まとめると、EUCをWindowsで扱う方法は三つ。
○SJISに変換する。
SJISにはない補助漢字領域の文字は全て破棄する事になる。
○EUC＜-＞UTF16変換テーブルをアプリ内で持つ。
一番やりたいのはこれだが作業がつらい。
○CP20932を使ってWindowsにやらせる。
本来のEUCでは補助漢字領域を3バイトで表すが、CP20932は2バイトで表す。
この2バイトと3バイトの相互変換が実に簡単な事がわかった。

CP20932でOSが変換し、真魚が補助漢字領域を補正すれば、
旧来のSJISを経由した変換に比べて、EUCへの対応度は上がる。
これでもまだ不備はあるらしいが、SJIS＜-＞UTF16だって不備は調整してないわけで、
規格としての正解よりも、Windowsでの正解に従うのが、一番自然な処理なのだ。
一応これで行きたいのだが、どの環境でもCP20932変換に対応しているかが問題。
地域と言語のオプションを見てみると、SJISやJISのコードページは灰色表示で、
チェックボックスを操作して削除することは出来ないのだが、
CP20932は削除することが出来るし、削除するとOSは変換が出来なくなる。
その状態でもIEはEUCのページを表示できるわけだから、
IEはCP20932に依存しない方法で変換しているのは間違いない。
ただしIEも補助漢字領域の読み込みが出来ないので、
IEと同じ方法を使うということはする気がないが。
環境といっても、意図してCP20932を削除した場合のみ動作しないわけだから、
削除の仕方がわかっている人が、削除の結果で変換できなくなったとしても、
いったい何の問題があるのだという話になるわけだ。
そういうことで、EUC変換はこの方法でバッチリ解決だ。
変換だけじゃなく、自動判別や不正文字の事前チェックなんか見直さなきゃだが。

萌ディタの日記でEUCよりもJISの対応の方がいろいろ書いてある。
EUCはUnix由来のファイルを編集するために必要な対応であり、
JISはEメールを編集するために必要な対応だ。
第一水準、第二水準漢字の扱いで4通り、半角カナの扱いで3通りの種類があり、
EUC補助漢字を含む拡張、ハングル、中国語を含む拡張、さらに不明な拡張2つある。
これって、4*3*5=60通りのJIS規格があるということだろうか。
実は規格がいくつあろうが、全部に対応する必要はないんじゃないかと。
Windowsで扱うEメール対応のためのJIS変換なんだから、
WindowsでEメールをどの形式で保存してるか調べてそれで統一すれば良い。
現在の真魚は、EUC同様jconvert.pasによるSJIS経由変換だが、
これも見直したり作り直したりするのは面倒だにゃぁ。

B0002T79LC