WentWayUp: WebLog

ちょっとした機器で漢字を表示したい時、文字のデータをROMに持つことになる。
ROMの容量を抑えたいなら、漢字のレパートリーをJIS第1水準のみに絞ったりするだろう。
その際、使う文字コードが(Shift_)JISならば問題ないのだが、何かの都合でUnicodeを使わざるを得ない場合もある…と思う。
(無いと話が終わってしまうのであることにしていただきたい)
ここで発生する問題が、変換テーブルが巨大になるということである。
UnicodeはJISコードとは無関係に文字が並べられているので、UnicodeでJIS第1水準の文字はバラバラに存在している。
例えばこんなだ。

空白部分を漢字ROMに持つのは無駄なのでROMには詰めて入れるが、そうすると文字コードとの対応を別にテーブルでもっておかなければならない。
これがどれほどのデータ量になるか。
まず漢字ROM本体だが、例えば12×12ドットのフォントを使うとして、JIS第1水準漢字2965文字は2965*12*12/8 = 53370Byte ≒ 53KBとなる。
一方変換テーブルだが、JIS第1水準漢字はUnicodeにU+4E00「一」からU+9F8D「龍」までのおよそ21000文字にわたって分布している。
2965文字を指定するには12bit必要なので、素直に考えれば21000*12/8 = 31500Byte、すなわち32KBと、本体の半分ものデータ量になってしまう。

と、ここまでが前置きで、今回これを解決するアルゴリズムを考案した。タイトルにもあるように、このアルゴリズムは「重畳漢字ROM」と名付けた。
この方式では漢字ROMの容量は少々増えるが(今回のサンプルでは14%増)、変換テーブルの容量を劇的に縮小することができる(32KB→1.3KB)。
仕組みは次のようになっている。
・ROMの番地は12bitある。
・その下位4bitは文字コードの下位4bitと同じである。
・上位8bitは文字コードの上位12bitからテーブルを引いて求める。
つまり文字コードの上位12bitが異なる文字を、番地の上位8bitが同じ箇所に押し込めている事になる。
先に述べたとおりUnicode中のJIS第1水準漢字は飛び飛びに存在しているのでこういうことができるのだ。
図で示すと分かりやすいかもしれない。


ただしこの方式には1つ重大な欠点がある。第1水準外の文字が入力された時でも区別できずに何らかの文字を表示してしまうのだ。
きちんと表示させるためにはデータを事前に調整しなければならず、それならJISに変換すればいいじゃないかということになりかねない。

最後にサンプルを用意した。
テキストボックスに任意の第1水準漢字を入れボタンかEnterを押せば下にその漢字の画像が表示される。わざと第2水準漢字を入れて変な文字が出るのを試すのもよいだろう。
変換テーブルはソースを参照。
コードは単純で、漢字ROM相当の画像ファイルの表示位置をずらして当該文字を出している。
なおこのROMの重畳のパターンは文字の多い順に並べてからナイーブな貪欲法で1つづつ重ねて作ったものである。やりようによってはもっと縮められると思う。