mysql:12440

森山です。

「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(\)

これを MySQL の仕様と考えて、今後とも、互換性を確保するのか、それとも不
具合と考えて修正するのかを決定する必要があります。
本来とは異なる文字に変換されてしまうということで、RBDMS としても問題があ
るのではないでしょうか?

修正する場合の考え方は複数あり、
(1) 0x00～0x7F を US-ASCII とする。
  (1)-a JIS X 0208 YEN SIGN を U+00A5 とマッピングする
(2) 0x00～0x7F を JIS X 0201 ラテン文字とする

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

> ＜私の考え＞
> ・MySQL自体の互換性を保つべき。

過去との互換性は重要ですね。

> ・他のRDBMSとの変換互換性を重視したい。
> 
> 残念ながら文字変換の「標準」はソフトウェアの種類だけあると考えています。
> Javaの世界にはJavaの世界の「事実上標準」が、
> RDBMSにはRDBMSの世界での「事実上標準」があるのではと思います。
> 
> 他のRDBMS(商用、フリー問わず)でも自身の互換性を保つ事情で一度決めた変換則は
> 変えることができず、詳細については独自の部分もある状況です。
> というわけでRDBMS毎にバラバラな部分もあるかもしれませんが、
> 共通する部分はできるだけ取り入れてRDBMS間でのデータのやり取りのときの面倒、
> またはRDBMS同士での移行容易性を高めたい。

MySQL 5.0.15 の strings/{ctype-sjis.c,ctype-ujis.c} を見てみると、MySQL
単体で考えた場合にでも、整合性のとれない実装が行われているようです。

変換表の問題以前に、変換表の使いかたが混乱しているようです。



> 
> というわけで、とりあえずOracle、PostgreSQLで行われている変換則と差分を取ったもの
> を元に「c)案」を作成しています。
> 
> 
> ・その他の事情の考慮。
> 
> 現状、MySQLのソース変更内容をレビューするは日本人ではないのではないでしょうか？
> それを踏まえて、追加変更のルール・指示はできるだけ分かり易い方がよいと考えます。
> 
> 
> ＜森山さんのメールへのレス＞
> 
> > しかし、sjis、ujis に関しては、なるべく標準規格にしたがいつつも UCS 経由
> > の sjis<->ujis 変換を実現し、他のソフトとも互換性がとれるように、Java
> > の SJIS、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)
> これらは現状のJIS規格での文字名称とは異なった変換をしていますが、
> Oracle、PostgreSQLなど他のRDBMSでもこの変換が基本になっており、
> 特にPostgreSQL、MySQLでは U+2014(Em Dash) はJIS系のコードへの変換はされず消えてしまいます。
> （※ので「c)案」には入れなければいけませんね^^;）
> 
> 
> > >４．ucs2 → ujis
> > >     007E → 7E
> > >     301C → A1C1
> > >     FF5E → 3F("?") ※c)案 では A1C1 になる
> >
> > MySQL だけで完結する問題であれば、自由に決めても構わないと思いますが、
> > ujis を Java の EUC_JP と互換にする場合、上記の c)案の変換はマズイです。
> 
> これは私のミスです。申し訳ありません。
> 観点は違いますが、Oracleとの互換性も考え、0xFF5E(ucs2) → 8FA2B7(ujis)
> とするべきですね。
> 
> 
> 
> > MySQL の sjis、ujis は、Unicode コンソーシアムが配布していた変換表を使っ
> > ていると思われますが、あの変換表は、JIS X 0201 ラテン文字との組合せの場
> > 合の変換表で、なおかつJIS規格とは完全に一致しないので、あれをそのまま使
> > うと、実用になりませんし、JIS規格とも異なるものになってしまいます。
> 
> 正直、具体的に差を指摘していただき、実用の基準を示されなければ、
> 「実用にならない」の実感がわかりません^^;
> 私は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系)以外は大きく化けることは無く
> 上記文字を使用しない人にとっては気づかない程度の差かも知れません。
> 
> 
> 
> > あらためて、まとめますと、実用的な変換は、cp932、eucjpms で実現し、
> > sjis、ujis は標準規格に出来うる限り従うようにするという事になります。
> 
> sjis、ujisの現状は森山さんが言われるところの「標準規格」とは違う変換をすること
> が分かりましたが、これらを無理に変更するのではなく、
> 新たに納得する文字コードセットを追加したほうがいいのではないでしょうか？
> MySQLのソースを見ると、UCSへの変換テーブル、UCSからの変換テーブルは
> strings/ctype-[コードセット名].c
> の中にあります。
> どうしても別の変換則が必要であれば、あたらしいctype-xxxx.cを作成して、
> 「このコードセットを追加してください」
> という要望を出したほうが、既存への影響も少なく、話が早いと思います。
> いかがでしょう？
> （ユーザー会の要望としてならば採用されやすいような気も・・）
> 
> 私の考えはあくまで「現状維持しつつ文字消えを改善すること」です。
> 
> 
> かなり長文になってしまいましたが、
> ＜c)案 Unicode -> JIS系文字コードへの変換＞
> をもういちど整理します。
> -------------------------------------------------------------------------------
> 
> １．基本ルール
> http://dev.mysql.com/doc/refman/4.1/ja/charset-cp932.html
> の下の表のUnicodeからの変換先が割り当てられていない("3F")
> 文字について、他のキャラクターセットで割り当てられているもの
> については同一の文字を割り当てる。
> ujis、eucjpmsでも同じ文字について同様にする。
> 
> ２．上記の例外
> FF5E(ucs2) → 8FA2B7(ujis)
> 
> ３．追加
> ucs2                   | sjis  | cp932
> -----------------------+-------+-------
> 00A5 (半角の￥※)      | 3F    | 3F    ←両方とも 5C にする
> 2014 "Em Dash"         | 3F    | 3F    ←両方とも 815C にする
> 
> ucs2                   | ujis                | eucjpms
> -----------------------+---------------------+---------
> 00A5 (半角の￥※)      | 8E5C5C（化けました）| 3F     ←両方とも 5C にする
> 00A6 (半角の￤)        | 8FA2C3              | 3F     基本ルールで
> FFE4 (全角の￤)        | 3F                  | 8FA2C3 基本ルールで
> 2014 "Em Dash"         | 3F                  | 3F     ←両方とも A1BD にする
> 
> --------------------------------------------------------------------------------
> これで大丈夫でしょうか？
> 表記法がばらばらでごめんなさい。
> 
> 
> 最後に村上さんが提案されているように、セッション毎に
> 同じエンコーディング間、またはＪＩＳ系の文字コード同士での
> 自動変換をバイパスする（句点コード不動）方法があったほうが便利だと私も思います。
> 
> 
> 以上、かなりの長文失礼いたしました。
> 
> 
> -- 
> 木下  靖文
> 
> e-mail: kinoshita.yasufumi@xxxxxxxxxx
> 
> 


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