JIS/EUC変換読み書き部分を作り直し、今まで対応してなかった文字に対応したので、
文字コード自動判定部分も、新たに対応した領域を使いたい。
jconvert.pasは結構古いものなので、
JIS、EUCを検出することは出来ても、UTF-8やUTF-7を自動判定することは出来ず、
真魚では、まずjconvert.pasの判定もして、
しかも自前で書いたUTF-7とUTF-8の判定をもするという形をとっているわけだが、
全部まとめて1passで判定する関数を作りたいと思っているわけだ。

そこで一つ問題が見つかった。
それはEUCでもJISでもなく、UTF-8だ。
現在、UTF-8はシステムに変換をさせているのだが、書き込みはたぶん問題ない。
そもそもユニコードからユニコードへの変換だから、
UTF-16からUTF-8に変換して保存するのに問題がでるはずもないだろう。
だが、逆にUTF-8ファイルから読み込む場合にちょっとマズい実装がある。
UTF-8やUTF-7はEUCやSJISによく似たファイル形式で、
半角部分は1バイト、それ以外の文字は複数バイトで書かれるわけだが、
その複数バイトの組み合わせが定義から外れていた場合、
UTF-8からの変換の場合だけ一切の文字を返さないのだ。
たとえばテキストファイルの先頭から最後の2文字目まで正当なUTF-8で、
最後の1文字がUTF-8では使えない0x80なんかが入っていたとする。
その、最後の1文字を除く、そこまでのテキストはせめて変換して欲しいのだが、
バイナリエディタで不正な文字を入れて試したら全くのゼロだった。
これって、OSのバグかなぁと思って調べてみたら、
DelphiのUTF-8変換はOSを介していない事がわかり、悪いのはDelphiだとわかった。
試しにMultiByteToWideCharで、OSに変換させてみたところ、
最後の不正な文字の前までちゃんと変換された。

そういうことで、これまではUTF-8かどうかを判定するために、
全テキストの最初から最後までがキッチリUTF-8に沿っているか調べていたが、
これからは、先頭からチェックしてEUCやSJISの可能性が消えた時点で、
UTF-8として判定をやめ、変換処理に移ると言う形でいけるのではなかろうか。

無論、自動判定を日本語以外のテキストにまで使う気はない。

4534032242

JISにもESC$(Dで補助漢字領域が使えるようなので、読み込み部分で対応した。
これで、EUCもJISも旧来の変換では切り捨てていた多くの文字に対応した事になる。
もちろんJISの書き出しはメーラー互換を前提にするので、補助漢字の書き出しはしない。
JISで使えないはずの規格外4文字が半角カタカナ周辺にあり、これも書き出さないことにした。
JISの変換はやはりSJISを経由にし、新たにテーブルを設けることはしなかった。

さてここで、まだ文字コード関連の仕事が残っている。
いままでは、EUCでもJISでも、SJISで使えない文字を色分けしていた。
JISはそれでも良いだろうが、EUCはこの色分けを変更しなきゃいけないだろう。
でも、これまで通りSJISで使えない文字を色分けした方が、
補助漢字であるということがわかって、使う人には便利なんじゃないかと。
これも、対応してないソフトが悪いんだってことで、EUC完全対応しちゃうべきだろうか。

文字コード判定部分も、EUCの補助漢字、JISのその他のエスケープに対応していない。
この部分については、こうやれば速いだろうなってアイデアはあるんだけど、
それやってたらまたかかり切りになるかなぁ。

まぁ、テキストエディタなんだから、文字コードに関する部分はかかり切りになってもいいけどね。
まだ萌ディタの開発日記からヒントを得たTODOがいっぱいあるが、ここから進まない。

4899770510