情况下保存

url在客户端和服务器之间是保留大小写的。但是部分url可能区分大小写，也可能不区分大小写，这取决于服务器，原因有几个。

区分大小写

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

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

用户@ example.com

基本原理

url中的大小写敏感有多种用途。主要是:

与区分大小写的文件系统的本机兼容性。 URL内更紧凑的数据编码，例如序列化、散列、id、永久链接和URL缩短器。

作为一名开发人员，我相信上述问题通常可以以更好的方式处理，但我也理解在某些情况下可能不允许这样做。

例如，假设一个现有产品需要在“GET”URL中放置大量数据，但它必须与所有主要服务器、浏览器和缓存/代理机制的最大URL长度兼容。为了适应中等长度的命令字符串(对于一些旧的浏览器来说小于1024个字符)，您需要使用每个惟一的url安全字符(这基本上就是base64url编码)。

理想世界

url是否应该区分大小写是有争议的。我个人认为，为了简单起见，它们不应该是这样的(尽管它可能会创建更长的URL，但我们有百分数转义来轻松处理必须确保保存确切字符的情况，并且有其他方法可以在URL中传输数据)。

许多人似乎都同意这样一个事实，即许多流行的网站和服务都明确启用了不区分大小写的url，以提高可用性。最突出的例子是电子邮件地址的用户名部分。大多数电子邮件提供商会忽略大小写，有时甚至是点和其他符号(比如“j.smith@example.com”和“JSMITH@example.com”一样)。尽管根据规范，电子邮件用户名默认情况下是区分大小写的。

然而，事实是，不管我或其他人想要什么，这就是事情目前的工作状态。虽然最终在全球范围内过渡到不区分大小写的URL标准当然是可能的，但这可能需要相当长的时间，因为区分大小写目前在网络上被广泛用于各种目的。

最佳实践

就最佳实践而言，作为用户，您可以合理地在大多数情况下坚持使用小写字母，并期望事情能够正常工作。主要的例外是使用基于实例的编码的url或具有直接文件系统等价物的文档路径。然而，这种复杂的url通常是复制粘贴的(或简单地单击)，而不是手动输入的。

作为一个web开发人员，你应该考虑让url尽可能不区分大小写。尽管如上所述，根据上下文，显然有一些难以避免的情况。

一般来说，url的大小写敏感性(以及它们在不同大小写下是否相同)需要从以下角度来看待:

资源等效 URL的比较

从资源等价的角度来看，通常不可能说两个url在任何情况下都不同(小写，大写，句子大小写，驼峰大小写……)大小写的任何组合)彼此不同，除非资源是从两个url中检索的，这在许多情况下是不现实的(RFC 3986, section 6.1, para 1)。因此，当资源不能检索时，使用比较透视图。

然而，在可以检索资源的情况下，问题会变得更加复杂(正如预期的那样)。根据RFC 3986第3.3节第5段的规定，如下所强调的

除了层次路径中的点段之外，路径段是 泛型语法认为是不透明的

似乎不能从通用语法(包括敏感性问题)对URI/URL的方案和权限以外的其他部分做出任何假设。

然而，对于授权的方案和主机部分，规范(仁慈地)规定它们是不区分大小写的。请参阅RFC 3986第3.1节第1段和RFC 3986第6.2.2.1节第2段。

在穷尽了这条查询线之后，应该查看比较透视图，以确定URI/ url是否区分大小写。

对这个方向的第一个提示是通过阅读6.2.2.1节(上面)

另一个泛型语法 除非特别说明，否则假定组件是区分大小写的 由方案另行定义

RFC 2616第3.2.3节进一步支持了这一点

当比较两个uri以决定它们是否匹配时，客户机 是否应该使用区分大小写的八个字节对整个代码进行比较 uri

然后，最后，查询是否已解决，url是否区分大小写…(嘿!)，不完全是，关键的词是“opaque”，“client”和“comparison”。

除了它的语法之外，上面的RFC没有提到任何关于路径和查询的实际解释，除了它是“不透明的”，它只指定了“客户端”如何(使用SHOULD而不是MUST)“比较”URL。它没有提到服务器(应该，更不用说必须)如何在方案/权限之外解释URL的其余部分。

因此，服务器有所有的纬度来解释一个URL，因为他们所做的是由其他人之前的帖子突出显示的。

请看这里的规格: 2.7.3节 https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-p1-messaging-25#page-19

scheme和host不区分大小写，通常以小写形式提供;所有其他组件以区分大小写的方式进行比较 的方式。

我认为这和许多关于规范做了什么或没有说什么的答案都没有抓住问题的重点。它们应该区分大小写吗?这是一个意味深长的问题。从用户的角度来看，区分大小写是一个痛点，不是所有人都知道就有区别。uri应该还是不应该的问题取决于问题的上下文。就技术灵活性而言，是的，它们应该如此。就可用性而言，不，它们不应该如此。

对于托管在Linux服务器上的网站，URL是区分大小写的。 http://www.google.com/about和http://www.google.com/About将被重定向到不同的位置。而在Windows服务器中，URL是不区分大小写的，就像命名文件夹一样，将被重定向到相同的位置。

我不喜欢撞旧文章，但因为这是对这个特定问题的第一个回应，我觉得有必要澄清一些事情。

@Bhavin Shah回答说url的域名部分是不区分大小写的，所以

http://google.com 

and

http://GOOGLE.COM 

and

http://GoOgLe.CoM 

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

所以…

http://GOOGLE.COM/ABOUT

and

http://GOOGLE.COM/about

是不同的。

注意:我说的是“技术上”，而不是“字面上”在很多情况下，大多数情况下，服务器的设置处理这些项目相同，但也有可能设置他们，所以他们不处理相同。

不同的服务器处理方式不同，在某些情况下，它们必须区分大小写。在许多情况下，查询字符串值是被编码的(例如Session id或Base64编码的数据，作为查询字符串值传递)这些项本质上是区分大小写的，因此服务器在处理它们时必须区分大小写。

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

当然，并不是所有的内容都需要区分大小写，但是服务器应该知道区分大小写的含义以及如何处理这些大小写。

@Hart Simha的评论基本上说了同样的事情。在我发布之前我错过了它，所以我想在应得的地方给予赞扬。