森山です。

「MySQL自体の互換性を保つべき。」という点、賛成です。

現状の変換を正確に把握するために、MySQL 5.0.15 の ctype-sjis.c、
ctype-ujis.c を調べてみました。

sjis、ujis ともに、ベンダ定義文字は含まれていないために重複符号化の問題
はなく、本来であれば、ラウンドトリップが保証されるはずですが、MySQL の実
装では、元に戻らない文字があります。これは木下さんも指摘している点です
ね。

sjis->ucs2->sjis
  5C(\)->005C REVERSE SOLIDUS->815F(＼)

ujis->ucs2->ujis
  A1C0(＼)->005C REVERSE SOLIDUS->5C(\)
  8FA2B7(JIS X 0212 TILDE)->007E TILDE->0x7E(~)

本来とは異なる文字に変換されてしまうということで、RBDMS としても問題があ
るでしょうから修正すべきと思われます。

参考)
バックスラッシュ(\,5C)が文字化けする
http://oss.timedia.co.jp/index.fcgi/kahua-web/show/MySQL%c6%fc%cb%dc%b8%ec%a4%ce%ce%b9/%a5%d0%a5%c3%a5%af%a5%b9%a5%e9%a5%c3%a5%b7%a5%e5
(%5c%2c5C)%a4%ac%ca%b8%bb%fa%b2%bd%a4%b1%a4%b9%a4%eb

修正方法ですが、0x00〜0x7F は US-ASCII とみなしてマッピングを行い、
US-ASCII や JIS X 0201 ラテン文字とバッティングする JIS X 0208、JIS X
0212 の文字は、 FULLWIDTH 側のコードポイントを用いるというマッピングが問
題がおきにくいと考えられています。

次のようなマッピングになります。(MySQLで影響すると思われる文字のみ)

sjis/ujis ←→ ucs2 (双方向変換)

 sjis    | ujis    | ucs2
---------+---------+---------------------------------
 5C \    | 5C \    | 005C "Reverse Solidus"
 7E ~    | 7E ~    | 007E "Tilde"
 815F ＼ | A1C0 ＼ | FF3C "Fullwidth Reverse Solidus"
 ----    | 8FA2B7  | FF5E "Fullwidth Tilde"

On Fri, 11 Nov 2005 19:54:38 +0900
Yasufumi Kinoshita <kinoshita.yasufumi@xxxxxxxxxx> wrote:

> 他のRDBMS(商用、フリー問わず)でも自身の互換性を保つ事情で一度決めた変換則は
> 変えることができず、詳細については独自の部分もある状況です。
> というわけでRDBMS毎にバラバラな部分もあるかもしれませんが、
> 共通する部分はできるだけ取り入れてRDBMS間でのデータのやり取りのときの面倒、
> またはRDBMS同士での移行容易性を高めたい。

上記修正を施した上で、ucs2->sjis/cp932/ujis/eucjpms の変換を次のようにす
ることで、移行容易性を高める事ができるのではないかと考えています。

 + 印が付いている部分を追加します。

ucs2 → sjis/cp932

  ucs2                             | sjis   | cp932  | char
  ---------------------------------+--------+--------+-----
  005C "Reverse Solidus"           | 5C     | 5C     | \
  00A5 "Yen Sign"                  |+5C     |+5C     | \
  ---------------------------------+--------+--------+-----
  207E "Tilde"                     | 7E     | 7E     | ~
  203E "Overline"                  |+7E     |+7E     | ~
  ---------------------------------+--------+--------+-----
  2014 "Em Dash"                   |+815C   |+815C   | ―
  2015 "Horizontal Bar"            | 815C   | 815C   | ―
  ---------------------------------+--------+--------+-----
  301C "Wave Dash"                 | 8160   |+8160   | 〜
  FF5E "Fullwidth Tilde"           |+8160   | 8160   | 〜
  ---------------------------------+--------+--------+-----
  2016 "Double Vertical Line"      | 8161   |+8161   | ‖
  2225 "Parallel To"               |+8161   | 8161   | ‖
  ---------------------------------+--------+--------+-----
  2212 "Minus Sign"                | 817C   |+817C   | −
  FF0D "Fullwidth Hyphen-Minus"    |+817C   | 817C   | −
  ---------------------------------+--------+--------+-----
  00A2 "Cent Sign"                 | 8191   |+8191   | ¢
  FFE0 "Fullwidth Cent Sign"       |+8191   | 8191   | ¢
  ---------------------------------+--------+--------+-----
  00A3 "Pound Sign"                | 8192   |+8192   | £
  FFE1 "Fullwidth Pound Sign"      |+8192   | 8192   | £
  ---------------------------------+--------+--------+-----
  00AC "Not Sign"                  | 81CA   |+81CA   | ¬
  FFE2 "Fullwidth Not Sign"        |+81CA   | 81CA   | ¬
  ---------------------------------+--------+--------+-----
  00A6 "Broken Bar"                | ----   |+FA55   | (JISX0208外)
  FFE4 "Fullwidth Broken Bar"      | ----   | FA55   | (JISX0208外)
  ---------------------------------+--------+--------+-----

