【问题标题】:Why are string in .net case sensitive by default?为什么.net中的字符串默认区分大小写?
【发布时间】:2010-12-13 23:47:07
【问题描述】:

大多数时候我想进行字符串比较,我希望它们不区分大小写。

那么为什么.net中的字符串默认区分大小写呢?

编辑 1: 为了清楚起见,我认为下面的内容应该默认返回 true。或者至少允许我有一个编译时标志来做到这一点。

"John Smith" == "JOHN SMITH" 

编辑 2:我可以想到更多不区分大小写的示例

不区分大小写的示例

  • 用户名
  • 网址
  • 文件扩展名/文件名/目录名/路径
  • 机器/服务器名称
  • 州/国家/地区/地点等
  • 名字/姓氏/缩写
  • 指南
  • 月/日名称

应区分大小写的示例

  • 密码

【问题讨论】:

  • @bryan。你是对的,这是我的经验。虽然与金钱相比并不准确
  • +1 关闭。与开始诚实的调查相比,表达对决定的不同意见似乎更有趣。
  • URI 不区分大小写,只有域和方案部分。 GUID 可能应该作为 GUID 而不是字符串进行比较,这也是一个有争议的问题。
  • @Simon:说"John Smith" == "JOHN SMITH" 应该返回true表示你不同意。你愿意使用 IL weaving 来颠覆语言决策,这表明了一种不屑。问题的这些属性往往会导致主观和争论的答案。我知道您在问为什么做出这个决定,但您的方法很重您的意见。
  • @tekiegreg:它给用户带来的烦恼多于安全性。至少在迄今为止我见过的任何真实系统中。他是对的,对于用户来说,几乎没有什么东西应该强制区分大小写。但对于通用编程语言,我想这是一条错误的路。

标签: .net string case-sensitive case-insensitive


【解决方案1】:

对不起,这个琐碎的答案,但这就是它的方式:)

在基本级别上,字符串表示为字符列表,其中“a”与“A”不同,因此它可能是最简单的表示 \ 总体约定。在您的情况下,可以公平地说大多数比较是不区分大小写的,但我认为论点的另一面至少同样适用,并且已经采用了约定。

我想使用一些辅助方法\类会稍微减轻你的痛苦。

【讨论】:

  • 那么您的回答是“他们没有考虑过”还是“出于性能原因”?
  • @cristobalito 我不想要辅助方法。我希望 "John Smith" == "JOHN SMITH" 返回 true。
  • 我想这主要是一个历史问题 - 这是它一直以来的做法,也是人们可能期望的。如果 "abc" == "ABC" 开箱即用返回 true,我会感到非常惊讶。此外,正如您所提到的,它的计算成本也更高,而且,我猜当您开始考虑 unicode 时,您可能会开始遇到更多问题。
  • @simon 但是约翰史密斯不等于约翰史密斯。好吧,不要对着电脑
  • @Simon - 对于开箱即用的此类功能,我认为您需要更改语言。我想不出我的头顶之一(html?)
【解决方案2】:

因为有不同类型的不敏感匹配,不清楚你想要哪一种。以下是三种最常见的模式:

StringComparison.OrdinalIgnoreCase
StringComparison.InvariantCultureIgnoreCase
StringComparison.CurrentCultureIgnoreCase

它们有截然不同的用例。您可能没有注意到太多,因为您每天都在处理 ASCII。其他地区的用户看到的差异更大。

【讨论】:

    【解决方案3】:

    因为不区分大小写的性能不佳,而且即使您不打算这样做,它也可以工作。

    供应商需要根据性能进行竞争,因此默认选项往往是性能最佳的选项。充其量,不区分大小写需要在比较之前将两个字符串折叠成一个常见的大小写。在最坏的情况下,根据语言环境,它需要一个可能是两倍长的代码路径。如果供应商默认使用性能较低的版本,竞争对手会选择最坏的情况进行基准测试。

    由于某些搜索不区分大小写,您必须在代码中解决此问题。它迫使人们做出有意识的决定。相反,不区分大小写是有效的,即使在您不希望它这样做的情况下也是如此。它不是强迫你做出决定,而是创造了一个你可以忽视它而对你不利的场景。作为选择架构的问题,供应商倾向于选择导致更少缺陷的选项 - 在这种情况下是区分大小写。

    【讨论】:

      【解决方案4】:

      .Net 中的字符串比较区分大小写,因为字符串(和单个字符)本质上是区分大小写的。

      字符“a”在内部存储为与“A”不同的 ASCII 或 Unicode 值。说 'a' 和 'A' 一样不是“正确的”。

      在比较非英语语言的值、使用哈希表等算法或使用许多加密/解密算法时,这种区别变得至关重要。

      我的两分钱:区分大小写的比较是默认的,因为它是正确的。

      【讨论】:

        【解决方案5】:

        在 VB.NET 中,可以将“选项比较”设置为文本以不区分大小写,但我强烈反对这样做。我最喜欢的只是当我需要不敏感地比较并读取文本的小写版本时使用 string.toLower() 方法。

        为什么?因为在某些应用程序中区分大小写很重要时,您还会如何比较?

        【讨论】:

        • 为什么不使用内置的 string.Compare(string, string, bool) (msdn.microsoft.com/en-us/library/zkcaxw5y.aspx)
        • “当区分大小写很重要时,您将如何比较它在某些应用程序中的重要性”使用 string.Equals(a, b, StringComparison.CurrentCulture);而不是 string.Equals(a, b, StringComparison.CurrentCultureIgnoreCase);
        • a.Equals(b, StringComparison.OrdinalIgnoreCase) 应该比对字符串执行 ToLower 更好。
        • 好点,没想到这些。但是我正在研究一个仅使用不区分大小写的语言的假设场景,让我们暂时假设没有办法声明或强制区分大小写,现在怎么办?
        【解决方案6】:

        您无法更改现有类的行为。在 mscorelib/system.core 中定义的 System.String 类覆盖 == 并定义区分大小写的相等性。

        你所能做的就是给字符串添加一个扩展方法并实现不区分大小写:

        public static class StringEqualityExtension
        {
            public static bool StringEquals(this string value, string other)
            {
               return value.ToLower()==other.ToLower();
            } 
        }
        
        // usage
        string myString = "Some112";
        string other = "sOME112";
        
        bool equal = myString.StringEquals(myString);
        

        【讨论】:

          【解决方案7】:

          您的情况不一定是最常见的情况,一个非常常见的情况是根据语法条件匹配文档中的单词,在这种情况下区分大小写是绝对必要的。

          以不区分大小写的方式进行笔记匹配非常简单。事实上,字符串的 equals 方法有一个重载,专门用于指定如何比较。

          【讨论】:

            【解决方案8】:

            我知道这是在发布尸体,但是

            我来这里是为了寻找相同问题的解决方案。现在已经快 5 年了……但我不介意,因为这是最早的搜索结果之一,我认为最好包含正确的信息。

            根据this MSDN page,您只需在文件中添加 1 行代码:

            Option Compare Text
            

            如果您将上述行添加到核心的开头,您就是在告诉 CLR 从默认 (Option Compare Binary) 切换到不区分大小写的比较。

            我不知道这是否可以在 C# 中工作。

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2010-09-05
              • 1970-01-01
              • 2022-11-22
              • 2015-08-31
              • 2016-01-26
              • 2016-04-02
              • 2011-11-17
              • 1970-01-01
              相关资源
              最近更新 更多