URL是否应区分大小写？

我注意到

HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK

和

http://stackoverflow.com/questions/ask

两者都可以正常工作-实际上将前一个转换为小写。

我认为这对用户有意义。

如果我查看Google，那么此URL可以正常工作：

http://www.google.com/intl/en/about/corporate/index.html  

但是这个带有“ ABOUT”的按钮不起作用：

http://www.google.com/intl/en/ABOUT/corporate/index.html   

URL是否应区分大小写？

根据W3的“ HTML和URL ”，它们应该：

可能存在URL或URL的一部分，大小写无关紧要，但是识别它们可能并不容易。用户应始终认为URL区分大小写。

所有“ 不敏感的 ”均以粗体显示，以提高可读性。

根据RFC 4343，域名不区分大小写。URL的其余部分通过GET方法发送到服务器。这是否区分大小写。

以此页面为例，stackoverflow.com接收GET字符串/ questions / 7996919 / should-url-be-case-sensitive，将HTML文档发送到您的浏览器。Stackoverflow.com 不区分大小写，因为它对/ QUEStions / 7996919 / Should-url-be-case敏感会产生相同的结果。

另一方面，维基百科区分大小写，但标题的第一个字符除外。URL https://en.wikipedia.org/wiki/Case_sensitiveivity和https://en.wikipedia.org/wiki/case_sensitiveivity导致了同一篇文章，但https://en.wikipedia.org/wiki/CASE_SENSITIVITY返回404。

取决于托管操作系统。Windows上托管的站点通常不区分大小写，因为基础文件系统不区分大小写。Unix类型系统上托管的站点通常区分大小写，因为其基础文件系统通常区分大小写。URL的主机名部分始终不区分大小写，这是其余路径的不同。

URL的域名部分不区分大小写，因为DNS忽略大小写： http://en.example.org/并且HTTP://EN.EXAMPLE.ORG/都打开同一页面。

该路径用于指定并可能找到请求的资源。它区分大小写，尽管某些服务器可能会将其视为不区分大小写，尤其是那些基于Microsoft Windows的服务器。

如果服务器区分大小写且http://en.example.org/wiki/URL正确，则http://en.example.org/WIKI/URL或http://en.example.org/wiki/url将显示HTTP 404错误页面，除非这些URL本身指向有效资源。

我不喜欢碰破旧文章，但是因为这是针对该特定问题的第一批回应之一，所以我觉得有必要澄清一些问题。

由于@Bhavin Shah回答指出url的域部分不区分大小写，因此

http://google.com 

和

http://GOOGLE.COM 

和

http://GoOgLe.CoM 

都一样，但是域名部分之后的所有内容都区分大小写。

所以...

http://GOOGLE.COM/ABOUT

和

http://GOOGLE.COM/about

是不同的。

注意：在很多情况下，我说的是“技术上”而不是“文字上”，大多数情况下，服务器被设置为以相同的方式处理这些项目，但是可以对它们进行设置，以使它们的处理方式不同。

不同的服务器对此处理方式有所不同，在某些情况下，它们必须区分大小写。在许多情况下，对查询字符串值进行编码（例如，作为查询字符串值传递的Session Ids或Base64编码数据），这些项目的性质区分大小写，因此服务器在处理它们时必须区分大小写。

因此要回答这个问题，“服务器”在获取这些数据时应区分大小写，答案是“是的，最肯定的是”。

当然，并非所有内容都必须区分大小写，但是服务器应该知道这是什么以及如何处理这些情况。

@Hart Simha的评论基本上说了同样的话。我在发布之前错过了它，所以我想在应得的额度上给予好评。

在此处查看规范：2.7.3节 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19

方案和主机不区分大小写，通常以小写形式提供；所有其他组件都以区分大小写的方式进行比较。

考虑以下：

https://www.example.com/createuser.php?name=Paul%20McCartney

在此假设示例中，HTML表单（使用GET方法）将“ name”参数发送到创建新用户帐户的PHP脚本。

我在此示例中提出的要点是，此GET参数必须区分大小写，以保留“ McCartney”的大写字母（或者，例如，保留“ Walter d'Isney”，因为还有其他方法）以便打破常规的大写规则）。

正是这种情况指导W3C建议方案和主机不区分大小写，但之后的所有内容都可能区分大小写-并留给服务器。按标准强制不区分大小写将使上面的示例无法保留作为GET查询参数传递的用户输入的大小写。

但是我要说的是，尽管这一定是适应此类案件的法律条文，但法律的精神是，在案件无关紧要的情况下，以不区分大小写的方式行事。但是，这些标准无法告诉您大小写无关的地方，因为就像我所给出的示例一样，这是上下文相关的。

（例如，最好使帐户用户名不区分大小写-因为“ User123”和“ user123”是不同的帐户可能会造成混淆-即使上面提到的真实姓名最好区分大小写。）

有时它是相关的，大多数时候都没有关系。但是必须由服务器/ Web开发人员来决定这些事情-并且不能由标准规定-因为只有在该级别才能知道上下文。

该方案和主机不区分大小写（这表明该标准对不区分大小写的偏爱，可以普遍规定该区分大小写）。剩下的由您决定，因为您可以更好地理解上下文。但是，正如已经讨论的那样，除非有充分的理由，您可能应该本着法律的精神默认不区分大小写。

网址应该不区分大小写，除非有充分的理由不应该这样。

这不是强制性的（它不是RFC的任何部分），但是它使URL的通信和存储更加可靠。

