在不破坏文件系统或文化的情况下将 URL 规范化为小写？

Question

将 URL 规范化为小写

我希望编写一个将 URL 转换为小写的 HTTP 模块。我的第一次尝试忽略了国际字符集并且效果很好：

// Convert URL virtual path to lowercase
string lowercase = context.Request.FilePath.ToLowerInvariant();

// If anything changed then issue 301 Permanent Redirect
if (!lowercase.Equals(context.Request.FilePath, StringComparison.Ordinal))
{
    context.Response.RedirectPermanent(...lowercase URL...);
}

土耳其测试（国际文化）：

但是除了美国以外的文化呢？我参考了Turkey Test 想出了一个测试网址：

http://example.com/Iıİi

这个阴险的小宝石破坏了 URL 中大小写转换很简单的任何观念！它的小写和大写版本分别是：

http://example.com/ııii
http://example.com/IIİİ

为了使用土耳其语 URL 进行大小写转换，我首先必须将 ASP.NET 的当前文化设置为土耳其语：

<system.web>
    <globalization culture="tr-TR" />
</system.web>

接下来，我必须更改我的代码以使用当前文化进行大小写转换：

// Convert URL virtual path to lowercase
string lowercase = context.Request.FilePath.ToLower(CultureInfo.CurrentCulture);

// If anything changed then issue 301 Permanent Redirect
if (!lowercase.Equals(context.Request.FilePath, StringComparison.Ordinal))
{
    context.Response.RedirectPermanent(...);
}

但是等等！ StringComparison.Ordinal 还能用吗？还是我应该使用StringComparison.CurrentCulture？我真的不确定！

文件名：变得更糟了！

即使上述方法有效，使用当前区域性进行大小写转换会破坏 NTFS 文件系统！假设我有一个名为 Iıİi.html 的静态文件：

http://example.com/Iıİi.html

即使 Windows 文件系统不区分大小写，它也不使用语言文化。将上述 URL 转换为小写会导致 404 Not Found，因为文件系统不认为这两个名称相等：

http://example.com/ııii.html

文件名的正确大小写转换？谁知道？！

MSDN 文章Best Practices for Using Strings in the .NET Framework 有注释（大约在文章中途）：

注意： 文件系统、注册表项和值以及环境变量的字符串行为最好用 StringComparison.OrdinalIgnoreCase 表示。

嗯？ 最好的表现？？？这是我们在 C# 中能做到的最好的吗？那么，匹配文件系统的正确大小写转换是什么？ 谁知道？！！？我们只能说，使用上面的字符串比较可能在大多数情况下都有效。

总结：两种情况转换：静态/动态网址

1. 所以我们已经看到 静态 URLs---文件路径与文件系统中的真实目录/文件匹配的 URL---必须使用仅“最好的代表“由StringComparison.OrdinalIgnoreCase。请注意，没有string.ToLowerOrdinal() 方法，因此很难确切知道什么大小写转换等同于OrdinalIgnoreCase 字符串比较。使用string.ToLowerInvariant() 可能是最好的选择，但它破坏了语言文化。
2. 另一方面，动态网址---文件路径与磁盘上的真实文件（映射到您的应用程序）不匹配的网址---可以使用string.ToLower(CultureInfo.CurrentCulture) ，但它会破坏文件系统匹配，而且还不清楚存在哪些边缘情况可能会破坏此策略。

因此，大小写转换似乎首先需要检测 URL 是静态还是动态，然后再选择两种转换方法之一。对于静态 URL，不确定如何在不破坏 Windows 文件系统的情况下更改大小写。对于动态 URL，如果使用区域性进行大小写转换同样会破坏 URL，则值得怀疑。

哇！有人有解决这个烂摊子的办法吗？还是我应该闭上眼睛假装一切都是ASCII？

Answer 1

我将挑战这里的前提，即尝试将 URL 自动转换为小写的任何实用程序。

完整的 URL 是否区分大小写完全取决于 Web 服务器、Web 应用程序框架和底层文件系统。

您只保证在 URL 的方案（http:// 等）和主机名部分不区分大小写。请记住，并非所有 URL 方案（例如 file 和 news）都包含主机名。

