我注意到
HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK
and
http://stackoverflow.com/questions/ask
两者都可以工作-实际上前一个转换为小写字母。
我认为这对用户来说是有意义的。
如果我看谷歌，那么这个URL工作正常:
http://www.google.com/intl/en/about/corporate/index.html
但是这个带ABOUT的不能用:
http://www.google.com/intl/en/ABOUT/corporate/index.html
URL是否应该区分大小写?
当前回答
RFC 3986第6.2.2.1节说:“scheme和host不区分大小写，因此应该规范化为小写。例如，URI HTTP://www.EXAMPLE.com/等价于http://www.example.com/。假定其他通用语法组件是区分大小写的，除非该方案另有特别定义”。
服务器可以在内部规范化传递的URI，并为不同大小写的URI (/about/和/about/)提供相同的资源，使URI对用户来说不区分大小写。
其他回答
有了官方的指导方针，有一个有趣的情况，人们应该考虑使用大写的整个url: QR码。
例如，https://example.com/不适合版本1 (21x21)的QR码，需要更大的版本2 (25x25)的QR码。
而使用字母数字模式允许将HTTPS://EXAMPLE.COM/12345塞进更小的版本1!
我不喜欢撞旧文章，但因为这是对这个特定问题的第一个回应，我觉得有必要澄清一些事情。
@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的评论基本上说了同样的事情。在我发布之前我错过了它，所以我想在应得的地方给予赞扬。
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中的空格显示为%20等)，由于小写字母和大写字母有不同的十六进制值，因此URL肯定是区分大小写的。然而，问题的精神似乎是，这应该是标准，我说不，但他们是。如果开发人员/提供商希望它能够为最终用户工作，那么他们就应该在代码中考虑到这一点。
我认为这和许多关于规范做了什么或没有说什么的答案都没有抓住问题的重点。它们应该区分大小写吗?这是一个意味深长的问题。从用户的角度来看，区分大小写是一个痛点，不是所有人都知道就有区别。uri应该还是不应该的问题取决于问题的上下文。就技术灵活性而言，是的，它们应该如此。就可用性而言，不，它们不应该如此。
