Windowsのsortkey tableを体系的に構築するのは、地味な作業でいて、その割にそれぞれの言語について、きちんと理解していないと難しい。これは、cultureに特化したテーブルについてはもちろんだけど、InvariantCultureのデフォルトテーブルについても言えることだったりする。大変だ。cultureに特化したテーブルなら、まあ未実装でもユーザーが居ないからさあ、といって言い逃れできるのだけど、InvariantCultureのテーブルが埋められないと、ちょっと困る。
で、今どんな作業をしているかというと、これらの文字とsortkeyの値から、何らかの法則性を見いだして、sortkeyのテーブルを計算できるように数式化するという、何か冷静に考えると気の遠くなりそうな作業だ1。これは時間がかかりすぎるようなら（ていうか間違いなくかかる）てきとーに流してしまおうと思っているのだけど、まあ多少はあがいてみてもいいだろう。と思っている。2
たとえば、僕は日本人だから、
- 半角カタカナの’ア’(FF71)のsortkeyが FF 02 C4 FF C4 FF 01 00 で
- 全角カタカナの’ア’(30A2)のsortkeyが FF C4 FF 01 00 で
- 全角ひらがなの’あ’(3042)のsortkeyが FF FF 01 00
で終わり、「その前にはいずれも 22 02 01 01 01 C4 が付く」ことを理解できる3し、従って同じルールに基づいて「イ」以降の文字についても、計算式を立てることができる。カキクケコにはガギグゲゴがあるけどナニヌネノには濁点は付かないことも知っている。
だけど、韓国語や中国語のsortkeyがどのように計算されているかは、全く分からない。詳しい人ヘルプぷりーず、とそのうち本家で投げようと思っている。
ちなみに、日本語でも、かな文字の「ん」の後に続く文字のsortkey順序が以下のようになっていると、一見してさっぱり分からない4:
- 22 97 01 01 01 01 00 : 3349, ㍉
- 22 98 01 01 01 01 00 : 3314, ㌔
- 22 99 01 01 01 01 00 : 3322, ㌢
- 22 9A 01 01 01 01 00 : 334D, ㍍
- 22 9B 01 01 01 01 00 : 3318, ㌘
- 22 9C 01 01 01 01 00 : 3327, ㌧
- 22 9D 01 01 01 01 00 : 3303, ㌃
- 22 9E 01 01 01 01 00 : 3336, ㌶
実はこれは（また）JIS X 0208の順序とかぶっていたりする。こんなの日本人でもすぐには気づかねーって。で、そこまで分かっても、例によって文字マッピングが存在しないものについては、もう本当に分からない。たとえば3302, 3300, 3301辺りは本当に意味不明だ。
この辺を調べた結果が全てmcsのおれおれブランチのCollation-notes.txtに書かれているのだけど、まだまだ完成からはほど遠い。