愛々問題をざっと調べてみた
id:kkamegawa:20081113:p1 なんてネタがあることをついったで教えてもらったので参戦してみるお。
以下とりあえずの実験に基づく考察。結論はまだ出ていません。
- String.IndexOf()は、culture sensitivityのオプションを問わず、System.Char配列におけるインデックスを返さなければならないのだから、1を返すのは仕様ではなくバグ。
- StringComparison.Ordinalでは問題ない。（当然か）
- 日本語ロケールでのみ発生する問題。CultureInfo.InvariantCultureやzh-CNでは問題なし。
- .NET 1.1では問題なし。（確認）
- .NET 1.1で返されるSortKeyの値と、.NET 2.0で返されるSortKeyの値は同一。
- ということは、ソートテーブルやnlpファイルに基づくculture dependentなtailoring*1の問題ではないと思われる。
- XMLと文字MLでは愛々が1文字ではないかという推測が最初に上げられているけど、これは違うということになりそうだ。
- Windows XPでも再現するので、Windows Vista以降のみでサポートされるLCMapStringExの問題ではないと考えられる。
- .NET 1.1ではLCMapStringを使っているはずなので、Windows XP SP3で導入されたバグというわけでもないだろう。
気が向いたらまた実験してみる。
ちなみに、.NET 4.0では文字列処理はordinalがデフォルトになるそうで、もう何年も前からMSのglobalization担当者が見ているところでそうしろと主張していた僕は、ようやく来たかと思ったのであった。
おまけ: 半角かなの'ワ'に半濁点の'゛'が続く文字列から半角かなのワだけ（culture sensitiveな）IndexOf()で探すと見つからないという問題は、この文字シーケンスがUnicode文字のU+30F7と見なされるからであって、これはMicrosoftが正しい。Unicodeの文字列照合の実装でもこうなるべき。
たぶんCompareInfoの実装の問題だと思う。
追記: id:kkamegawa:20081119:p1
monoではどうなんでしょうと言ってみる。
いやあ、普通に2を返しますです:p もう実装したのが3年以上前なのでうろ覚えですが、ja-JPに特化したロジックは入れなかった気がする。日本語に特化したソーティングはInvariantCultureのレベルで.NETでも共通実装になっていますので、日本語環境で問題が起こるとしたら基本的にはja-JP用sortkey tableの問題になり、おそらく今回のような問題の出方はしないでしょう。まあ、この種のバグは実装に手を入れれば自然発生するもんです（monoでも実装してしばらくはいろいろバグレポートされましたし）。
