我注意到了
HTTP://STACKOVERFLOW.COM/QUESTIONS/ASK
和
http://stackoverflow.com/questions/ask
两者都运行正常 - 实际上前一个转换为小写。
我认为这对用户来说很有意义。
如果我查看Google，那么此网址可以正常运行：
http://www.google.com/intl/en/about/corporate/index.html
但是这个“关于”的人不起作用：
http://www.google.com/intl/en/ABOUT/corporate/index.html
网址是否区分大小写？
答案 0 :(得分：256)
根据W3的“HTML and URLs”，他们应该：
可能存在URL或URL的一部分，其中大小写无关紧要，但是 识别这些可能并不容易。用户应该始终考虑这一点 网址区分大小写。
答案 1 :(得分：116)
为了便于阅读，所有“不敏感”都是加粗的。
根据RFC 4343，域名是不敏感的。 URL的其余部分通过GET方法发送到服务器。这可能是区分大小写的。
以此页面为例，stackoverflow.com收到GET字符串/questions/7996919/should-url-be-case-sensitive，将HTML文档发送到您的浏览器。 Stackoverflow.com是不敏感的情况，因为它为/QUEStions/7996919/Should-url-be-case-sensitive产生相同的结果。
另一方面，除了标题的第一个字符外，维基百科区分大小写。网址https://en.wikipedia.org/wiki/Case_sensitivity和https://en.wikipedia.org/wiki/case_sensitivity会导致相同的文章，但https://en.wikipedia.org/wiki/CASE_SENSITIVITY会返回404。
答案 2 :(得分：68)
取决于主机操作系统。由于底层文件系统不区分大小写，因此Windows上托管的站点往往不区分大小写。 Unix类型系统上托管的站点往往区分大小写，因为它们的底层文件系统通常区分大小写。 URL的主机名部分始终不区分大小写，它是路径的其余部分变化。
答案 3 :(得分：30)
由于DNS忽略大小写，因此URL的域名部分不区分大小写：
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本身指向有效资源。
答案 4 :(得分：15)
我不喜欢碰到旧文章，但因为这是对这一特定问题的第一批回应之一，我觉得有必要澄清一些事情。
正如@Bhavin Shah回答的那样，url的域部分不区分大小写，所以
http://google.com
和
http://GOOGLE.COM
和
http://GoOgLe.CoM
都是相同的，但域名部分之后的所有内容都被视为区分大小写。
所以...
http://GOOGLE.COM/ABOUT
和
http://GOOGLE.COM/about
是不同的。
注意：我正在谈论＆＃34;技术上＆＃34;而不是＆＃34;字面意思＆＃34;在很多情况下，大多数情况下，服务器设置为处理这些项目相同，但可以设置它们，因此它们的处理方式不同。
不同的服务器处理不同的方式，在某些情况下，它们必须区分大小写。在许多情况下，查询字符串值是经过编码的（例如作为查询字符串值传递的Session Ids或Base64编码数据）这些项目的性质区分大小写，因此服务器在处理它们时必须区分大小写。
所以要回答这个问题，＆＃34;应该＆＃34;服务器在获取这些数据时会区分大小写，答案是“＃34;是的，绝对是。”＃34;
当然并非所有内容都需要区分大小写，但服务器应该知道这是什么以及如何处理这些情况。
答案 5 :(得分：6)
请查看此处的规范： 第2.7.3节 http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#page-19
方案和主机不区分大小写，通常以小写字母提供;所有其他组件在区分大小写时进行比较 方式。
答案 6 :(得分：2)
URL应该不区分大小写，除非有充分的理由说明它们不应该是。
这不是强制性的（它不是RFC的任何部分），但它使URL的通信和存储更加可靠。
如果我在网站上有两个页面：
http://stackoverflow.com/ABOUT.html
和
http://stackoverflow.com/about.html
他们应该如何区别？也许有人写的是“喊叫风格”（帽子） - 但从IA的角度来看，不应该通过更改URL的情况来区分。
此外，在Apache中很容易实现这一点 - 只需使用mod_Speling中的CheckSpelling On即可。
答案 7 :(得分：2)
请考虑以下内容：
https://www.example.com/createuser.php?name=Paul%20McCartney
在这个假设的示例中，HTML表单（使用GET方法）将“ name”参数发送到创建新用户帐户的PHP脚本。
在此示例中，我要说明的是，此GET参数必须区分大小写，以保留“ McCartney”的大写字母（或作为另一个示例，保留“ Walter d'Isney”，因为是其他打破常规大写规则的方法。
像这样的情况指导W3C建议方案和主机不区分大小写，但是此后的所有内容都可能区分大小写-并留给服务器。按标准强制不区分大小写将使上面的示例无法保留作为GET查询参数传递的用户输入的大小写。
但是我要说的是，尽管这必然是适应此类案件的法律条文，但法律的精神是，在案件无关紧要的情况下，以不区分大小写的方式行事。但是，这些标准不能告诉您大小写无关的地方，因为像我所给出的示例一样，这是上下文相关的事情。
（例如，最好使帐户用户名不区分大小写，因为“ User123”和“ user123”是不同的帐户可能会造成混淆，即使它们的真实姓名（如上）最好区分大小写。）
有时它是相关的，多数情况下是不相关的。但是必须由服务器/ Web开发人员来决定这些事情-并且不能由标准规定-因为只有在该级别才能知道上下文。
该方案和主机不区分大小写（这表明该标准对不区分大小写的偏爱，在此可以普遍规定）。剩下的由您决定，因为您可以更好地理解上下文。但是，正如已经讨论的那样，除非有充分的理由不这样做，否则您可能应该本着法律的精神默认不区分大小写。
答案 8 :(得分：1)
Section 6.2.2.1 of RFC 3986 表示“scheme 和 host 不区分大小写，因此应该规范化为小写。例如，URI HTTP://www.EXAMPLE.com/ 等价于 {{1} }. 其他通用语法组件被假定为区分大小写，除非方案另有特别定义”。
服务器可能会在内部对传递的 URI 进行规范化，并为不同大小写的 URI（http://www.example.com/ 和 /about/）提供相同的资源，从而使 URI 对用户不区分大小写。
答案 9 :(得分：0)
将URL字符转换为十六进制代码（如果您注意到URL中的空格显示为％20等），并且由于大写和小写字母具有不同的十六进制值，因此URL完全正确绝对是区分大小写的。然而问题的精神似乎应该是标准，我说不，但他们是。如果开发人员/提供商希望无论最终用户是否都能使用它，那么由开发人员/提供商来解决这个问题。
答案 10 :(得分：0)
我认为这个以及关于规范所说或未说的内容的许多答案都忽略了问题的重点。应该它们是否区分大小写？真的是这个问题。从用户的角度来看，区分大小写是一个痛点，并非所有知识都有所不同。 URI是否应该是的问题取决于问题的背景。为了技术灵活性，是的，它们应该是。对于可用性，不，它们不应该是。
答案 11 :(得分：0)
老问题但我在这里偶然发现，所以为什么不对它采取行动，因为问题是寻求各种观点，而不是一个明确的答案。
w3c可能有它的建议 - 我非常关心 - 但是想要重新思考，因为问题就在这里。
为什么w3c认为域名不区分大小写并且之后不区分大小写？
我认为理由是URL的域部分是由用户手工输入的。 超文本后的所有内容都将由机器解析（后面的浏览器和服务器）。
机器可以比人类更好地处理不区分大小写（不是技术类型:)。
但问题只是因为如果以这种方式完成，机器可以处理吗？
我的意思是命名和访问位于hereIsTheResource与hereistheresource的资源有什么好处？
侧面比骆驼箱更难以读取。 人类可读（包括技术类）。
所以这是我的观点： -
资源路径落在编程结构中间的某个地方，有时接近浏览器后面的最终用户。
如果您的用户需要触摸它或键入它等，您的URL（不包括域名）应该不区分大小写。您应该开发应用程序以避免让用户尽可能地键入路径。
如果您的用户永远不会手动输入，您的网址（不包括域名）应区分大小写。
<强>结论
路径应区分大小写。我的观点正在考虑区分大小写的路径。
答案 12 :(得分：0)
URL是保留大小写。但是由于某些原因，取决于服务器，URL的某些部分可能区分大小写，
http：// www。 example.com /abc/def.ghi?jkl=mno#pqr
用户 @ example.com
URL中的区分大小写可以有多种用途。主要是：
作为开发人员，我相信上述方法通常可以更好地解决，但我也理解在某些情况下可能不允许这样做。
例如，假设一个现有产品需要在“ GET” URL中放置大量数据，但是它必须与所有主要服务器，浏览器和缓存/代理机制的最大URL长度兼容。为了适合中等长度的命令字符串（对于某些较旧的浏览器，该字符必须少于1,024个字符），您需要使用所有可能的唯一URL安全字符（基本上就是base64url编码）。
URL 是否是否区分大小写尚有待商.。我个人认为，不应该这样，为简单起见（尽管它可能会创建更长的URL，但是我们有转义符可以轻松处理必须确保保留准确字符的情况，并且有一些方法可以传输URL以外的数据）
许多人似乎都基于这样的事实，即为许多流行的站点和服务显式启用了不区分大小写的URL，以提高可用性。最突出的例子是电子邮件地址的用户名部分。大多数电子邮件提供商会忽略大小写，有时甚至会忽略点和其他符号（例如“ j.smith@example.com”与“ JSMITH@example.com”相同）。根据规范，即使电子邮件用户名默认情况下也区分大小写。
但是，事实是，尽管我或其他人可能想要什么，但这是当前工作方式的状态。当然，尽管最终有可能在全球范围内过渡到不区分大小写的URL标准，但由于当前区分大小写在网络上广泛用于各种目的，因此可能要花很长时间。
就最佳实践而言，作为用户，您可以在大多数情况下合理地坚持使用小写字母，并期望一切正常。主要例外是使用基于案例的编码或具有直接文件系统等效项的文档路径的URL。但是，此类复杂的URL通常是复制粘贴（或简单地单击）而不是手动键入的。
作为Web开发人员，您应该考虑使URL尽可能不区分大小写。如上所述，尽管视情况而定，显然存在一些难以避免的情况。
答案 13 :(得分：0)
一般来说，URL的大小写敏感性（以及大小写是否相同）必须从以下角度考虑：
从资源等效性的角度来看，除非资源不同，否则通常无法说出两个URL互不相同（小写，大写，句子大小写，驼峰大小写……的任意组合）互不相同。从这两个URL检索，在许多情况下不可行（RFC 3986, section 6.1, para 1）。因此，在无法检索资源的地方，将使用比较透视图。
但是，在可以检索资源的情况下，事情变得更加复杂（按预期）。根据{{3}}的规定，如下所述
除分层路径中的点段外，路径段为 通用语法认为不透明
看起来，除了通用语法（包括敏感性问题）的方案和权限之外，对于URI / URL的其余部分都无法做任何假设。
但是对于规范的方案和主体部分，规范确实（明智地）声明它们不区分大小写。请参阅RFC 3986, Section 3.3, para 5和RFC 3986, section 3.1, para 1。
已经用尽了这条查询线，应该从比较的角度来确定URI / URL是否区分大小写。
对该方向的第一个提示是通过仔细阅读第6.2.2.1节
其他通用语法 除非特别说明，否则假定组件区分大小写 该计划另有定义
考虑RFC 3986, section 6.2.2.1, para 2
会进一步推动比较两个URI以确定它们是否匹配时，客户端 应该对整个字节使用区分大小写的八位字节比较 URI
然后，最后是查询解决了，URL是区分大小写的...（嘿！），不是，可操作的单词是“不透明”，“客户”和“比较”。
除了语法之外，上述RFC并未提及有关路径和查询的实际解释，只是它是“不透明的”，并且仅指定了“客户端”（应该（而不是必须））如何“比较” URL。它没有提及服务器（应该是SHOULD，更不用说必须）如何解释方案/权限之外的其余URL。
因此，服务器可以自由地随意解释URL，正如其他人之前的帖子所强调的那样。
答案 14 :(得分：-2)
问题是网址是否应区分大小写？
我认为在区分大小写的URL后面没有任何用处或良好做法。这很愚蠢，很糟糕，应该随时避免。
只是为了支持我的观点，当有人问什么URL时，你怎么能解释URL的大小写是什么？这是无稽之谈，不应该有人告诉你。
答案 15 :(得分：-3)
对于Linux服务器中托管的网站，URL区分大小写。 http://www.google.com/about和http://www.google.com/About将被重定向到不同的位置。在Windows Server中，URL不区分大小写，如命名FOLDER并将重定向到相同位置。
答案 16 :(得分：-6)
可以制作非案例敏感网址
RewriteEngine on
rewritemap lowercase int:tolower
RewriteCond $1 [A-Z]
RewriteRule ^/(.*)$ /${lowercase:$1} [R=301,L]
将Google.com..GOOGLE.com等直接发送到google.com