服务器的其他所有内容都可以区分大小写，包括路径 (/)、文件名、查询 (?)、片段 (#) 和权限信息（@ 之前的用户名/密码在mailto、http、ftp 和其他一些方案中）。

Answer 2

你有一些不相容的目标。

1. 具有区分区域性的小写字母。如果土耳其语看起来不好，你不想知道一些格鲁吉亚文字，别介意ß要么大写成SS，要么不常见到SZ——在任何一种情况下都有一个完整的大小写-folding where lower("ß") 将匹配 lower(upper("ß")) 您需要认为它至少等同于那些两个字符序列中的一个。一般来说，如果可能，我们的目标是折叠而不是降低大小写（这里不可能）。

2. 在非文化敏感的上下文中使用它。 URI 最终是不透明的字符串。他们可能具有人类可读的理解对于编码人员、用户、搜索引擎和营销人员等都是有用的，但他们的最终工作是通过直接区分大小写的比较来识别资源。

3. 将此映射到 NTFS，它具有基于 $UpCase 文件中映射的保留大小写敏感性，它通过比较 大写 形式的单词 (至少它不必以文化不敏感的方式决定 Σ 是小写到 σ 还是 ς。

4. 大概在 SEO 和人类可读性方面做得很好。这很可能是您最初目标的一部分，但是虽然这不是很容易阅读或解析它，但对于人和机器来说都比这更容易。折叠案例会丢失信息。

我建议一种不同的方法。

1. 从您的起始字符串开始，无论它是什么以及它来自何处（NTFS 文件名、数据库条目、web.config 中的 HttpHandler 绑定）。把它作为你的规范形式。无论如何都有规则，人们应该根据某种规范形式创建这些字符串，并可能在可能的地方强制执行它，但是如果有什么东西违反了你的规则，那么不管有多少，都接受它作为该资源的官方规范名称你不喜欢它。

2. 规范名称应该尽可能是外界“看到”的唯一名称。这可以通过编程方式强制执行，也可以仅作为最佳实践执行，因为使用 301 进行事后规范化并不能解决外部实体在取消引用 URI 之前不知道您这样做的事实。

   李>

3. 收到请求后，根据它的使用方式对其进行测试。因此，虽然您可以选择使用（或不使用）特定的文化来处理您自己执行资源查找的情况，使用所谓的“静态”URI，您的逻辑可以通过简单地使用 NTFS 来故意遵循 NTFS 的逻辑来执行工作：

   1. 暂时忽略区分大小写的问题查找映射文件。
   2. 如果不匹配则 404，谁在乎大小写？
   3. 如果找到，则进行区分大小写的序数比较，如果不匹配则 301 到区分大小写的映射。
   4. 否则，照常进行。

编辑：

在某些方面，域名问题更为复杂。 IDN 的规则必须以更小的回旋余地来涵盖更多问题。但是，至少就案例规范化而言，它也更简单。

（我将忽略是否使用 www. 等的规范化。虽然我猜它在这里是同一项工作的一部分，但它正在推动范围，如果我们最终可能会在我们之间写一本书我们不会停在某个地方:)

IDN 在 RFC 3491 中定义了自己的大小写规范化（以及一些其他形式的规范化）规则。如果您要根据大小写规范化域名，请遵循该规则。

回答起来很简单，不是吗？ :)

在某种程度上压力也较小，因为虽然搜索引擎必须认识到 http://example.net/thisisapath 和 http://example.net/thisIsAPath 可能是同一个资源，但他们也必须认识到它们可能不同，这就是所有 SEO对其中一个进行规范化的优势（不管是哪一个）来自。

但是，他们知道 example.net 和 EXAMPLE.NET 不可能是不同的站点，因此确保它们相同几乎没有 SEO 优势（对于缓存和历史列表之类的东西仍然很好自己跳）。当然，问题仍然在于 www.example.net 甚至 maAndPasExampleEmporium.us 可能是同一个站点，但同样，这与案例问题无关。

还有一个简单的问题，大多数时候我们不必处理超过几十个不同的域，所以有时更努力而不是更聪明地工作（即，只要确保它们都设置正确并且不要' t 以编程方式做任何事情！）可以解决问题。

最后一点，重要的是不要规范化第三方 URI。如果您更改路径（他们可能不会不区分大小写），您最终可能会破坏事物，并且您至少可能最终会破坏它们略有不同的规范化。最好始终保持原样。

Answer 3

首先从不使用案例转换来比较字符串。它不必要地分配了一个字符串，它对性能产生了不必要的小影响，如果值为 null，可能会导致 ObjectReferenceException 并且可能导致不正确的比较。

如果这对您来说足够重要，我将手动遍历文件系统并使用您自己的比较来与每个文件/目录名称进行比较。您应该能够使用Accept-Language 或Accept-Encoding（如果它包含文化）HTTP 标头来找到要使用的合适文化。拥有CultureInfo 后，您可以使用它来执行字符串比较：

var ci = CultureInfo.CurrentCulture; // Use Accept-Language to derive this.
ci.CompareInfo.Compare("The URL", "the url", CompareOptions.IgnoreCase);

我只会在 HTTP 404 上执行此操作； HTTP 404 处理程序将搜索匹配的文件，然后对用户进行 HTTP 301 到正确大小写的 URL（因为手动文件系统遍历可能会很昂贵）。