从他们的简要描述来看，字符串比较规则StringComparison.Ordinal 和StringComparison.InvariantCulture 的意思是它们对字符串的排序 方式有所不同。那是全部吗？也就是说，这是否意味着我们可以在进行相等比较时使用任一字符串比较规则？
string.Equals(a, b, StringComparison....)
另外，如果我们比较 OrdinalIgnoreCase 和 InvariantCultureIgnoreCase，答案是否会有所不同？怎么样？
请提供支持论据和/或参考资料。
【问题讨论】：
标签： .net string equality string-comparison culture
这确实很重要，例如 - 有一种叫做字符扩展的东西
var s1 = "Strasse";
var s2 = "Straße";
s1.Equals(s2, StringComparison.Ordinal); // false
s1.Equals(s2, StringComparison.InvariantCulture); // true
使用InvariantCulture，ß 字符将扩展为ss。
【讨论】：
String.Equals(s1, s2, StringComparison.OrdinalIgnoreCase) 似乎是最好的不区分大小写的替代(s1 == s2)。
嗯，这当然很重要。当您使用“忽略大小写”相等比较时，您将调用 .NET 框架中的大量代码，这些代码知道大小写规则在当前文化中的工作方式。对于像我这样的前邮票收藏家来说，其中的规则非常有趣，有一些非常奇怪的规则取决于你在哪里看。土耳其语 I 问题很有名，Unicode 的家伙必须为他们做出明确的例外。
顺便说一句，它实际上不是代码，而是查找表。它本身很有趣，因为它需要 MSFT 来维护 C# 编译器的 /linkres 命令行选项。您不能在自己的项目中使用的编译选项。它只是为了让 mscorlib 能够找到 .nlp 文件，即文化规则的转换表。与mscorlib.dll存放在GAC同一个子目录下，编译选项的效果。
但我离题了。按理说StringComparison.OrdinalIgnoreCase 比 StringComparison.InvariantCultureIgnoreCase 快一点。仅仅因为“不变”意味着美国，MSFT 的故乡。很难测量，这以纳秒为单位。 StringComparison.CurrentCultureIgnoreCase 命中那些翻译表。第一次使用时速度很慢，以后使用时会变慢。
【讨论】：
关于额外学分问题
Comparison confusion: INVARIANT vs. ORDINAL
... 添加了 Ordinal 排序的概念，并将 Ordinal 成员添加到 CompareOptions 枚举中。选择它会忽略所有这些文化整理功能，并为您提供一个二进制排序，顺便说一下，它不会变化。
string comparison InvariantCultureIgnoreCase vs OrdinalIgnoreCase?
C#: String comparison guidelines and common usage
该建议指出，对于与文化无关的比较，请使用 Ordinal 和 OrdinalIgnoreCase 比较。这些既快速又安全。它们依赖于字节匹配，是匹配字符串以进行内部（非 UI）处理的绝佳选择。
【讨论】：