不定記

• Ａ ｔｏ Ｃ プログラム集 for ＭＳＸ
• 蟲取り日記
• MSX資料室
• Junk Programs
• Top page

1999年4月 / ... / 8月 / ... / 2000年12月

1999年8月

1999/08/10

文字コード。説明が下手なので、結論だけ読むのも可です。
とりあえず交換用のコードはISO-2022-JPでいいし、ローカルではShiftJISやEUC-JPが標準になっているわけで、まぁ間に合っている(むしろ多すぎる)。問題はプログラム内部で使うコードなのだが、ShiftJISやEUC-JPでは困る場面が少なくない(ISO-2022-JPは柔軟過ぎて、困るケースの方が多い)。
以後、1byte文字をS、2bytes文字の1st byte, 2nd byteをそれぞれD1, D2と表記してみる(例えば、"99年8月"という文字列は、"S S D1 D2 S D1 D2")。

さて、文字を単純に検索し、見つかった場所以降を表示したい場合。表示するには、見つけた文字がS,D1,D2のどれなのか判別しなければならないが、これが難しい。
ShiftJISでは、D2にSやD1と同じコード領域を使うため、ある(D1ではない)1byteを見て、それがSなのか、D2なのか判別するのは、かなり面倒で効率の悪い作業である(Sが連続している場所まで後方検索する)。EUC-JPにも似た問題があり、ある2bytes文字"D1 D2"を見つけたとして、それが本当に"D1 D2"なのか、"D1 D2 D1 D2"の"D2 D1"を誤認しているのか区別するには、ShiftJISと同じような手法を使わなければならない(Sが見つかるまで後方検索)。

理想を言えば、件の1byteを見ただけで区別出来るのが望ましいが、これはどうも無理らしい。で、妥協して、1byte前を見れば区別できるコードを考えた。中身は非常に単純で、EUC-JPのD2が配置される領域をSと同じ21H〜7EHにずらしただけである(本来のEUC-JPではD1と同じA1H〜FEH)。なお、拡張漢字の3bytesコードは考えない(弱いぞ)。
この方法なら、D1が2bytes文字のleading byteとして使えるので、順方向に見ていく分には常にS,D1,D2の区別がつき、EUC-JPと同様に扱える。そして、任意の1文字を取り出した場合も、以下の表のように1byte前を見るだけで常に判別可能である(D1とS/D2はその1byteを見るだけで判別できる)。

要はファイルを読み込む時、このコード系に変換して格納していけば便利という事だが、まだ一つ問題が残っている。いわゆる、1byte片仮名の扱いである。
EUC-JPの場合、1byte片仮名は2byteコードとして扱われる。今回のコード(名前はまだない)の場合も同様で、D1が8EH固定、D2が21H〜5FHに割り当てるのが妥当である。従って、漢字と同じ様に扱えばそのまま使えなくはないが、表示の事を考えると半角文字が2bytesの内部幅を持つ状況は好ましくないような気がする。変換処理に必要なバッファの大きさとかね。
そんなわけで、1byte片仮名を1byteで扱え、かつ前記のコード系と同様のメリットが得られる方法を考えてみた。

まず、ASCII(128文字)と1byte片仮名(64文字)をShiftJISと同じ領域に配置すると、D1として使えるのは64文字=6bitである。漢字は14bitで表現されるから、D1に上位6bitを置くと、D2は8bitフルに使う事になり、S/D2とD1が区別出来なければならないという目的から外れてしまう(S/D1とD2の領域が重なるので区別できない)。
しかし、漢字の表現幅が14bitあるとは言え、実際には文字の入っていない領域があり、うまく詰め込めばbit数を減らせる。例えば、MSXの漢字ROMを読み出すときに使う漢字コードは、13bitで第一水準・第二水準のすべての文字を表現できる。これを使って、D1に6bit、D2に7bitを割り当てれば、問題は解決である。

で、結論。下表の文字コードを使えば、1byte文字・2bytes文字の1byte目・2bytes文字の2bytes目を簡単に判別できる。ただし、漢字コードには、空白領域を圧縮したタイトなコードを用いる(MSXの漢字コード等)。

1999年4月 / ... / 8月 / ... / 2000年12月