问题是url是否应该区分大小写?

我认为区分大小写的URL没有用处，也没有很好的实践。这很愚蠢，很糟糕，应该在任何时候都避免。

只是为了支持我的观点，当有人问什么URL，你怎么解释URL的字符是大写还是小写?这是无稽之谈，没有人会告诉你不是这样的。

URL字符被转换为十六进制代码(如果您注意到URL中的空格显示为%20等)，由于小写字母和大写字母有不同的十六进制值，因此URL肯定是区分大小写的。然而，问题的精神似乎是，这应该是标准，我说不，但他们是。如果开发人员/提供商希望它能够为最终用户工作，那么他们就应该在代码中考虑到这一点。

为了可读性，所有“不敏感”都加粗。

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

以这个页面为例，stackoverflow.com接收GET字符串/questions/7996919/should-url-be-大小写敏感，向浏览器发送HTML文档。Stackoverflow.com是大小写不敏感的，因为它为/QUEStions/7996919/ should -url-be大小写敏感生成了相同的结果。

另一方面，维基百科是区分大小写的，除了标题的第一个字符。url https://en.wikipedia.org/wiki/Case_sensitivity和https://en.wikipedia.org/wiki/case_sensitivity指向同一篇文章，但https://en.wikipedia.org/wiki/CASE_SENSITIVITY返回404。

根据W3的“HTML和url”，它们应该:

可能有url，或者url的一部分，大小写不重要，但是 识别这些可能并不容易。用户应该始终考虑到这一点 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指向有效资源本身。

一般来说，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，因为他们所做的是由其他人之前的帖子突出显示的。