.NET 如何正确比较表示文件名的两个字符串，忽略大小写
鉴于（至少在 NTFS 上）Windows 上的文件系统不区分大小写，我想将 String fileA 与 String fileB 进行如下比较：
fileA.Equals(fileB, StringComparison.CurrentCultureIgnoreCase)
然后问题就变成了我选择哪种文化应该使用，默认的当前（ui？）文化是否足够？我似乎找不到任何用于此目的的 BCL 方法。
Given that (at least on NTFS) the filesystem on Windows is case insensitive, I would like to compare String fileA to String fileB as such:
fileA.Equals(fileB, StringComparison.CurrentCultureIgnoreCase)
The question then becomes which culture I should use, does the default current (ui?) culture suffice? I can't seem to find any BCL methods for this purpose.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
根据最佳实践，您应该使用
StringComparison.OrdinalIgnoreCase在 .NET Framework 中使用字符串。如果您使用区域性来匹配字符串，您可能会遇到这样的情况，例如名称“häl.gif”和“hal.gif”将被视为匹配。
You should use
StringComparison.OrdinalIgnoreCase, according to Best Practices for Using Strings in the .NET Framework.If you use a culture for matching the strings, you may get in a sitation where for example the names "häl.gif" and "hal.gif" would be considered a match.
这是不可能可靠地做到的。
是的，文件系统的大小写转换不区分大小写。
但是大小写转换表存储在文件系统本身上（对于 NTFS），并且它在版本之间确实会发生变化（例如 Vista 大小写转换表被带到了 Unicode 5 级别，因此 Vista NTFS 和 XP NTFS 有不同的大小写转换规则）。
重要的是格式化文件系统的操作系统，而不是当前的操作系统。
然后你可能会遇到其他文件系统的各种问题（Mac OS 执行某种 Unicode 规范化（不是标准的）），Linux 不执行任何操作，但 Samba（实现 Windows 文件共享协议）执行此操作。并且有除 Windows 之外的其他表。
那么如果我将一个盘符映射到Linux或Mac OS共享的网络磁盘上会发生什么呢？
一般来说，您永远不应该尝试比较文件名。如果您想知道它是否存在，请尝试访问它。
This is not possible to do reliably.
Yes, the case conversion for the file system is case-insensitive.
But the case conversion table is stored on the file system itself (for NTFS), and it does change between versions (for instance the Vista case conversion table was brought to the Unicode 5 level, so Vista NTFS and XP NTFS have different case conversion rules).
And the thing that matters is the OS that formatted the file system, not the current OS.
Then you can run into all kind of problems with other file systems (Mac OS does some kind of Unicode normalization (not the standard one)), Linux does not do anything, but Samba (implementing the Windows file sharing protocol) does. And has other tables than Windows.
So what happens if I map a letter to a network disk shared by Linux or Mac OS?
In general you should never try to compare file names. If you want to know if it is there, try to access it.
Marcus，
您可能想看看另一个 StackOverflow 问题的答案，该问题非常相似：Win32 文件名Comparison ，其中又提到了 http://www.siao2. com/2005/10/17/481600.aspx。
按照同一问题的另一个答案中的链接并进一步挖掘，我发现了以下 MSDN 文章 http://msdn.microsoft.com/en-us/library/ms973919.aspx。一般而言，值得一读，但当涉及文件名比较时，建议使用 StringComparison.OrdinalIgnoreCase。请参阅本文中的表 1，其中包含作为处理的数据类型之一的文件路径或以下引用：
因此，在解释文件名、cookie 或任何其他可能出现类似 å 组合的内容时，序数比较仍然提供最透明、最合适的行为。
希望这有帮助，
波阿斯
Marcus,
You might want to at look at the answer for another StackOverflow question, which is very similar: Win32 File Name Comparison , which in turn mentions http://www.siao2.com/2005/10/17/481600.aspx .
Following a link in another answer to the same question and digging further, I came across the following MSDN article http://msdn.microsoft.com/en-us/library/ms973919.aspx . It is worth a read in general, but when it comes to file name comparison it recommends using StringComparison.OrdinalIgnoreCase. See Table 1 in the article, which contains file paths as one of the data types handled or the following the quote:
So, when interpreting file names, cookies, or anything else where something like the å combination can appear, ordinal comparisons still offer the most transparent and fitting behavior.
Hopes this helps,
Boaz
也许你可以尝试这个：
http://msdn.microsoft.com/en-us/library/zkcaxw5y。 ASPX
Maybe you could try this:
http://msdn.microsoft.com/en-us/library/zkcaxw5y.aspx
您可以使用 InvariantCulture （查看 http://msdn.microsoft.com/en-us/library/4c5zdc6a.aspx）。
在你的例子中：
You could use InvariantCulture (look at http://msdn.microsoft.com/en-us/library/4c5zdc6a.aspx).
In your example:
我试过这个。
I tried this.