如果我在网站上有两个页面：

http://stackoverflow.com/ABOUT.html

和

http://stackoverflow.com/about.html

它们应该有什么不同？也许有人写成“喊样式”（大写）-但从IA的角度来看，永远不要通过更改URL的大小来区分。

此外，在Apache中轻松实现此功能-只需CheckSpelling On在mod_Speling中使用即可。

这是一个老问题，但我在这里偶然发现，为什么不试一试，因为这个问题正在寻求各种视角，而不是一个明确的答案。

w3c可能有它的建议-我很在意-但由于问题在这里，所以想重新考虑。

为什么w3c认为域名不区分大小写，事后不区分大小写？

我认为原因是URL的域部分是由用户手动键入的。超文本之后的所有内容都将由计算机（后面的浏览器和服务器）解决。

机器可以比人类更好地处理不区分大小写的问题（不是技术上的问题：）。

但是问题仅仅是因为机器可以处理那样处理吗？

我的意思是命名和访问hereIsTheResourcevs上的资源有什么好处hereistheresource？

侧面比骆驼的情况更不可读，骆驼的情况更容易辨认。对人类可读（包括技术种类）。

所以这是我的观点：

资源路径位于编程结构中间的某个位置，有时靠近浏览器后面的最终用户。

如果希望用户触摸或键入URL，则URL（不包括域名）应区分大小写。您应将应用程序开发为AVOID，让用户尽可能键入路径。

如果您的用户永远不会手动输入您的URL（不包括域名），则应区分大小写。

结论

路径应区分大小写。我的观点正朝着区分大小写的方向发展。

URL字符将转换为十六进制代码（如果您曾经注意到URL中的空格显示为％20等），并且由于小写和大写字母具有不同的十六进制值，所以完全可以确定URL绝对区分大小写是很有意义的。但是，问题的精神似乎应该成为标准，我说不，但事实是这样。如果开发人员/提供者希望最终用户不管它如何工作，则由开发人员/提供者自行决定。

我认为，有关规范说明或不说明的问题以及许多答案都遗漏了问题的重点。如果他们是区分大小写？确实，这是一个充满挑战的问题。从用户的角度来看，区分大小写是一个痛点，并不是所有人都知道有所作为。URI是否应该的问题取决于问题的上下文。为获得技术灵活性，是的，应该如此。为了可用性，不，它们不应该。

案件保全

URL 在客户端和服务器之间是区分大小写的。但是，由于服务器的不同，URL的某些部分可能区分大小写，也可能不区分大小写，这有两个原因。

区分大小写

URL 的以下粗体部分可能区分大小写，具体取决于站点和/或服务器的配置。

    http：// www。example.com /abc/def.ghi?jkl=mno#pqr

    用户 @ example.com

基本原理

URL中的区分大小写可以有多种用途。主要是：

1. 与区分大小写的文件系统的本机兼容性。
2. URL中更紧凑的数据编码，例如用于序列化，哈希，ID，永久链接和URL缩短器。

作为开发人员，我相信上述方法通常可以更好地解决，但我也理解在某些情况下可能不允许这样做。

例如，假设现有产品需要在“ GET” URL中放置大量数据，但必须与所有主要服务器，浏览器和缓存/代理机制的最大URL长度兼容。为了适合中等长度的命令字符串（对于某些较旧的浏览器，该字符必须少于1,024个字符），您需要使用所有可能的唯一URL安全字符（基本上就是base64url编码）。

在理想世界中

URL 是否区分大小写尚待商.。我个人认为，不应该这样，为简单起见（尽管它可能会创建更长的URL，但我们有百分号转义符可以轻松处理必须确保保留准确字符的情况，并且有一些方法可以传输URL以外的数据） 。

许多人似乎都基于这样的事实，即为许多流行的站点和服务显式启用了不区分大小写的URL，以提高可用性。最突出的例子是电子邮件地址的用户名部分。大多数电子邮件提供商会忽略大小写，有时甚至会忽略点和其他符号（例如“ j.smith@example.com”与“ JSMITH@example.com”相同）。根据规范，即使电子邮件用户名默认情况下也区分大小写。

但是，事实是，尽管我或其他人可能想要什么，但这是当前工作方式的状态。尽管最终有可能在全球范围内过渡到不区分大小写的URL标准，但由于当前区分大小写在网络上广泛用于各种目的，因此可能会花费很长时间。

最佳实践

就最佳实践而言，作为用户，您可以在大多数情况下合理地坚持使用小写字母，并期望一切正常。主要的例外是使用基于案例的编码或具有直接文件系统等效项的文档路径的URL。但是，此类复杂的URL通常是复制粘贴（或简单单击）的，而不是手动键入的。

作为Web开发人员，您应该考虑使URL尽可能不区分大小写。如上所述，尽管视情况而定，但显然存在一些难以避免的情况。

问题是网址应该区分大小写吗？

我看不到区分大小写的URL的用处或好的做法。它很蠢，很烂，应该始终避免。

只是为了支持我的观点，当有人问什么URL时，您如何解释URL的哪些字符是大写或小写？那是胡说八道，没有人告诉过你。

对于Linux服务器中托管的网站，URL区分大小写。 http://www.google.com/about和http://www.google.com/About将会重定向到其他位置。在Windows Server中，URL不区分大小写，就像在命名FOLDER一样，并将重定向到相同位置。

可以创建不区分大小写的URL

RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]

使Google.com..GOOGLE.com等直接指向google.com