为什么URL区分大小写？

我的问题：最初设计URL时，为什么要区分大小写？我之所以这样问，是因为我（即一个外行）似乎不希望使用大小写不敏感来防止不必要的错误并简化已经很复杂的文本字符串。

另外，区分大小写的URL是否有真正的目的/优势（与大写字母指向同一页面的大多数URL相对，无论大小写都相反）？

例如，维基百科是一个对字母大小写敏感的网站（第一个字符除外）：

https://en.wikipedia.org/wiki/St 甲 ck_Exchange是DOA。

URL为什么不区分大小写？

我知道这看起来像是一个挑衅性的（和“魔鬼的拥护者”）类型的修辞问题，但我认为考虑一下很有用。HTTP的设计是通常称为“ Web浏览器”的“客户端”向“ Web服务器”询问数据。

发布了很多很多不同的Web服务器。Microsoft已经发布了带有Windows Server操作系统（以及其他操作系统，包括Windows XP Professional）的IIS。Unix具有像nginx和Apache这样的重量级人物，更不用说像OpenBSD的内部httpd或thttpd或lighttpd之类的较小产品了。此外，许多具有网络功能的设备都内置了可用于配置设备的Web服务器，包括具有特定于网络目的的设备，例如路由器（包括许多Wi-Fi接入点和DSL调制解调器），以及其他设备，例如打印机或可能具有网络连接性的UPS（电池支持的不间断电源设备）。

因此，“为什么URL区分大小写？”这个问题问，“为什么Web服务器将URL区分大小写？” 实际的答案是：他们并没有做到这一点。至少一台相当流行的Web服务器通常不区分大小写。（Web服务器是IIS。）

不同Web服务器之间行为不同的一个关键原因可能归结为简单性。制作Web服务器的简单方法是按照与计算机/设备的操作系统定位文件相同的方式进行操作。很多时候，Web服务器会定位文件以提供响应。Unix是针对高端计算机设计的，因此Unix提供了允许使用大写和小写字母的理想功能。Unix决定将大写和小写区别对待，因为它们是不同的。那是要做的简单自然的事情。Windows由于希望支持已经创建的软件而具有不区分大小写的历史，而这种历史可以追溯到DOS，后者根本不支持小写字母，可能是为了使用功能更强大的计算机使用更少的内存来简化操作。由于这些操作系统不同，因此结果是，简单设计的Web服务器（早期版本）反映了相同的差异。

现在，在所有背景下，这里是针对特定问题的一些具体答案：

最初设计URL时，为什么要区分大小写？

为什么不？如果所有标准Web服务器均不区分大小写，则表明该Web服务器遵循该标准指定的一组规则。根本没有规则说该案需要被忽略。没有规则的原因仅仅是因为没有理由要有这样的规则。为什么要麻烦制定不必要的规则？

我之所以这样问，是因为我（即一个外行）似乎不希望使用大小写不敏感来防止不必要的错误并简化已经很复杂的文本字符串。

URL是为机器处理而设计的。尽管人们可以在地址栏中输入完整的URL，但这并不是预期设计的主要部分。预期的设计是使人们遵循（“单击”）超链接。如果普通的普通人这样做，那么他们真的不在乎看不见的URL是简单还是复杂。

另外，区分大小写的URL是否有真正的目的/优势（与大写字母指向同一页面的大多数URL相对，无论大小写都相反）？

William Hay的答案的第五点提到了一个技术优势：URL可能是Web浏览器向Web服务器发送一些信息的有效方法，如果限制较少，则可以包含更多信息，因此区分大小写限制将减少可包含的信息量。

但是，在许多情况下，区分大小写并没有超级引人注目的好处，事实是IIS通常不会对此加以干扰，这证明了这一点。

总而言之，最令人信服的原因可能是对于那些设计Web服务器软件的人来说只是简单，尤其是在区分大小写的平台（例如Unix）上。（HTTP并没有影响Unix的原始设计，因为Unix明显比HTTP古老。）

