木下です。
毎度、勉強になります。

議論をより具体的にするために
Unicode(UCS)、日本語EUCの文字コードにおいて、
「～」形状の文字について
現状のMySQLで行われている変換を一旦整理します。

<ucs2との対応>
１．eucjpms → ucs2
    7E     → 007E
    A1C1   → FF5E
    8FA2B7 → FF5E

２．ujis → ucs2
    7E     → 007E
    A1C1   → 301C
    8FA2B7 → 007E

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

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

<上記を踏まえたucs2を介したeucjpmsとujisの変換>
Ａ．eucjpms → ujis
    7E     → 7E
    A1C1   → 3F("?") ※c)案 では A1C1 になる
    8FA2B7 → 3F("?") ※c)案 では A1C1 になる

Ｂ. ujis → eucjpms
    7E     → 7E
    A1C1   → 3F("?") ※c)案 では A1C1 になる
    8FA2B7 → 7E

長くてすいませんが、以上を踏まえて・・^^;

MORIYAMA Masayuki wrote:
> IANA の charset の定義によれば、
> 
> Shift_JIS = JIS X 0201:1997 (ラテン文字+片仮名) + JIS X 0208:1997
> EUC-JP    = US ASCII + JIS X 0208-1990 + JIS X 0201 片仮名 + JIS X 0212-1990
> 
> となっています。
> 
> ここで UCS の変換で問題となってくるのは、次の点です。
> 
> (1) 0x00～0x7F を JIS X 0201 ラテン文字とするのか、US-ASCII とするのか?
> (2) JIS X 0212 を含めるのか否か?
> 
> この辺の問題は、次のページに詳しく取り上げられています。
> http://euc.jp/i18n/ucsnote.ja.html#ascii
> 
> (2) に関しては、CP932、eucjpms との関係を考えると、次のような問題が生
> じてきます。
> 
> 本来、IANA の定義に従った EUC-JP では、JIS X 0212 2区23点 TILDE を 
> US-ASCII の TILDE と区別するために、FULLWIDTH TILDE U+FF5E に対応付け
> されます。

ということは、
    A1C1   → FF5E
    8FA2B7 → FF5E
な eucjpms も
    A1C1   → 301C
    8FA2B7 → 007E
な ujis も
どちらも IANA の EUC-JP 「ではない」ということになるのですよね？？
（※IANA EUC-JP ではこうでしょうか？
    A1C1   → 301C
    8FA2B7 → FF5E）

> 
> しかし、cp932 などの UCS とのマッピングでは、JIS X 0208 1区33点 WAVE
> DASH (～) を UCS の FULLWIDTH TILDE U+FF5E と対応付けしているため、
> 
>   cp932 → UCS → EUC-JP
> 
> という変換を行うと、次のような変換がされてしまい、区点位置が保存されま
> せん。
> 
>   ～ 0x8160(cp932) → U+FF5E(UCS) → 0x8FA2B7(EUC-JP)
> 


0x8160(cp932) → U+FF5E(ucs2) → 0xA1C1(eucjpms)
                                 0x3F ※c)案 では A1C1 (ujis)
ということでMySQLではcp932での「～」の句点位置はeucjpmsでは保存され、
c)案を適用するとujisでも保存されます。


> ですので、「Unicode -> JIS系文字コードへの変換」で、多対1 の変換を行っ
> て、Unicode マッピングの違いを吸収できるのは、JIS X 0212 を含まない、
> cp932、sjis もしくは、U+FF5E FULLWIDTH TILDE が JIS X 0208 WAVE DASH 
> にマッピングされる eucjpms になります。
> 
> EUC-JP には、JIS X 0212 が含まれていて、U+FF5E FULLWIDTH を JIS X 0212 
> の TILDE と対応付けすべきなので、残念ながら違いを吸収できません。
> 
> という事で、UCS 経由では ujis<->eucjpms という変換は、元々不可能な変換
> であると考えておく必要があります。

というわけでeucjpmsもujisも現在はIANAのEUC-JPではないとすると、
UCS 経由での ujis<->eucjpms は、JIS X 0212 2区23点 TILDE (8FA2B7) が
7E か A1C1 に揃えられてしまうことを念頭に使用すれば、
実用上の問題は大きくは無いのではないでしょうか？
確かに厳密なIANAのEUC-JPとの変換をUCS経由でサポートするのは難しいですが。。

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

個人的には厳密な字形よりも実用性(他のRDBMSとのデータのやり取りなど)を重視して
「／」だけは
0xA1C0(ujis) ←→ U+005C(ucs2)
ではなく
0xA1C0(ujis) ←→ U+FF3C(ucs2)
と変更して欲しいのですが。(シフトJISも) ujis<->eucjpmsのためにも。
困るケースがあるでしょうか？？

だんだん頭が痛くなってきました・・^^;

-- 
木下  靖文
e-mail: kinoshita.yasufumi@xxxxxxxxxx