URL结构:小写 VS 大写

39

我在浏览一些网站时,突然想到一个问题:它们的url中包含大写字母和小写字母的组合,例如http://www.domain.com/Home/Article

现在,我知道我们应该始终在url中使用小写字母,但不清楚技术原因。我希望从您这位专家那里学习,以澄清为什么在url中使用小写字母。大写url的优缺点是什么。


一些最大的网站甚至没有遵循或执行这个……这并不是被认为是最佳实践的东西。 - Hugo
参考:Google网络管理员趋势分析师[John Mueller说](https://twitter.com/JohnMu/status/877952088030007297):“URL区分大小写,但选择任何大小写都可以。” - showdev
这个回答解决了你的问题吗?URL 区分大小写吗? - TylerH
4个回答

52

域名部分不区分大小写。 GoOgLe.CoM 会起作用。您可以按照自己的意愿添加大写字母,但通常没有这样做的理由,并且可能会影响您的SEO排名,如下面的评论所述。

路径部分大小写敏感或不敏感,具体取决于服务器环境和服务器。通常情况下,Windows机器不区分大小写,而Linux机器区分大小写。这意味着您应该坚持使用小写字母,否则可能会引入一个很难追踪的错误(在开发服务器上不重要的大小写不匹配)。

查询字符串部分按原样提供给服务器。您可以随意使用混合大小写,或者丢弃大小写(toLowerCase(...))。这也意味着使用base64编码的键是可行的。但是,您不能指望用户正确地输入它们。

哈希部分(称为“片段标识符”)仅对客户端代码可用,而不对服务器可用。Javascript可以根据喜好区分大小写,浏览器也一样。 url#a 将滚动到ID为a的元素,但 url#A 不会。


7
从 SEO 的角度考虑,您应该使用全部小写字母,因为 Google 将会把 www.domain.com/Home/Articlewww.domain.com/home/article 视为两个不同的页面,这将影响它们的搜索排名。 - oenpelli
2
路径部分是区分大小写的,无论使用哪种服务器软件,/Home/home都是不同的URL。 - Daniel W.
1
URL始终区分大小写,但可以视为不区分大小写。请阅读http / html / url / uri规范https://www.w3.org/TR/WD-html40-970708/htmlweb.html。 - Daniel W.
1
片段标识符(“#hashtag”)不可用于服务器,因为它不是HTTP协议的一部分。 - Daniel W.
1
@JanDvorak 片段标识符是 URI 的一部分,但不是 HTTP 协议的一部分。URI 不仅可以是 http://...,还可以是 irc://... 等等。 - Daniel W.
显示剩余9条评论

18

我不得不反对所有已有的智慧,所以可能会被踩,但是:

如果你将所有大小写混合的网址重定向到正确大小写的网址,它可以解决提到的所有问题。因此,这个争论似乎来自传统和偏好。一个URL的目的是拥有一个用户友好的页面表示方式,如果你的URL使用大写更加友好,为什么不用呢?比较一下:

moviesforyoutowatch.com/batman-vii-the-dark-knight-whatevers MoviesForYouToWatch.com/Batman-VII-The-Dark-Knight-Whatevers

我认为混合大小写版本更适合此目的。如果有技术上的原因不能用小写进行比较和重定向,请分享。


7
混合大小写的问题出现在社交媒体上。如果你关心Facebook点赞,那么需要知道Facebook分享链接是区分大小写的。如果因为某些原因,有人以小写形式分享了你的链接,那将是一个不同的链接。这就是为什么安全的做法是坚持使用全部小写而不是混合大小写。此外,用户并不会查看URL,他们只会点击链接。 - Ross
3
如果由于某种原因,有人使用大写字母分享了您的URL,那就是一个不同的URL。这就是为什么安全起见最好坚持使用全部大写字母,而不是大小写混合的方式。 - Gqqnbig
2
如果由于某种原因,有人在KEBABCASE中分享了您的URL,那就是一个不同的URL。这就是为什么安全的方法是坚持使用所有KEBABCASE而不是混合大小写的原因。 - Vad
1
如果由于某种原因,有人使用SNAKE_CASE分享了您的URL,那就是一个不同的URL。这就是为什么安全起见最好坚持使用全部大写的SNAKE_CASE而不是混合大小写的方式。 - 无名小路
1
如果由于某种原因,有人在CamelCase中分享了您的URL,那就是一个不同的URL。这就是为什么安全的方法是坚持使用全部CamelCase而不是混合大小写的原因。 - Dimi Ansari
如果由于某种原因,有人以nUtCAsE的形式分享了您的URL,那就是一个不同的URL。这就是为什么安全的方法是坚持使用全部nUtCAsE而不是混合大小写的原因。 - Conan

13

我知道你要求技术方面的原因,但从用户体验的角度考虑也是值得考虑的。

假设你有一个包含大写字符的URL,且该URL已经在印刷媒体上分发。当用户尝试在浏览器中输入该URL时,他们可能会被迫匹配该大小写(或者如果你的Web服务器区分大小写,则被迫匹配指定的大小写),这实际上增加了他们的工作量,因为他们必须考虑大小写。毕竟,他们不知道你的服务器是否区分大小写,而且他们可能在过去遇到过来自区分大小写Web服务器的404错误。

如果您的服务器区分大小写并且正在使用混合大小写URL,则可以给用户更多的机会来输入URL。此外,假设您有URL www.example.com/Contact. 如果用户忽略了大小写,使用了错误的大小写,那么他们可能永远无法到达您的内容。

考虑到所有这些问题,请使用小写字母的URL,例如www.example.com/news/articles/freeicecreamforall。在键盘上输入还好,但在移动设备上输入将非常麻烦。

反过来,如果用户想从地址栏中写下URL,他们可能觉得需要匹配大小写,这最终会增加他们的工作量并增加错误的可能性。

总之,请使用小写字母的URL。


-19

关于此问题的安全方面:

实际上,使用大小写混合有一个很好的安全理由。

它会使攻击者感到困惑和阻塞!

在人类交流中,人们很容易因为大小写的使用而感到困惑。

如果标识符、密码或URL包含大小写字母,人类就无法清晰地“说出”这些单词。

这有助于保护站点子部分上提供的数据或密码的安全性,这些数据或密码是作为站点或其数据的“自动访问”部分的一部分提供的。

这类似于不使用JSON。

JSON是“可读文本”,因此JSON只是向所有攻击者(包括窃取您的想法和数据的政府、谷歌等)提供了几乎所有他们需要了解的数据……使用私有定制的非常快速的“二进制协议”来混淆他们,使用您自己的“不可知数据结构”更加安全……但要注意,实际上可能会使您自己或您自己的开发团队感到困惑。

为避免混淆,必须“良好管理”所有安全层和协议。

因此,通过使用完全非传统的系统(即为什么任何人都想要使用“标准安全协议”时,通过一些简单的重量级先前计算它们都可以轻松破解),可以获得来自人类攻击者(和一些机器人)的额外站点和数据安全级别。

只需“盐和哈希”一切-并添加一些额外的定制安全性-这只是常识!

结论:以上所有答案都非常清晰和正确-但您也可以愉快地利用相同的知识来混淆潜在的攻击者。


10
通过隐秘性来实现安全是薄弱的安全措施。此外,“攻击者”不会使用语音进行沟通。即使忽略了传输案例更加容易这一点,电子邮件也要可靠得多。 - John Dvorak
非常感谢你的负分评价(哇啊啊)...然而我仍会坚持我的观点和答案,因为即使是英国政府通信总部也无法解密二战时期的历史军事编码信息,因为ALICE和BOB使用了“独特于他们”的加密算法,这些算法并不标准,并且他们事先达成了协议,所以即使在今天,即使EVE(拥有GCHQ所有权力)也无法解密他们的消息。 - Clive Williams
3
URL 应该能够被人类读懂。如果您认为用户能够访问您的网站是安全问题,那么就不要在网络上发布。 - sba
我们将不得不持有不同意见,因为在Inferix Sentient AI,最重要的是我们的主要非人类(AI实体)有权访问,因此我提到了预先协商的非标准协议。我们需要让我们最聪明的人类(在切尔滕纳姆)有权访问,但对于不属于该组的人类则没有访问权限 - 因此,使用复杂规则和使用非标准协议对我们来说是最好的选择 - 因此(对于我们而言),通常是关于阻止访问并为访问制造“人类死胡同”。直接访问您的思想或工作场所的“集体智慧”是您希望阻止的事情 - 但有时允许“信任的人”访问! - Clive Williams
2
原创思路和精美的写作。从技术上讲,我必须同意“安全性靠混淆”是较低级别的形式,因此这不是正确的方法。把钥匙放在门垫下不是专业软件解决方案的方式。但请将此答案保留为此想法-虽然不是微不足道的-可能会在其他人中发芽。 - Bart

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接