ucs2 → ujis/eucjpms

  ucs2                             | ujis   |eucjpms | char
  ---------------------------------+--------+--------+-----
  005C "Reverse Solidus"           | 5C     | 5C     | \
  00A5 "Yen Sign"                  |+5C     |+5C     | \
  ---------------------------------+--------+--------+-----
  207E "Tilde"                     | 7E     | 7E     | ~
  203E "Overline"                  |+7E     |+7E     | ~
  ---------------------------------+--------+--------+-----
  2014 "Em Dash"                   |+A1BD   |+A1BD   | ―
  2015 "Horizontal Bar"            | A1BD   | A1BD   | ―
  ---------------------------------+--------+--------+-----
  301C "Wave Dash"                 | A1C1   |+A1C1   | 〜
  FF5E "Fullwidth Tilde"           | 8FA2B7 | A1C1   | (注意)
  ---------------------------------+--------+--------+-----
  2016 "Double Vertical Line"      | A1C2   |+A1C2   | ‖
  2225 "Parallel To"               |+A1C2   | A1C2   | ‖
  ---------------------------------+--------+--------+-----
  2212 "Minus Sign"                | A1DD   |+A1DD   | −
  FF0D "Fullwidth Hyphen-Minus"    |+A1DD   | A1DD   | −
  ---------------------------------+--------+--------+-----
  00A2 "Cent Sign"                 | A1F1   |+A1F1   | ¢
  FFE0 "Fullwidth Cent Sign"       |+A1F1   | A1F1   | ¢
  ---------------------------------+--------+--------+-----
  00A3 "Pound Sign"                | A1F2   |+A1F2   | £
  FFE1 "Fullwidth Pound Sign"      |+A1F2   | A1F2   | £
  ---------------------------------+--------+--------+-----
  00AC "Not Sign"                  | A2CC   |+A2CC   | ¬
  FFE2 "Fullwidth Not Sign"        |+A2CC   | A2CC   | ¬
  ---------------------------------+--------+--------+-----
  00A6 "Broken Bar"                | 8FA2C3 |+8FA2C3 | (JISX0208外)
  FFE4 "Fullwidth Broken Bar"      |+8FA2C3 | 8FA2C3 | (JISX0208外)
  ---------------------------------+--------+--------+-----

ujis と ucs2 間での変換で JIS X 0212 TILDE 8FA2B7 のラウンドトリップをあ
きらめて、次のようにすることで、JIS文字に関して、ujis と eucjpms/cp932
の相互変換が実現でき移行容易性をさらに高めることができるものと思われま
す。

ucs2 → ujis/eucjpms

  ucs2                             | ujis   |eucjpms | char
  ---------------------------------+--------+--------+-----
  FF5E "Fullwidth Tilde"           |*A1C1   | A1C1   | (注意)

ujis では、JIS X 0212 TILDE 8FA2B7 に関しては、厳密に区別して取り扱う事
を主張しましたけれども、上記のようにした方がメリットが大きいかもしれませ
ん。

vim6 でも、iconv(3) で、JIS文字に関して、cp932<->euc-jp といった変換がで
きることを前提にハードコーディングされていたり、Linux kernel NLS でも
cp932 と euc-jp といった名前になっていたりして、Windows の ucs(Unicode)
マッピングにより変換された ucs と euc-jp の相互変換が出来ることを暗に期
待している人が多いという事実もありますし。

