Re: 続:.NET FrameworkのCultureと"々"

おくればせながら、 元ネタをよーやく検証しました。

( もちろん ! ) 再現できたので、 Visual Studio & .Net Framework プロダクト フィードバック センターに vote / 検証 / 回避策 それぞれ ++ してきました。

> 一日でトップアクティブバグレポートに躍り出るとは思いませんでした。

私が出した WPF ネタが長らくトップだったのに。 残念じゃ～ (^^;

> なんかわざとやっているのかと思います。

わざとかどうかは別として、 とりあえずは IndexOf() だけみたいですね。
StringComparison を指定できるその他のメソッド Compare(), LastIndexOf(), StartsWith() といったあたりは、 "愛々" では大丈夫そうでした。
→ テストコード UnitTest1.cs ( 7,192 バイト, VS2008 Pro. 以上 )

IndexOf() の挙動不審のイヤなところには、 こんなのもあって…

Assert.AreEqual<int>(0, "愛々,1,2,3".IndexOf("愛"));
Assert.AreEqual<int>(1, "愛々,1,2,3".IndexOf("々"));
Assert.AreEqual<int>(1, "愛々,1,2,3".IndexOf(","));
Assert.AreEqual<int>(3, "愛々,1,2,3".IndexOf("1"));
※ "々" も "," も、 どちらも先頭から 2文字目 (inex=1) なんだそうで。

Assert.AreEqual<int>(3, "愛々愛々,1,2,3".IndexOf(",")); //先頭だけおかしくなる!?
Assert.AreEqual<int>(3, "12愛々,1,2,3".IndexOf(",")); //や、そーでもないぞ。
Assert.AreEqual<int>(4, "愛々12,1,2,3".IndexOf(",")); //なぜ合う?
Assert.AreEqual<int>(1, "愛々12,1,2,3".IndexOf("1"));
※ なんと言えばいいものやら… f(^^;

回避策としては、 コード分析 ( FxCop ) の仰せに従って、 StringComparison を指定してやれば、 大丈夫みたいです。 ( kkamegawa 氏の探し出してくれた全ての文字を検査したわけじゃないので、 万全とは言えないです。 )

"愛々,1,2,3".IndexOf(",") というコードに対して、 コード分析 ( FxCop ) は CA1307 という警告をしてきます。

CA1307: StringComparison を指定します

多くの文字列演算 ( 最も重要なものは Compare メソッドおよび Equals メソッド) では、 StringComparison 列挙体をパラメータとして受け取るオーバーロードが用意されています。

StringComparison パラメータを受け取るオーバーロードが存在する場合は、 このパラメータを受け取らないオーバーロードではなく、 受け取るオーバーロードを使用する必要があります。

言われた通りに、 "愛々,1,2,3".IndexOf(",", StringComparison.Ordinal) としてやれば、 この問題は出なくなるようです。 また、 CA1309 の解説には次のように書かれています。

StringComparison.Ordinal または StringComparison.OrdinalIgnoreCase を指定すると、 文字列比較は非言語的になります。 つまり、 比較を判断する場合に、 自然言語固有の機能は無視されます。 これは、 判断は単純なバイト比較に基づいたものであることを示し、 大文字と小文字の指定、 またはカルチャでパラメータ化される同等の表は無視されます。 その結果、 パラメータを StringComparison.Ordinal または StringComparison.OrdinalIgnoreCase に明示的に設定することによって、 多くの場合、 コードの速度、 正確さ、 および信頼性が向上します。

スピードも上がるそうですから、 今回の回避策とは関係なく、 カルチャに関係無い比較で良い場合は積極的に指定した方がよさそうですね。