森山です。

まず、私の考えをはっきりさせておきます。

UCS->cp932、UCS->eucjpms で、多対1 の変換をサポートする事に関して異論は
ありません。 glibc 2.3.3 以降、libiconv のパッチでは iconv(3) の cp932,
eucJP-ms は、そのようにしてあります。(Java で SJIS->UCS, EUC_JP->UCS 変
換したデータを変換できるようにしてあります。)

しかし、sjis、ujis に関しては、なるべく標準規格にしたがいつつも UCS 経由
の sjis<->ujis 変換を実現し、他のソフトとも互換性がとれるように、Java
の SJIS、EUC_JP と互換にするのが、今のところ最も妥当なのではないかと考え
ています。

sjis、ujis は次の変換表を使うという事を意味します。

JIS-Unicode間の変換表の選択について
http://hp.vector.co.jp/authors/VA010341/unicode/

On Thu, 10 Nov 2005 20:15:18 +0900
Yasufumi Kinoshita <kinoshita.yasufumi@xxxxxxxxxx> wrote:

> ４．ucs2 → ujis
>     007E → 7E
>     301C → A1C1
>     FF5E → 3F("?") ※c)案 では A1C1 になる

MySQL だけで完結する問題であれば、自由に決めても構わないと思いますが、
ujis を Java の EUC_JP と互換にする場合、上記の c)案の変換はマズイです。

> （※IANA EUC-JP ではこうでしょうか？
>     A1C1   → 301C
>     8FA2B7 → FF5E）

そうなります。
Java の EUC_JP では、そのように変換されます。

> ・・とここまで書きましたが、１文字だけ実用上拙い文字がありますね。
> U+005C ＼ REVERSE SOLIDUS
> と
> U+FF3C ＼ FULLWIDTH REVERSE SOLIDUS
> です。
> c)案では消えることはなくなりますが、
> 0xA1C0(ujis) → U+005C(ucs2) → 0x5C(eucjpms)
> 0x5C(eucjpms) → U+005C(ucs2) → 0xA1C0(ujis)
> と逆になってしまいます。。。

MySQL の sjis、ujis は、Unicode コンソーシアムが配布していた変換表を使っ
ていると思われますが、あの変換表は、JIS X 0201 ラテン文字との組合せの場
合の変換表で、なおかつJIS規格とは完全に一致しないので、あれをそのまま使
うと、実用になりませんし、JIS規格とも異なるものになってしまいます。

Unicode コンソーシアムの変換表
ftp://ftp.unicode.org/Public/MAPPINGS/EASTASIA/README.TXT
ftp://ftp.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/

JIS0208.TXT で、JIS規格と異なるマッピング　
誤: 0x815C	0x213D	0x2015	# HORIZONTAL BAR
正: 0x815C	0x213D	0x2014	# EM DASH

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

次の変換は可能とする
  sjis->cp932
  ujis->eucjpms

次の変換はサポートしない
  cp932->sjis
  eucjpms->ujis

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