> > sjis、ujis は次の変換表を使うという事を意味します。
> >
> > JIS-Unicode間の変換表の選択について
> > http://hp.vector.co.jp/authors/VA010341/unicode/
> 
> 概ね賛成です。しかし、「現状変換が割り当てられていなかった文字限定」です。
> 現状行われているの変換則と違う文字がある場合に、
> それを修正するためには互換性に関して慎重に検討する必要があるのではないでしょうか？
> なので現状のsjis、ujisの変換は上記変換表と違う変換を行う部分が少なくともあるので、
> 「sjis、ujis は次の変換表を使うという事を意味します。」
> とは言えないと思います。
> 
> (一例)
> 0x815C(sjis) ←→ U+2015(ucs2)
> 0xA1BD(ujis) ←→ U+2015(ucs2)

オープン・ソース・ソフトウェアの場合、U+2015 Horizontal Bar との対応付け
の方が多いようですから、それに従った方がいいでしょうね。

> > MySQL の sjis、ujis は、Unicode コンソーシアムが配布していた変換表を使っ
> > ていると思われますが、あの変換表は、JIS X 0201 ラテン文字との組合せの場
> > 合の変換表で、なおかつJIS規格とは完全に一致しないので、あれをそのまま使
> > うと、実用になりませんし、JIS規格とも異なるものになってしまいます。
> 
> 正直、具体的に差を指摘していただき、実用の基準を示されなければ、
> 「実用にならない」の実感がわかりません^^;

http://hp.vector.co.jp/authors/VA010341/unicode/
で、Unicode Consortiumで配布されている JIS0201.TXT, JIS0208.TXT,
SHIFTJIS.TXT の問題点が指摘されています。

MySQL のように、sjis/ujis → ucs2 の変換の際に、0x00〜0x7F を US-ASCII と
みなして、U+0000〜U+007E に変換しているにも関わらず、JIS X 0208 の変換
を JIS0208.TXT、JIS X 0212 の変換を JIS0212.TXT を使ってしまうと、次のよ
うな実装をつくり出してしまうことになります。

＼(sjis=815F, ujis=A1C0) と \ (sjis=5C, ujis=5C) を区別できない。
JIS X 0212 TILDE(ujis=8FA2B7) と ~ (ujis=7E) を区別できない。

MySQL 5.0.15 の実装

  sjis/ujis → ucs2

   sjis    | ujis    | ucs2
  ---------+---------+---------------------------------
   5C \    | 5C \    | 005C "Reverse Solidus"
   7E ~    | 7E ~    | 007E "Tilde"
   815F ＼ | A1C0 ＼ | 005C "Reverse Solidus"
   ----    | 8FA2B7  | 007E "Tilde"

  ucs2 → sjis/ujis

   ucs2                   | sjis    | ujis
  ------------------------+---------+------------------------
   005C "Reverse Solidus" | 815F ＼ | 5C \
   007E "Tilde"           | 7E ~    | 7E ~

JIS0201.TXT との組合せであれば、次のような変換になります。

sjis/ujis ←→ ucs2 (双方向変換)

 sjis    | ujis    | ucs2
---------+---------+---------------------------------
 5C \    | 5C \    | 00A5 "Yen Sign"
 7E ~    | 7E ~    | 203E "Overline"
 815F ＼ | A1C0 ＼ | 005C "Reverse Solidus"
 ----    | 8FA2B7  | 007E "Tilde"

従来、JIS X 0201 ラテン文字はコード値だけを考えれば、US-ASCII と互換のも
のであるとして扱ってきたにもかかわらず、上記のような変換では、もはや
JIS X 0201 ラテン文字のコード値は、US-ASCII とは互換性がなくなってしまい
ます。さらに悪いことに、ucs2 の U+005CとU+007E が、それぞれ、JIS X 0208
と JIS X 0212 の文字に対応づけられてしまうので、利用者にとっては、不可解
な動作に思えてしまいます。

