GetSortKey() is a hack

invariantCompareInfo.Compare ("A\u0308\u0301", "\u1EA6");

ベタっと書くと、前者は"Ä́"で後者は"Ầ"。戻り値は0。

うーん、本当にこれで本当にUCAよりWindows collationの方が優れていると言えるのか? 正常系としてはAに対してdiaeresisとacuteが同時に付くことは無いようではあるけどさ。だんだん信用ならなくなってきた。

というわけで、sortkeyの解析を続けているのだけど、level 2のsortkeyの値については非常にやっつけっぽい実装になっているなあと感じる。nonspacing markが連続した場合、そのlevel 2の値は単純にprimary weightを持つ文字のlevel 2の現在値に加算される。そして256を超えるとあふれた桁を無視して0に戻る。

そもそもnonspacing markだけでも256文字以上存在するので、1バイトですむって事はかなりあり得ない*1のだから、やっぱ設計上無理があるだろうと思う。

そんなわけで日本語だのタイ語だのアラビア語だのには特別な加算処理が行われているんだとずっと思っていたけど、どうもそうではなく、みんな単純に加算されているだけっぽい。これらのlevel 2の値が単に1とか2とかなのね。

*1:理屈としてはlevel3以降に違いをもつことがあり得るので不可能ではないが、case insensitiveになれば同一になるnonspacing markというのは滅多に存在しない。存在はしていたと思う（けど定かではない）。