ようやく満足のいく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

自体はどんどん複雑化する。
ユニコードの私用領域であるU+E000辺り以降が、SJISやJISへ変換出来ると言うことを、
ATOKの文字パレットで確認したが、JISの規格では使われていない、
0x7F21から0x927Eまでが割り当てられているようだ。
EUCでは、JISでの0x2121～0x7E7Eに0x8080を加えた、0xA1A1～0xFEFEを使っているので、
規格をはみ出して私用領域を割り当てようとすると桁があふれてしまうのだ。

さて、今回やりたいEUC変換は何を正解とするのかというと、
今まで真魚がやってきたSJIS経由EUC変換に対する完全上位互換で、
しかも今までは出来なかった補助漢字領域の変換を行うことだ。
その今までやってきたSJIS経由の変換は、
変換表によるマッピングではなく計算でやっているため、
一部の不正な文字も変換が行われている可能性がある。確認はしていない。
意図した変換ではない部分があっても、その部分の変換を再現するのが正解だろうか？
とりあえず、jconvert.pasでは、私用領域部分の変換はしていないように見える。

ちゃんと意図している0xA1A1～0xFEFEは、これまでの変換を正解としていいだろう。
0x00～0x007FはSJIS同様、ストレートに変換する。
SS2の半角カタカナもシンプルだ。
SS3は、資料が一つしかないし確認のしようもないのでそのまま使う。
もっといいSS3の資料が見つかれば、その時置き換えればいい。
あと残りの領域については、規格にないわけだから、
今まで変換できてたとしても意図した物ではないはずな訳で、
切り捨てて問題が起こるような文字は一切含まないはずだ。

ようやくこれでEUC対応は完成しそうな予感。

4324061394

JISX0212の補助漢字領域の資料が正しいかどうかはわからないが、
JISX0208の第一水準、第二水準漢字領域については、
資料には不備が多すぎて使い物にならなかったと言うことで、
CP50220を使って、OSにJISX0208領域を実際に変換させてテーブルを作成させた。
そしたら、CP20932を使ったときと同様、それと同じ文字で問題があった。
これも、SJIS経由での変換とは多少違った物を作ってしまった。
いや、多少かどうかは知らないよ。全部は確認してないから。
ただ、コレで作ったテーブルを用いてEUCからユニコードにコンバートしてみたら、
目立って違っていたのがそれらの文字で、似たような変換なんだろうと思っただけ。

あと、ユニコードで0xE000あたりに存在する私用領域ってのがあるんだけど、
そのあたりはJISで0x7F21からってことになっていて、
0x21から0x7Eしか定義されていないのに7Fを使われたら変換できない。
CP50220でMultiByteToWideCharしようとすると、7Fはやっぱり受け付けてくれない。
OSによる変換はSJIS以外全然ダメってことでいいかな。
ちなみにこの私用領域の文字、EmEditorでEUCに保存しようとすると、
なぜかそこだけSJISで保存する。
よって、EmEditorで保存したEUCファイルはサポート外ということで。

さて、CP50220による変換表も使えないわけだが、一番良い方法を忘れていたよ。
今まで使っていたjconvert.pasを使って、SJIS経由で変換する表を作ればいいんだ。
そうすれば、今までのEUC文字は今まで通り、
補助漢字領域は不備があるかも知れないけど一応1990年のもので対応できる。

はぁ、EUCで命落とすかも。

二つの方法がダメになった。
○SJISを経由すると補助漢字が失われる。
○CP20932でもうまくいかない。
で、最後の方法として、
○アプリが変換テーブルをもつ。
コレをやるにあたり、
http://www.unicode.org/Public/MAPPINGS/OBSOLETE/EASTASIA/JIS/
にあるテキストファイルを使用した。
矩形選択と正規表現置換で、完璧にDelphiコードに変換できた。
そして実際に正しい変換が出来るかやってみた。

これも全然ダメ。
ユニコード全文字を上からざっと見ていくと、最初に目につくのが「№」という文字。
JIS0208.TXTで、0x2D62を0x2116に変換する記述がない。
0x2840の次が急に0x3021まで飛んでいて、0x2D21から0x2d70にある文字ゴッソリない。
おかしいのはここだけじゃなく、本当に大量におかしいのだ。
CP20932の変換がマトモに見えるくらい相当おかしい。
コレってJIS X 0208 (1990) to Unicodeって書いてあるから、
78の旧JIS、83の新JIS、90の情報交換用漢字符号、97の規格厳密化、という流れの、
90年版に相当するもののようだが、EUCで使われるJIS0208とは異なると言うことなのか。
補助漢字対応の前に、第一水準＆第二水準漢字で既に変換できなくなってる。

さて、これからどうしようかな。
○もっと良い変換表を探してくる。
○OSの挙動を調べて自分で作る。
○あきらめる。
CP20932で実装した時点で、気分はもう補助漢字対応当たり前になっているので、
もう後戻りはしたくない。

B0002V04GM