しばらく間が空いたのでおさらいからだ。
この話は、既存のEUC変換では対応してない補助漢字領域に対応することから始まった。
既存の方法では対応してないので、対応するように関数を書いたわけだ。
そのついでとして、JIS変換の関数も書いて、現在の真魚に使用していると。
さて、このJIS変換についてだが、JISにも補助漢字領域ってのがあって対応したいし、
JIS規格だけでもいろんな種類があるしで、やはり自作しなきゃ満足な変換は出来ない。
しかし、その満足な変換は、読み込みにおいてはより多くの規格に対応するが、
書き出しについては、最も有用な1種類の規格で書き出せれば十分である。
すなわち、JISの利用目的はメールなので、メーラー互換で書き出すのが真のJISである。
ということで、EUCもJISも、OSまかせや既存関数を使わないで実装した。

さて、この作ったものを、さらにまた.NETへ移植しようという段階だが、
EUC変換は、OSにやらせると様々な問題が起こることを検証したが、
JIS変換については、書き出しをOSにやらせるとどうなるかを検証してなかったな。
いや、たしか、多くの文字がSJIS経由とは異なっている事までは確かめたはずだが、
どう異なっているのかまでは確かめていなかったはずだ。
読み込みは確かめるまでもなく、OS以上のことをやらせるつもりなので検証しないが、
書き出しについては、OSにやらせても問題起こらないんじゃないかな？という検証ね。
ま、検証といっても例によって、真魚付属のユニコード表作成スクリプトを使用し、
できあがった物を真魚でもぎょえでも保存してみて、比較するだけ。
ぎょえの保存はCP50220を使ったOSによる変換だ。

まず最初に違うのがU+0080だ。
実験目的でしか文章に含まれるはずがない文字なので、通常は問題が起こらないが。
一応JISは7bitコードなので、0x00～0x7Fの文字しか使わない事になっているが、
OS変換は0x80として保存しちゃうので、これはルール違反になる。
違反しても真魚で読み込めるけども、違反だから自動判別は失敗する。
真魚による保存も、マルチバイトの1文字目と認識してしまって、マトモに保存されない。
これはどちらも正解じゃなくて、例えばクエスチョンマークなどに変換すべきだろう。

次に、JIS208からはみ出ちゃった部分の外字とか。
SJIS経由変換だと、これもルール違反だが、8bitに食い込んでしまう。
これがOS変換だと、ちゃんと7bitで変換されてるんだよね。
どういう事なのかなと思って、ATOKの文字パレットで調べてみて気がついた。
例えば㈱という文字がその例だ。
U+3231にあるのだが、SJISでは0x878Aと0xFA58の二箇所にマップされている。
JISでは、0x2D6Aと0x9339が機械的に対応する。
SJISを経由するとはみ出ていた部分の文字は、はみ出ない場所に同じ文字があるようだ。
もちろん読み込みは両方に対応するのが望ましいが、
書き出しは7bitという原則に従い、OSによる変換方法が正しい。

あと、U+D800～U+DFFFの領域だ。
この領域はサロゲートなので、真魚は守備範囲外であり、正解も求めないが。
SJISに変換するとクエスチョンマークになるので、経由すれば同じくクエスチョンマークだ。
OSにやらせると何も文字がなくなってしまう。

最後に半角カタカナの問題だ。
OSに変換させても、半角カタカナは全角に自動的に修正されるようだ。
ただし、濁点のついた文字を1文字として変換はしてくれないみたい。
よって、自前で作った半角→全角の変換は残さなきゃいけない。

ということなのだが、ルール違反をしないで、不具合なく簡単な変換をまとめると、
まず、ユニコードの時点で自前で半角カナを全角にし、U+0080を潰し、
それをSJIS経由しないでCP50220で変換させるってのが良いようだ。
というわけで、真魚のJIS変換書き出しもそういう仕様に変更する。
具体的には、U+0080をクエスチョンに変え、外字等を7bitの同じ文字で保存するようにする。
影響するのは、テキストをバイナリエディタで見てる人や文字以外を求める人だけ。
いま.NETに移植しようとしてる部分もこれをやる。