ようやく満足のいくEUC対応ができあがったようだ。
が、乗りかかった船なのでもうちょっと調べている。

http://kanji.zinbun.kyoto-u.ac.jp/~yasuoka/kanjibukuro/japan.html
これのEUC-JPとShift_JISのところに、ちょっと納得いくことが書いてあった。
＞いずれを使うかは、使う人の自由にまかされます。
なるほどな。
DelphiアプリでのEUC変換は、jconvert.pasというのが昔からあり、
そこに書いてある奇数だとか偶数だとかのルールで機械的に行っているわけだが、
これはEUC側でどのJISを用いているかと、SJIS側のそれが一致している前提なんだな。
で、Windowsで編集され、EUCで保存されたファイルというのは、
JISX0208の領域が、Windows式で保存されたEUCファイルと言うことになる。
このWindows式は、少なくともJIS0208.TXTに記された物とは異なっている。
真魚のような、内部ユニコードなアプリが、SJISを経由せずにEUC保存する場合、
JIS0208.TXTにしたがって変換すると、Windows式でないEUCファイルが出来るので、
それを内部SJISなアプリが変換を行ってSJISにした場合は、
Windows式でないSJISという、何とも実用性のないおかしな物が出来るという答えだ。
これはCP20932やCP50220を利用した場合も同じく問題になる。
正解はやはり、前述の奇数偶数の計算のみで変換するWindows式EUCファイルだろう。
もし対象となるEUCファイルが何式なのかがわかっているなら、
それをユーザーが指定して変換するのが一番正確ではあるが、
EUCだけで3種類の形式を提起するテキストエディタを使った場合、
一体どれで保存すればいいのか判断できるユーザーがどれだけいるだろうか。

そういうわけで真魚のEUC対応は、Windows式0208＆0212-1990で完成だ。
双方向で変換テーブルを持つようになったので実行ファイルが微妙に大きくなって、
UPX処理前でついに2MBだが、UPXすればそれほど変ってない。
一応、テキストエディタごときなので、配布ZIPファイルで1MB以内でやっていきたい。

せっかくいろいろ調べたのでJIS変換もどうにかしたい。
せっかく作った変換テーブルをJIS変換にも利用できないかなぁとか考えている。

4053008913