漢字以外の文字を考える。漢字以外とはつまり、ひらがな・カタカナ、および一部の全角文字……にしようと思っていたが、せっかく漢字の読みについては Unicode のデータを参照するようにしたのだから、こちらもそうしよう。
ひらがな・カタカナについては、UnicodeData.txt を参照する。これらの読みのデータは入っていないが、文字名が “HIRAGANA LETTER KA” とかなのでそこを取り出す。ちょっと強引。
残りの文字も UnicodeData.txt から取り出すのだが、bmp 全体を対象にし、データベースの 5 番目のフィールド、Decomposition_Type と Decomposition_Mapping を参照する。Decomposition_Mapping の先頭の文字が Latin-1 の U+0020 から U+007F であれば、fFtT の対象にする。ちなみに先頭の文字をただ取り出すのではなく、Decomposition できなくなるまで再帰的に変換する必要がある。
生成するデータの構造は、bmp のコードポイント 2 バイトと、変換先文字のコードポイント 0x20 から 0x7f の 1 バイトで計 3 バイト。
というわけで生成させてみたところ、1574 文字分、4722Bytes のデータができた。あら小さいのね！
これによって生成したデータにより、例えば㍇とか①とかʣといった特殊な文字でも、それぞれ Latin-1 の文字 m、1、d を対応させることが可能になる。これはつまり、例えば一般的な日本語の文章でも、下記のように Latin-1 の文字を使って各文字に自由に fFtT できるようになるということだ。
a a m ! f w m m ! !
ああ㍇！ ふわ㍉ ㍇！！
j a
k d g
m o h k k
j s s i m n m
y t m m d t w m t n i z k t h m o r w s i t
柚純㎟まだ終わ㍇てないぞ 今度は㎟後ろを向いて
たださらに微調整の余地はある。助詞としての「は」は w で飛べたほうが自然かも。濁点や半濁点付きの半角カナに対応していない。悪名高い円記号とバックスラッシュの問題。また、上の例の「後」のように、「うしろ」と読めるはずなのに u が定義されていない、Unicode の仕様自体の不備も気になる。もっとも、Unihan_Readings.txt 内の kJapaneseOn と kJapaneseKun は status:Provisional だそうなので文句を言うわけにもいかないのだが。
ちなみに変換表は
となっている。漢字のほうはそれなりにでかいので注意。