日本語文字コードって、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