UnicodeNormalizer作成中 - やればできる子の日記

JavaScriptで動くUnicodeNormalizerを作成中であります。
[http://blog.livedoor.jp/dankogai/archives/50783210.html:title=JavaScriptではU+10000以上の文字をサロゲートペアで扱う必要があるという衝撃的な事実を知って、道理でユニットテストの勝率が上がらないわけだと納得した次第です。"\u10000"って、"\u1000" + "0" と等価だって知ってました?

Normalizeを行うにはUnicodeで定義されてる変換データを保持する必要があり、これが結構巨大になります。データ形式次第だけど500KB±200KBくらい。そんな巨大データを必要とするJavaScriptのライブラリって、かなり嫌ですよね。なので、データを小さくしようと考えていました。
一番最初はコードポイントを整数で書いていたのですが、コードポイントが大きい文字を扱うときに、5〜6byteも要してしまう(BMPでも5byte必要)というのが嫌だったんですよね。なので、コードポイントでなく文字を直接書くようにしたのですが、サロゲートペア問題があること、サロゲートのペアをUTF-8で表現すると一文字あたり6byteが必要な上に、''や""で囲む必要のある場合は+2byteも必要だと言うことに気づき、結局コードポイントを各方式に戻しちゃいました。
現在のところ、こんな感じのデータ形式になっています。各コードポイントに対し、Decompose後の文字列(コードポイント)、カノニカルクラス/互換フラグ/除外フラグの値、Composition時のTRIEデータの配列が作成されております。

{8189:[[180]],8190:[[32,788],256,{768:8157,769:8158,834:8159}],8192:[[8194]], //(以下省略)

もうちょっとなんとかならんのかと思いますよね……。
コードポイントを10進数でなく64進数で表現するとかやれば多少はサイズが小さくなりそうなのですが、括弧やコロンなどもかなり数多いため、他の方法も検討すべきです。

gzip圧縮状態で使ってね、とやればあんまり気にしなくても良いんですがね。
ともかく、このデータフォーマットはとても読みやすい(圧縮かけるととたんに読めなくなる)ので、NFD, NFKD, NFC, NFKCの全てでテストケースを通過するようになってからデータサイズのことは考えるようにしましょう。