> 私はUnicode コンソーシアムの変換表とまだ比較したことが無いので分かりませんが、
> 少なくとも(sjis、ujis)のUCS2への変換は、調べた範囲では
> 
> ・シフトJISでの NEC特殊/NEC選定IBM拡張/IBM拡張/外字領域 などのJIS規格外文字句点コードは無視
> ・「／」全角バックスラッシュが U+005C と対応付けられる
> ・(EUCですみませんが) A1C0、A1C1、A1C2、A1DD、A1F1、A1F2、A2CC、8FA2B7、8FA2C3 にあたる文字
> 　のマッピングの違い
> 　※特に A1F1、A1F2、A2CC (¢、£、¬) を U+00A2、U+00A3、U+00AC （半角）に変換するのは
>     sjis、ujisのみの特徴。
> 
> 上記以外、他のRDBMS（Oracle、PostgreSQL）との差は無いようです。
> 確かに「／」が「\」とかに化けてしまう可能性はあるものの、
> ここまでで議論になった特定の文字(tilde系)以外は大きく化けることは無く
> 上記文字を使用しない人にとっては気づかない程度の差かも知れません。

JIS規格を元にした Unicode マッピングによる変換で得られる Unicode のコー
ド値を JIS-Unicode、CP932 の Unicode マッピングによる変換で得られる
Unicode のコード値を MS-Unicode と定義して、次のような表を作っておくとソ
フトウェアの実装を調べるときに比較すべき基準ができるので、マッピングの調
査をするときに役に立つと思います。

  +----+--------------+-------------+-------------+------------+
  |    | SJISコード値 | EUCコード値 | JIS-Unicode | MS-Unicode |
  +----+--------------+-------------+-------------+------------+
  | \  |       5C     |      5C     | 00A5 / 005C |    005C    |
  | ~  |       7E     |      7E     | 203E / 007E |    007E    |
  +----+--------------+-------------+-------------+------------+
  | ￣ |     8150     |    A1B1     | FFE3 / 203E |    FFE3    |
  | ―  |     815C     |    A1BD     |     2014    |    2015    |
  | ＼ |     815F     |    A1C0     | 005C / FF3C |    FF3C    |
  | 〜 |     8160     |    A1C1     |     301C    |    FF5E    |
  | ‖  |     8161     |    A1C2     |     2016    |    2225    |
  | − |     817C     |    A1DD     |     2212    |    FF0D    |
  | ￥ |     818F     |    A1EF     | FFE5 / 00A5 |    FFE5    |
  | ¢ |     8191     |    A1F1     |     00A2    |    FFE0    |
  | £ |     8192     |    A1F2     |     00A3    |    FFE1    |
  | ¬ |     81CA     |    A2CC     |     00AC    |    FFE2    |
  +----+--------------+-------------+-------------+------------+
  |    |     ----     |  8FA2B7     | 007E / FF5E |    ----    |
  |    |    (FA55)    |  8FA2C3     |     00A6    |    FFE4    |
  +----+--------------+-------------+-------------+------------+

> > あらためて、まとめますと、実用的な変換は、cp932、eucjpms で実現し、
> > sjis、ujis は標準規格に出来うる限り従うようにするという事になります。
> 
> sjis、ujisの現状は森山さんが言われるところの「標準規格」とは違う変換をすること
> が分かりましたが、これらを無理に変更するのではなく、
> 新たに納得する文字コードセットを追加したほうがいいのではないでしょうか？
> MySQLのソースを見ると、UCSへの変換テーブル、UCSからの変換テーブルは
> strings/ctype-[コードセット名].c
> の中にあります。
> どうしても別の変換則が必要であれば、あたらしいctype-xxxx.cを作成して、
> 「このコードセットを追加してください」
> という要望を出したほうが、既存への影響も少なく、話が早いと思います。
> いかがでしょう？
> （ユーザー会の要望としてならば採用されやすいような気も・・）
> 
> 私の考えはあくまで「現状維持しつつ文字消えを改善すること」です。

次のように不具合修正がされれば、「現状維持しつつ文字消えを改善すること」
でも問題ないと考えています。

次のようなマッピングに変更 
  0x7E(sjis)   <--> U+007E(ucs2) "Reverse Solidus"
  0x815F(sjis) <--> U+FF3C(ucs2) "Fullwidth Reverse Solidus"
  0xA1C0(ujis) <--> U+FF3C(ucs2) "Fullwidth Reverse Solidus"

-- 
森山将之 (MORIYAMA Masayuki)
e-mail: msyk@xxxxxxxxxx
blog: http://msyk.at.webry.info/