木下です。

私もどういう考え方に基づいて発言してきたのかまとめます。
また c) 案についての変換表をもう一度整理します。
（結構下のほうになってしまいました・・玉川さんすみません）

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

現在の仕様の、sjis、cp932、ujis、eucjpmsが正式にリリースされていて、
（多分）不便な中それぞれの工夫で実際に利用されているはずです。
なので、たとえ各々の意にそぐわない変換でも現在動作しているシステムのために
互換性を保たなければいけないと思います。

過去との互換性を保っていくために許される変更は、基本的には
従来変換されていなかった文字について変換できるようにすることだけと考えています。

というわけで、各々の”標準規格”の意図する変換と違う文字になるのであれば
違うものであると諦めて新しく文字コードとその変換を定義しなければいけないのでは
ないでしょうか。


・他のRDBMSとの変換互換性を重視したい。

残念ながら文字変換の「標準」はソフトウェアの種類だけあると考えています。
Javaの世界にはJavaの世界の「事実上標準」が、
RDBMSにはRDBMSの世界での「事実上標準」があるのではと思います。

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

というわけで、とりあえず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