(続き）
というものです．「都」という文字が隣り合わせで異なるソート順の重みで指定してあるというのです．入力データは数百KBもあるのでデバッグも大変．しかもいくら見ても「都(U+90FD)」は一回しか使っていません．ついにjava.text.RuleBasedCollatorのソースコードを自分でJDKから引っ張り出してきてビルドし、デバッグする羽目になりました．すると該当のメッセージを出している箇所の前で、RuleBasedCollatorのコンストラクタに与えたソート順定義文字列を「正規化」しているではありませんか！犯人はこれでした．実は、ソート順定義文字列の中に、"< \u90FD < \uFA26"というくだりがあります．U+90FDは先ほども説明したように「都」ですが、U+FA26はこの異体字で、「者」の部分に一箇所「、」が加わっています．なんとこのU+FA26が正規化されてU+90FDになってしまい、同じ文字に異なったソートの重みをつけていると判断されて落ちているのです．
相手がJavaのシステムライブラリなのでうかつに触れませんが、仕方がないのでこの正規化のコードをはずして試してみました．すると今度は配列の添字エラーでこけてしまいます．こうなるともう素人にはほとんど手がつけられません．
最後の望みはICUです．
最新のicu4j-4_8.jarを落とし、RuleBasedCollatorをcom.ibm.icu.text.RuleBasedCollatorに変えて、あとは少しコンストラクタに与えるソート順定義文字列を変更します．（JavaとICUのRuleBasedCollatorは完全コンパチではないため）するとRuBasedCollatorのインスタンスの生成は一発で成功しました．さすがIBMのICU! これでJavaのjava.text.RuleBasedCollatorは捨てて、ICUで行くことに決めました．
でもJavaのRuleBasedCollatorがコンストラクタの文字列を正規化してしまっているのかよくわかりません．ラテン文字の場合はありえるのかもしれないけれど、CJKの入力の場合は正規化してしまってはせっかく苦労して作ったデータが元も子もなくなってしまいます．こんど時間があったらOracleに聞いてみようかなと考えています．
