玉川です。

>> あらためて、まとめますと、実用的な変換は、cp932、eucjpms で実現し、
>> sjis、ujis は標準規格に出来うる限り従うようにするという事になります。

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

>私の考えはあくまで「現状維持しつつ文字消えを改善すること」です。

木下さんの考えに賛成です。

対応のポイントとしては以下の2点だと思います。

1. UCSからの変換する際の文字消えの可能性への対応
2.　異なる変換ルールへの対応

1.については、現時点で何も文字が割り当てられていないところに文字を
割り当てることによって、変換の際に発生する文字消えを回避するものなので、
既存MySQLとの互換性も保てるので良いでしょう。

2.については、MySQLとしても既存の変換ルールを変えるのではなく
新しいキャラクターセットを追加する事で対応することになっています。
新しいキャラクターセットの追加については、どれだけのニーズがあるかに
よるでしょう。

>かなり長文になってしまいましたが、
>＜c)案 Unicode -> JIS系文字コードへの変換＞
>をもういちど整理します。

ありがとうございます。

>２．上記の例外
>FF5E(ucs2) → 8FA2B7(ujis)

ここは8FA2B7、A1C1のどちらかの選択になりますが、JAVAのEUC_JP、Oracleとの互換を
考慮して8FA2B7を選択するということでよろしいですか？