URL不区分大小写，仅一部分。
例如，URL中不区分大小写https://google.com，

参考RFC 3986-统一资源标识符（URI）：通用语法

首先，在Wikipedia中，URL类似于：

 scheme:[//host[:port]][/]path[?query][#fragment]

（我删除了该user:password部分，因为它并不有趣并且很少使用）

• scheme：

方案不区分大小写

• host：

主机子组件不区分大小写。

• path：

路径组件包含数据...

• query：

查询组件包含非分层数据...

• fragment：

各个媒体类型可以在片段标识符语法中定义自己的限制或结构，以指定不同类型的子集，视图或外部引用

因此，scheme和host不区分大小写。
URL的其余部分区分大小写。

为什么path区分大小写？

这似乎是主要问题。如果没有记录，
很难回答为什么要这样做，但是我们可以做出很好的猜测。
我从规范中选择了非常具体的报价，重点放在data上。
让我们再次看一下URL：

 scheme:[//host[:port]][/]path[?query][#fragment]
 \____________________/\________________________/
        Location                 Data

• 位置-位置具有规范形式，并且不区分大小写。为什么？可能是这样，您可以购买域名而不必购买数千个变体。

• 数据-数据由目标服务器使用，应用程序可以选择其含义。使数据不区分大小写是没有任何意义的。该应用程序应具有更多选项，并且在规范中定义不区分大小写将限制这些选项。
  这对于HTTPS也是有用的区别：数据是加密的，但主机是可见的。

它有用吗？

区分大小写在缓存和规范URL方面有其陷阱，但是它肯定有用。一些例子：

• Base64，用于数据URI。
• 网站可以在网址中对Base64数据进行编码，例如：http : //tryroslyn.azurewebsites.net/#f : r/A4VwRgNglgxgBDCBDAziuBhOBvGB7AOxQBc4SAnKAgczLgF44AiAUQPwBMBTDuKuYgAsucAKoAAlABCBCJgG4
• URL缩短器利用区分大小写：/a5B可能与/a5b
• 正如您所提到的，维基百科可以区分“艾滋病”和“艾滋病”。

简单。操作系统区分大小写。Web服务器通常不在乎，除非它们必须在某个时候访问文件系统。这是Linux和其他基于Unix的操作系统执行文件系统规则的地方，在这种情况下，敏感度是主要部分。这就是IIS从来都不区分大小写的原因。因为Windows从不区分大小写。

[更新]

正如我所说的那样，注释中有一些强有力的论点（自删除以来），它们关于URL是否与文件系统有任何关系。这些论点变得热烈起来。相信没有关系是极短视的。绝对有！让我进一步解释。

应用程序程序员通常不是系统内部人员。我不是在侮辱。它们是两个独立的学科，当应用程序可以简单地调用OS时，就不需要系统内部知识来编写应用程序。由于应用程序程序员不是系统内部程序员，因此无法绕过OS服务。我之所以这样说，是因为这是两个独立的阵营，而且很少交叉。编写应用程序通常是为了使用OS服务。当然，很少有例外。

当Web服务器开始出现时，应用程序开发人员并未尝试绕过OS服务。有几个原因。第一，没有必要。第二，应用程序程序员通常不知道如何绕过OS服务。第三，大多数操作系统要么极其稳定，强大，要么极其简单，轻巧，不值得付出任何代价。

请记住，早期的Web服务器要么在大型主机或中型计算机上的DEC VAX / VMS服务器和当今的Unix（Berkeley，Ultrix以及其他）等昂贵的计算机上运行，​​然后不久就开始运行。轻型计算机，例如PC和Windows 3.1。当更现代的搜索引擎开始出现时，例如1997/8年的Google，Windows进入了Windows NT，而其他操作系统（例如Novell和Linux）也开始运行Web服务器。Apache是​​主要的Web服务器，尽管还有其他非常流行的诸如IIS和O'Reilly的服务器。当时他们都没有绕过OS服务。直到今天，所有Web服务器都可能没有。

早期的Web服务器非常简单。他们仍然是今天。Web服务器通过OS文件系统发出/通过硬盘驱动器上存在的HTTP请求发出的对资源的任何请求。

文件系统是相当简单的机制。当发出访问文件的请求时，如果该文件存在，则该请求将传递到授权子系统，如果被授权，则原始请求会得到满足。如果资源不存在或未被授权，则系统将引发异常。当应用程序发出请求时，将设置触发器并等待应用程序。响应请求后，将引发触发器，并且应用程序将处理请求响应。直到今天仍然如此。如果应用程序认为请求已得到满足，则该请求将继续；如果请求失败，则该应用程序将在其代码内执行错误条件；如果未处理，则死亡。简单。

对于Web服务器，假定发出了对路径/文件的URL请求，则Web服务器将采用URL请求（URI）的路径/文件部分，然后向文件系统发出请求，并且该请求可以满足或引发异常。然后，Web服务器处理响应。例如，如果找到了所请求的路径和文件并由授权子系统授予了访问权限，则Web服务器将照常处理该I / O请求。如果文件系统引发异常，则如果未找到文件，则Web服务器将返回404错误，如果未授权原因代码则返回403禁止。

由于某些操作系统区分大小写，并且这种类型的文件系统需要完全匹配，因此Web服务器请求的路径/文件必须与硬盘驱动器上存在的完全匹配。这样做的原因是简单的。Web服务器不会猜测您的意思。未经编程，没有计算机会这样做。Web服务器在接收到请求后便对其进行处理。如果直接传递给文件系统的URL请求的路径/文件部分与硬盘驱动器上的内容不匹配，则文件系统将引发异常，并且Web服务器将返回404 Not Found错误。

真的是那么简单的人。这不是火箭科学。URL的路径/文件部分与文件系统之间存在绝对关系。

1. URL声称是UNIFORM资源定位器，可以指向Web之前的资源。其中一些是区分大小写的（例如，许多ftp服务器），URL需要能够以合理直观的方式表示这些资源。

2. 在寻找匹配项时（无论是在OS中还是在OS之上），不区分大小写都需要进行更多工作。

3. 如果将URL定义为区分大小写，则各个服务器可以根据需要将它们实现为不区分大小写。反之则不成立。

4. 在国际环境中，不区分大小写可能很重要：https： //en.wikipedia.org/wiki/Dotted_and_dotless_I。RFC1738还允许使用ASCII范围以外的字符，只要它们已编码但未指定字符集。这对于将自己称为“万维网”的事情来说非常重要。将URL定义为不区分大小写将为bug打开很多范围。

5. 如果您尝试将大量数据打包到URI中（例如Data URI），则在区分大小写的情况下可以打包更多数据。

我从博客中窃取了一个“新旧事物”的习惯，以“为什么会这样？”的形式来回答问题。提出反问“如果不是这样，世界会是什么样？”

假设我设置了一个Web服务器来为我自己的文件夹提供文档文件，以便我不在办公室时可以在电话上阅读它们。现在，在我的文档文件夹中，我有三个文件todo.txt，ToDo.txt并且TODO.TXT（我知道，但它是有意义的我，当我提出的文件）。

我想使用什么URL来访问这些文件？我想使用来以一种直观的方式访问它们http://www.example.com/docs/filename。

假设我有一个脚本，可以将联系人添加到我的地址簿中，也可以通过网络进行添加。应该如何采用其参数？好吧，我想像这样使用它http://www.example.com/addcontact.php?name=Tom McHenry von der O'Reilly。但是，如果我没有办法按大小写指定名称，该怎么办？

如何区分Cat和CAT，文本和文本，乳胶和LaTeX的Wiki页面？我想，页面有歧义，但是我更喜欢得到我想要的东西。

但是无论如何，这一切都感觉像是在回答错误的问题。

我认为您真正要问的问题是：“为什么Web服务器404只是为了区分大小写，而当它们是计算机时，它们旨在简化生活，并且它们完全有能力找到至少最明显的大小写变化。我输入的网址行得通吗？”

答案是，尽管某些站点已经做到了这一点（更好的是，它们也检查了其他错别字），但是没有人认为值得更改网络服务器的默认404错误页面来做到这一点……但是也许他们应该这样做？

虽然以上答案是正确和良好的。我想补充一点。

为了更好地理解，应该了解Unix（Linux）与Windows服务器之间的基本区别。Unix区分大小写，而Windows不区分大小写。

HTTP协议是在1990年左右演变或开始实施的。HTTP协议是由CERN研究所的工程师设计的，在大多数时候，科学家使用的是Unix计算机，而不是Windows。

大多数科学家都熟悉Unix，因此他们可能受到Unix样式文件系统的影响。

Windows Server在2000年之后发布。在Windows Server成为流行的HTTP协议之前，它就已经很成熟并且规范已经完成。

这可能是原因。

应该怎么读“为什么要这样设计？” 题？您是要对决策过程进行历史准确的说明，还是要问“为什么有人会这样设计？”？

很少有历史记录的帐户。有时，当在标准委员会中做出决定时，会有关于辩论进行方式的文献记录，但是在网络成立初期，一些人匆忙地做出了决定（在这种情况下，可能是TimBL本人做出的），因此基本原理不太可能被写下来。但是TimBL承认他在URL的设计上犯了错误-参见http://www.dailymail.co.uk/sciencetech/article-1220286/Sir-Tim-Berners-Lee-admits-forward-slashes-web-address -mistake.html

在早期，URL非常直接地映射到文件名，并且文件通常位于类Unix的计算机上，类Unix的计算机具有区分大小写的文件名。因此，我的猜测是，这样做只是为了实现实现的便利，而从未考虑过（对于最终用户）可用性。再有，在早期，用户都是Unix程序员。

这与您在哪里购买域名无关，DNS不区分大小写。但是，用于托管的服务器上的文件系统是。

这并不是真正的问题，在* nix主机上相当普遍。只要确保您在页面上编写的所有链接都是正确的，就不会有问题。为了简化操作，我建议您始终以小写形式命名页面，这样在编写链接时就无需再次检查名称。

Closetnoc对操作系统是正确的。某些文件系统将相同的名称用不同的大小写视为不同的文件。

另外，区分大小写的URL是否有真正的目的/优势（与大写字母指向同一页面的大多数URL相对，无论大小写都相反）？

是。以避免重复的内容问题。

例如，如果您具有以下URL：

http://example.com/page-1
http://example.com/Page-1
http://example.com/paGe-1
http://example.com/PAGE-1
http://example.com/pAGE-1

并且他们都指向内容完全相同的页面，那么您将拥有重复的内容，并且我确定您是否拥有Google搜索控制台（网站站长工具）帐户，Google会向您显示。

在这种情况下，我建议您使用所有小写的URL，然后将其中至少包含一个大写字母的URL重定向到小写版本。因此，在上面的URL列表中，将所有URL重定向到第一个URL。

区分大小写确实有价值。

如果有26个字母，则每个字母都有大写的能力，即52个字符。

4个字符具有52 * 52 * 52 * 52组合的可能性，等于7311616组合。

如果无法大写字符，则组合的数量为26 * 26 * 26 * 26 = 456976

52个字符的组合是26个字符的组合的14倍以上。因此，用于存储数据的Urls可以更短，并且可以通过较少的数据传输通过网络传递更多的信息。

这就是为什么您使用诸如https://www.youtube.com/watch?v=xXxxXxxX之类的网址看到youtube的原因