Code owners previously using the InvariantCulture for string comparison, casing, and sorting should strongly consider using a new set of String overloads in Microsoft .NET 2.0. Specifically, data that is designed to be culture-agnostic and linguistically irrelevant should begin specifying overloads using either the StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase members of the new StringComparison enumeration. These enforce a byte-by-byte comparison similar to strcmp that not only avoids bugs from linguistic interpretation of essentially symbolic strings, but provides better performance.
Thanks, Eugenia! That is quite useful, since the general idea applies to any string handling wanting to support internationalisation in a sane way.
These enforce a byte-by-byte comparison similar to strcmp
How the heck else would you compare strings?
It is intresting, like once Java, Turkish “I” (and dotless “i”) problem haunts .Net too. In JDK 1.4 code in the String.toUpper and toLower methods there were spesific piece of code just for tr locale and I character i remember. later in Java 5 they made a more generic approach and 2 more additional languages. Too bad you cannot see .Net code to understands what they really do.
But every now and then in Linux, Windows, and all the computer related stuff you can see this problem popping up.
for the “i” character, i wonder who’s fault is this, the turkish government who decided to change the alphabet completely to latin in 1920’s or the “global” companies who design software thinking 128 characters are enough for everything..
If you want the source, download the Microsoft Research version of the Framework. A lot of the code in that is the same as the production code.
http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7…