老问题，但我在这里绊了一下，所以为什么不尝试一下呢，因为这个问题寻求的是不同的观点，而不是一个确定的答案。

w3c可能有它的建议-我很关心-但想要重新考虑，因为问题在这里。

为什么w3c认为域名是不区分大小写的，并且在后面留下不区分大小写的内容?

我认为基本原理是URL的域部分是由用户手动输入的。 超文本之后的所有内容都将由机器(浏览器和后面的服务器)解析。

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

但问题是，仅仅因为机器可以处理，就应该这样做吗?

我的意思是命名和访问位于hereIsTheResource和hereIsTheResource的资源的好处是什么?

横向图比驼色图更难读，驼色图更容易读。 人类可读(包括技术类)

以下是我的观点:-

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

你的URL(不包括域名)应该不区分大小写，如果你的用户希望触摸它或键入它等等。在开发应用程序时，应该尽量避免让用户键入路径。

你的URL(不包括域名)应该区分大小写，如果你的用户从来不会手动输入它。

结论

Path应该区分大小写。我的观点倾向于区分大小写。

url应该不区分大小写，除非有很好的理由说明它们不应该区分大小写。

这不是强制性的(它不是RFC的任何一部分)，但它使url的通信和存储更加可靠。

如果我在网站上有两页:

http://stackoverflow.com/ABOUT.html

and

http://stackoverflow.com/about.html

它们有何不同?也许有人写的是“大喊风格”(大写)——但从IA的角度来看，这种区别永远不应该通过URL的变化来区分。

此外，在Apache中很容易实现这一点-只需从mod_spelling使用CheckSpelling On。

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。

情况下保存

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尽可能不区分大小写。尽管如上所述，根据上下文，显然有一些难以避免的情况。

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