开发者

is StringComparison.Ordinal the same as InvariantCulture for testing equality?

开发者 https://www.devze.com 2023-02-03 18:19 出处:网络
From their brief summary descriptions, it sounds like the string comparison rules StringComparison.Ordinal and StringComparison.InvariantCulture are meant to differ in how 开发者_Go百科they do sorting

From their brief summary descriptions, it sounds like the string comparison rules StringComparison.Ordinal and StringComparison.InvariantCulture are meant to differ in how 开发者_Go百科they do sorting of strings. Is that all? i.e., does that mean we can use either string comparison rule when doing an equality comparison?

string.Equals(a, b, StringComparison....)

And for extra credit: does it make a difference to the answer if we compare OrdinalIgnoreCase and InvariantCultureIgnoreCase? How?

Please provide supporting argument and/or references.


It does matter, for example - there is a thing called character expansion

    var s1 = "Strasse";
    var s2 = "Straße";

    s1.Equals(s2, StringComparison.Ordinal);          // false
    s1.Equals(s2, StringComparison.InvariantCulture); // true

With InvariantCulture the ß character gets expanded to ss.


Well, it certainly matters. When you use an "ignore case" equality comparison then you're invoking a fairly massive chunk of code in the .NET framework that's aware of how casing rules work in the current culture. The rules of which are very interesting to a former-postage-stamp collector geek like me, there are some pretty odd-ball rules depending where you look. The Turkish I problem is famous, the Unicode dudes had to make an explicit exception for them.

It isn't actually code btw, it's lookup tables. Interesting in itself because it requires MSFT to maintain the /linkres command line option for the C# compiler. A compile option you cannot use in your own projects. It's solely there to get mscorlib to be able to find the .nlp files, the conversion tables for culture rules. Stored in the same subdirectory of the GAC as mscorlib.dll, the effect of the compile option.

But I digress. It stands to reason that StringComparison.OrdinalIgnoreCase is a wee bit quicker than StringComparison.InvariantCultureIgnoreCase. Just because 'invariant' means USA, home of MSFT. Hard to measure, this clocks in at nanoseconds. StringComparison.CurrentCultureIgnoreCase hits those translation tables. Dead slow when you first use it, just slower when you use them later.


For the extra credit question

  • Comparison confusion: INVARIANT vs. ORDINAL

    ... the notion of an Ordinal sort was added and an Ordinal member was added to the CompareOptions enumeration. Selecting it would ignore all of those cultural collation features and give you a binary sort that would also, incidentally, not vary.

  • string comparison InvariantCultureIgnoreCase vs OrdinalIgnoreCase?

  • C#: String comparison guidelines and common usage

    The recommendation states that for culture-agnostic comparisons use the Ordinal and OrdinalIgnoreCase comparisons. These are fast and also safe. They rely on byte matching and are excellent options for matching strings for internal (non-UI) processing.

0

精彩评论

暂无评论...
验证码 换一张
取 消