一見かなりまともそうだったのだが、いくつかの文字がどうしようもなかったりした。
補助漢字部分の拡張が目的ではあるが、それにより今まで変換できた文字が出来なくなる。
WideCharToMultiByteで、UTF-16からSJISへの変換に成功した文字の内、
UTF-16からEUCへの変換に失敗したのは、「昴」「～」とか14文字だ。
逆にそれらを、MultiByteToWideCharで、EUCからUTF-16に変換すると、
似て非なるコードに割り振られたり、似てない非なるコードに割り振られたりする。
ちょっと待てよと。
今回はEUCへの変換に失敗した文字だけに注目したが、
この分だと変換に成功したけどまるっきり間違っているってのも多いんじゃないかと。

CP20932を利用する変換は破綻した。

CP51932はWideCharToMultiByteもMultiByteToWideCharも動作しないので、
あとは旧来のSJIS経由変換か、変換表作成しか残っていない。

CP20932の変換もせっかく作ったので残そうかとも思ったが、
普通のEUC変換とどこが違うのかを説明したりするのも面倒だしスッキリしないのでナシで。

まとめると、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

日本語文字コードって、WindowsではSJIS、UnixではEUCということだが、
インターネットが普及したおかげで、EUCをWindowsで扱う機会も増えてきたということだが、
EUCにはあってSJISにはない文字っていうのもあるってことを、萌ディタの開発日記で知った。
旧来のSJISのテキストエディタでは、SJISにない文字なんだから編集出来なくて当たり前で、
”EUC対応”って書いていても特定の文字は変換できなくて切り捨ててきたわけだ。
知らなかった。

真魚も元々はSJISのテキストエディタだったので、現在はユニコードであるにもかかわらず、
その時に使ってたSJIS＜-＞EUC変換をそのまま使っていて、
EUCのファイルはいったんSJISに変換し、さらにSJISをユニコードに変換している。
EUCとSJISの変換を真魚がやり、SJISとユニコードの変換をOSにやらせている。
OSは、Win9xまではSJIS、Win2K/XPはユニコードで動いてるので、
下位互換のためSJISとユニコードの変換は得意中の得意で、なんの問題もない。
EUCとSJISの変換は前述の問題アリだけれども、
日本語文字コード同士なので割と簡単に実装できる。
そういう状況なので、多くのテキストエディタはEUCに完全対応していないのだ。
真魚は内部ユニコードになったので、SJIS変換を経由するのをやめれば、
EUCにしかない文字も切り捨てずに編集できるようになるだろうという話。

.NET製のぎょえ（仮）の場合、文字コードの変換は.NETの実装で行っていた。
MSDNにはコードページ51932を使えと書いてあり、実際にそれを使っていた。
しかし、非.NETでは51932は動かないので、かわりに20932を使う事になる。
萌ディタの開発日記では「51932は環境による」ってあったけど、
環境によらず51932は.NETでしか動かず、
.NETの51932はおそらく20932を呼び出して動かしているらしく、動作は全く同じらしい。
よって、WindowsではEUCを20932で扱うということになる。

さて、この20932を使って、OSにEUC＜-＞ユニコード変換をさせてみたのだが、
EUCにあってSJISにない文字群（JIS X 0212 補助漢字）は、ユニコードに変換出来なかった。
逆にユニコードからEUCに変換してみたところ、EUCの規格に沿わない2バイトを吐いた。
本来のEUC
8F A2 AF
ユニコード
U+02D8
WindowsのEUC
A2 2F

というわけで、Windowsに任せてEUC＜-＞ユニコード変換するのは無理のようだ。
アプリ本体内に、EUC＜-＞ユニコード変換表を持たせておけば変換は可能であるが、
さてその変換表を誰がまとめるのだ？
数万ある文字を双方向に変換できるようにデータ化しろというのか。
EmEditorすら変換できない領域の文字に、そこまでの労力が必要か。

いや、必要だと思うね。
現状、Unixで書いた文書をWindowsで開いて、編集せずに上書き保存したら、
その文書に含まれる補助漢字領域の文字は失われてしまうのが普通。
ここらでEUC変換部分をつくってソース公開すれば、
DelphiアプリのEUC対応状況が一歩前進することになるだろうから、ぜひチャレンジしたい。
できあがる頃にはもうWindowsもUnixもSJISもEUCもない、遙か未来かも知れないが。
それより先にDelphi自体がなくなってるかもな。

B0009IQQZ6