我应该在URL中使用标题大小写吗？

我们目前正在确定具有多个Web应用程序的网站上的一致命名约定。从历史上看，我一直倡导“小写所有字母！” 创建网址时：

http://example.com/mysystem/account/view/1551

但是，在过去的一两年中，特别是自从我开始使用ASP.NET MVC并开始处理基于REST的URL以来，我一直喜欢将URL中每个节/单词的首字母大写更容易阅读（恕我直言）。

http://example.com/MySystem/Account/View/1551

我们不会处于人们需要阅读或能够理解URL的情况，因此这本身不是驱动程序。我们追求的主要目标是一种合理且有意义的一致方法。

是否有任何标准声明一种方法或另一种方法是好的，或者我们可能会遇到（至少现实地是现代的）设置会优先选择另一种设置的问题？目前对此辩论的普遍共识是什么？

由于选择主要是美观的（即，大多数系统不区分大小写，而用户肯定不区分），所以我建议您选择一个让您满意的方法。应用程序内的一致性是关键，而不是您选择的方式。

当您使用ASP.Net时，建议您使用PascalCase方法-因为这是Microsoft框架（系统库等）中经常存在的内容，但是除了保持一致之外，没有“最佳实践”。

大多数浏览器在向用户隐藏URL方面做得相当好，以至于很多以google为主页的人都将搜索Facebook并单击它-而不是在他们的主页中输入facebook网址。浏览器。

对于内部网站，无关紧要，只要您与之保持一致即可。

对于外部的，面向公众的站点，您可能希望坚持使用小写字母，这或多或少是Linux / Apache Web托管中的标准。我记得，某些版本的Firefox处理URL大小写的方式似乎也不同于IE。这也可能适用于Chrome。

大小写一致对于搜索引擎优化也很重要。您不希望Google将lower-case.aspx和Lower-Case.aspx视为具有重复内容的不同页面。尽管他们的算法试图防止这种错误的身份，但确实会不时发生，并可能导致页面受到惩罚。

只要用户可以按自己的意愿键入它，就没有关系。就个人而言，我更喜欢TitleCase，但有许多人不同意。如果您保持一致，没有人会介意。

如果您的网络服务器由于某种原因无法显示给http://foo.com/HelloWorld我，请尝试http://foo.com/helloworld选择全小写。尽管如今人们很少键入完整的URL，但是应该可以访问前端地址，而不必大写。

您开始使用MVC的过程不应“泄漏”到REST抽象中。有充分的理由将所有小写的URL都使用单词之间的破折号。URI（不是域名）区分大小写。如果您将所有内容都小写并使用破折号来分隔单词，则可以消除很多猜测工作和一次性操作，并且如果您使用代理服务器（nginx，nodejs，apache ...），您将不会破坏一切因为它突然区分大小写。

“ MiXeD-CaSe NaMeS。不要通过在URL中混合大小写字符来混淆用户。请坚持使用小写字母，不要让他们猜测。如果您的用户实际上以大小写混合的形式输入URL，在服务器上对其进行规范化并提供适当的大小写”。

尽管TLD不区分大小写，并且Windows路径使用大写和Pascal大小写的组合，但是我们的应用程序对传入的请求路径敏感，其中路径或其中的组件通常被规范化为标准大小写，因为/format/JSON/和/format/json/是两个请求不同的格式，并引用两个不同的资源。

每当我看到http://www.somewebsite.com/Having/URLs/That-Look-Something-Like-This/时，我都觉得开发人员的意图主要是与其他人有所不同，但这没什么创新，而且也无助于提高可读性，尤其是在您拥有I和l，O和0以及其他竞争分析的字母的情况下。

我不知道有任何共识，也不相信应该有一个共识，因为仅将URL的某些部分大写这样简单的事情就可能对可读性产生积极影响，而且我敢肯定有人已经在某个地方出现了在将字母大小写应用于URL方面有一些有趣的想法。

但是，考虑到大多数Web服务器都在Linux上运行，并且由于输入区分大小写，我们的开发人员总是最终最终使输入的文本数据标准化，所以我一直坚持这样做的方式。

出于可用性原因，切勿使用标题大小写！想象一下，您应该花多少时间点击才能在您的MOBILE手机中执行不同大小写的URL ！