CP 51932の実装

昨日書いた「WindowsのEUC-JP、「CP 51932」について」の続きです。


gTefの開発を始めてかなり経ちますが、全く実用にならない符号を実装したのは、今回が初めてです。
結構苦労して実装してますが、自己満足以外に何の意味があるのでしょう。

入力と出力

そういえば書き忘れたので、この辺をまず書いておきます。
このシステムでは、入力をEncode、出力をDecodeと呼んでいます。
ローカル符号を基準と考えると、表現が逆のように思われますが、これは内部符号を基準に考えているからです。

内部符号は独特のMIXTUREという符号であり、この存在がこのシステム最大の特徴です。
他の符号をDLLに与えるとMIXTUREが得られ、MIXTUREをDLLに与えると他の符号が得られる。
つまり、この符号に変換するEncode処理と、この符号をDecodeして他の符号にする処理が、存在するわけです。

従って、他の処理系なら「○○デコーダ」と呼ばれるものは、このシステムでは「○○からMIXTUREへのエンコーダ」のように表現されます。

CP 51932の入力

昨日作った処理を、更に改良？した。
2バイト目は必ずしも半角カナではなく、0x81〜0x9f、0xe0〜0xfcで、次の漢字の1バイト目にも成り得るため、この範囲内の場合は更に1バイトを要求して出力するよう、内部の改造をした。

Microsoft的には楽な処理にした結果だったのでしょうが、このバグといっても過言ではない処理を他が実装するのは、なかなか難儀なことでありました。


一応、いろいろな可能性を試験して、ほぼ同じ動作をしているように思われたため、Encodeは完成としました。

CP 51932の出力

今日は新規に出力を書いた。
関数自体はEUC-JPと共通で、必要な箇所に処理を書き足した。

結果として
・ASCII文字は良い
・JIS X 0208も良い
・JIS X 0201カナ(半角カナ)も良い
・JIS X 0212は出力しない
・JIS X 0213も出力しない
・IBM拡張文字は、NEC選定IBM拡張文字の符号位置で返す
そして
・ユーザー定義外字は、シフトJISの符号で返す(!)

なんという間抜けな仕様でしょう。
少なくとも実用にはなりません。