検討中
将来的に、
UnicodeのNormalizationの処理を搭載する予定でいます。
なので、改めて仕様の確認をしているところです。
unicode.orgの
NormalizationTest.txt(試験用ファイル)を見ると、part0から3で、18000種程度の定義がある。
この表を処理しやすいようにコンパイルしてしまえば、あとは処理を書くだけだろうかとも思ってみましたが、思っただけで、実際には相当難しそうです。
特に、part2の処理はもはや変換表だけで済む問題には思えません。
あと、正規化されて出力されたものを改めて入力された場合、合成済み文字にする処理も必要になるのでしょうか。
情報が欠落していなければ処理を作ること自体は不可能ではないと思われますが、かなり大変な気がします。
不明点
Unicode正規化も併せて読んでおりますが、NormalizationTestにはないパターンが記述されていました。
例えば、「平仮名は+半角濁点」(U+306F U+FF9E)で、NFD/NFCがU+306F U+FF9E、NFKDでU+306F U+3099となるのは良いでしょう。NormalizationTestの通りです。
しかし、NFKCで「濁点付き平仮名は」(U+3070)となるのは、NormalizationTestにはないパターンです。
「半角仮名」での説明も同様で、NFKCでは濁点を連結して、いわゆる全角文字相当に変換するようですが、NormalizationTestには当該の記載がありません。
特例だと書かれていますが、このあたりをまとめた資料などはあるのでしょうか。
概案
part1については、Unicode1文字に対するNFC、NFD、NFKC、NFKDへの変換なので、変換表を作ってしまえば、処理自体は難しくないと見込まれます。
part0のUnicode1文字のものも、この変換表に融合できるでしょう。
part0のUnicode2文字のものと、part3は、別に変換表を作った方がサイズ的に都合が良いかと思っております。
しかし前述の通り、part2については、かなり難易度が高そうです。
0061~0062の文字列は例で、ここではaを使った場合の例示をしているようですが、実際には様々な文字に対応せねばならないはずです。
変換表と、プログラム処理の併用が必要になることは明々白々なので、この処理の完成は先になりそうですね。
実装するなら、ですが。
そもそも、このpart2を実装する意味があるのかどうかも良く分からない。
例えば、
0061 3099 093C 0334 093C 0062
に対して、NFC、NFD、NFKC、NFKDが定義されているわけですが、AとBが何であれ、こんな文字列になることは有り得ないので、苦労して実装する意味は殆どないのでしょう。
恐らく、「もし万一このような連結可能文字があった場合は、このような優先度をもって並べ直す」といったようなことを、言いたいのだと解釈しております。