我注意到
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是否应该区分大小写?
当前回答
可以创建不区分大小写的url
RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]
使Google.com.. Google.com等直接到Google.com
其他回答
url应该不区分大小写，除非有很好的理由说明它们不应该区分大小写。
这不是强制性的(它不是RFC的任何一部分)，但它使url的通信和存储更加可靠。
如果我在网站上有两页:
http://stackoverflow.com/ABOUT.html
and
http://stackoverflow.com/about.html
它们有何不同?也许有人写的是“大喊风格”(大写)——但从IA的角度来看，这种区别永远不应该通过URL的变化来区分。
此外，在Apache中很容易实现这一点-只需从mod_spelling使用CheckSpelling On。
取决于主机操作系统。托管在Windows上的站点往往不区分大小写，因为底层文件系统不区分大小写。托管在Unix类型系统上的站点往往是区分大小写的，因为它们的底层文件系统通常是区分大小写的。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。
我认为这和许多关于规范做了什么或没有说什么的答案都没有抓住问题的重点。它们应该区分大小写吗?这是一个意味深长的问题。从用户的角度来看，区分大小写是一个痛点，不是所有人都知道就有区别。uri应该还是不应该的问题取决于问题的上下文。就技术灵活性而言，是的，它们应该如此。就可用性而言，不，它们不应该如此。
有了官方的指导方针，有一个有趣的情况，人们应该考虑使用大写的整个url: QR码。
例如，https://example.com/不适合版本1 (21x21)的QR码，需要更大的版本2 (25x25)的QR码。
而使用字母数字模式允许将HTTPS://EXAMPLE.COM/12345塞进更小的版本1!
