在过去的几年里，我对可用性和网页设计产生了兴趣。 在网站设计中，一个经常被忽视的领域是网站上URI的设计。现代CMS系统允许在一定程度上自定义 URI，但默认值通常不如其应有的可用性高，并且 URI 通常在设计流程中被放在最后。
简洁的 URI 是简洁网站的一个组成部分，也是一个重要的组成部分。 大多数最终用户访问互联网都涉及到 URI，无论用户是否实际输入 URI，他们都在使用它。
首先，我想谈谈 URI 设计背后的指导原则，然后谈谈这些原则的实际实施。
注意：最初，我在撰写本文草稿时使用了“URL”一词，但由于“URL”已被“URI”取代，我已更新为使用“URI”一词。 来自 W3C 的更多信息。
原则
首先，让我们看看一些 URI 设计的一般原则。
URI 必须唯一且永久地表示一个对象
URI 最基本的理念之一是它代表互联网上的一个数据对象。 URI 必须是唯一的，以便实现一对一匹配——每个数据对象对应一个 URI。
虽然这始终是目标，但在某些情况下，实现起来非常困难或不可能。 规范 URL 标签的发明是为了帮助减少搜索引擎看到的重复内容的数量。 虽然这不是最终的解决方案，但强烈建议使用规范 URL，因为 Google 等大型搜索引擎现在正在关注它们。 有关规范 URL 的更多信息，请查看 SEOmoz 的这篇文章。
URI 也应该是永久的（即，选择 URI 一次，然后保持不变）。 这说明了在网站启动之前进行良好的 URI 设计，并仔细计划 URI。 会有那么一天，您希望改进您的选择或出于其他原因必须更改 URI 结构。 当这成为必要时，请务必设置 HTTP 301 永久移动 重定向到您的服务器上。 这会告诉浏览器和搜索引擎内容的新位置，并保留旧 URI 累积的任何 PageRank。
尽可能人性化
这是 URI 设计（或应该成为）最基本的驱动力。 URI 的设计应以最终用户为中心。 搜索引擎优化 (SEO) 和开发简易性应放在第二位。
保持 URI 对用户友好的方法之一是使其简洁明了。 这意味着在保持可用性的同时使用尽可能少的字符。 因此，/about 比 /about-acme-corp-page 更好。 虽然努力使其尽可能短，但它不应牺牲用户友好性而使用诸如 /13d2 之类的 URI，因为这对最终用户没有任何意义。
相反，建议在共享 URI 时使用 短链接。 这非常适合在 Twitter 上发布链接，或在 Facebook 或 Google Buzz 等社交网站上共享。 如果出于 SEO 原因您可以控制自己的 URI 缩短器，那将非常棒，尽管像 Bit.ly 这样的网站也很好。 我个人使用 PrettyLink Pro（一个 WordPress 插件）来创建我的短 URI。 另一种选择是 Short URL 插件。
WordPress 提供了一个按钮，可以根据 WordPress 自己的 /?p=XXX 格式获取文章的短链接，该格式可能比您选择的永久链接结构更短。 优点是只要您的网站存在，它就会起作用。 缺点是链接的短度取决于您域名名的长度。
URI 不应依赖于与内容或用户无关的信息。 一个常见的例子是使用数据库 ID 作为 URI，例如 /products/23。 最终用户并不关心该产品是数据库记录编号 23，因此诸如 /products/ballpoint-pen 之类的 URI 更好。 采用这种糟糕的 URI 结构可能很诱人，因为它在后端使用 ID 查询数据库通常更容易，而不是必须对别名进行查找以找到对象。
判断 URI 是否为用户友好 URI 的一个好方法是“语音友好”测试。 您应该能够在与朋友的对话中提及一个 URI，并且它应该是有意义的。 例如
我的个人资料在 domain dot com 斜杠 jim
而不是
我的个人资料在 domain dot com 斜杠 page 斜杠 g g 2 3
一致性
整个网站的 URI 必须在格式上保持一致。 选择 URI 结构后，请保持一致并遵循它！ 对网站的一部分拥有良好的 URI 结构意味着您总体上仍然拥有糟糕的结构。 为了让用户相信 URI 在网站上的工作方式，格式必须一致。 如果您必须切换结构（也许您正在更新一个设计糟糕的网站），请使用前面提到的 301 重定向。
“可修改”的 URI
与一致性相关的是，URI 的结构应使其可以理解地“可修改”或可更改。 例如，如果 /events/2010/01 显示 2010 年 1 月的月历，其中包含 1 月的事件，那么
- /events/2009/01 应显示 2009 年 1 月的事件日历
- /events/2010 应显示 2010 年全年的事件
- /events/2010/01/21 应显示 2010 年 1 月 21 日的事件
关键词
URI 应由与页面内容相关的关键词组成。 因此，如果 URI 是针对一篇标题很长的博文，则只有对页面内容重要的词语应该包含在 URI 中。 例如，如果博文是“我的百思买内存卡之旅”，那么 URI 可能是 /posts/2010/07/02/trip-best-buy-memory-cards 或类似内容。
作为额外的好处，在 URI 中使用重要的关键词将提高 SEO。 我个人的 SEO 理念是，与其为了搜索引擎而优化，不如为了优质内容而优化。 搜索引擎的目标是找到网络上最好的内容，因此，在我看来，尽一切努力创建一个易于使用的网站，提供很棒的内容和进一步信息（链接）的机会，将产生搜索引擎可见性的最佳长期效果。
技术细节
我们已经介绍了一些 URI 设计背后的指导原则。 现在，让我们看看这些指南的一些技术实现。
没有底层技术的痕迹
URI 不应附加 .html、.htm、.aspx（一个很大的烦恼）或任何其他仅用于显示底层技术的内容。 没有任何最终用户关心您的网站是用 ASP.NET（.aspx）、ColdFusion（.cfm）编写的，或者使用了服务器端包含（.shtml）——至少大多数最终用户不关心。 这些额外信息只会增加输入量，并增加出错和令人沮丧的可能性。
此规则的一个例外是将 URI 附加后缀，如 .atom、.rss 或 .json，以请求返回特定格式。 或者，可以使用 Accept HTTP 标头请求格式。
不使用 WWW
网站 URI 中应该去除 www.，因为它是多余的输入，违反了尽可能人性化以及 URI 中不包含多余信息的原则。
然而，许多用户仍然会输入 www. 前缀，因此 www.domain.com 应该 301 重定向到 domain.com。同样的，www.subdomain.domain.com 也应该 301 重定向到 subdomain.domain.com。
格式
URI 应该采用以下格式：
domain.com/[关键信息]/[名称]/?[修饰符]
关键信息是指并非对象标识符（例如帖子标题），但对于访问的对象仍然至关重要的信息。这可能包括：
- 事物的类型（例如帖子）
- 总体父类别（例如技术）
- 关键数据成员（例如发布日期）
修饰符修改视图，而不是表示的数据模型，因此它们是查询字符串的一部分，而不是 URI 本身。
“关键信息”的数量应该保持最少，因为 URI 不应该过度嵌套。关键信息部分中的每个项目都必须真正是解决页面的关键。
最终，URI 应该表示一个递降的层次结构。例如：
- 域名
- 类型
- 类别
- 标题
例如：http://domain.com/posts/servers/nginx-ubuntu-10.04。对于包含日期的项目，格式应遵循递降的层次结构：
- 年份
- 月份
- 日期
例如：http://domain.com/news/tech/2007/11/05/google-announces-android。
Google 新闻对希望出现在 Google 新闻结果中的网页有一些有趣的要求——Google 要求至少使用一个 3 位的唯一数字。由于他们会忽略看起来像年份的数字，因此建议使用 5 位或更多位的数字。还建议使用Google 新闻站点地图。在某些情况下，如果你必须针对 Google 新闻，则必须符合这种较差的 URI 结构。但是，如果你必须这样做，请确保保持一致，并且它仍然可操作（例如，使用 yyyymmdd 格式，如 20100701）。
全部小写
所有字符都必须是小写。当涉及混合大小写时，尝试向他人描述 URI 几乎是不可能的。
如果有人输入混合大小写的 URI，则应将其 301 重定向到小写页面。这听起来很棒，但在实践中，我不确定这是否可行……使用重写所有请求到单个文件的 CMS 将是最简单的实现方式，因为脚本可以发出 301 到小写，但我不确定是否有更简单的方法（.htaccess 规则或其他）。
附加到 URI 的操作
操作可以附加到 URI，例如 show、delete、edit 等。非破坏性操作（不会更改对象的操作）应该使用 HTTP GET 请求，而破坏性操作应该 POST 到 URI。有关更多信息，请在 Google 上搜索 REST URI 设计。
URI 标识符应使其对 URI 友好
URI 可能包含帖子的标题，并且该标题可能包含对 URI 不友好的字符。因此，必须使该帖子标题对 URI 友好。例如：
- 所有大写字符都转换为小写
- 像 é 这样的字符应该转换为 e（等等）
- 空格应该用连字符替换
- 未知字符（!、@、#、$、%、^、&、* 等）应该用连字符替换
- 双连字符（–）应该替换为单个连字符
- 可能还有更多我忘记的规则
字符可以进行 URI 编码（例如空格字符的 %20），但这通常不是一个好主意，原因与上述许多原因相同（显示技术、不必要的输入等）。
有趣的想法
使用类似句子的结构（感谢Chris Shiflett）
chriscoyier.net/authored/digging-into-wordpress/
chriscoyier.net/has-worked-for/chatman-design/
chriscoyier.net/likes/trailer-park-boys
jacobwg.com/thinks/this-post/is/basically-done
如果你知道我错过的任何其他 URI 指南，或者对我想起的那些指南有任何意见，我很乐意听取你的意见！
鸣谢
非常感谢Forrst 社区，他们看到了这篇帖子的最初（非常）粗略草稿并贡献了许多有见地的评论。特别感谢@chriscoyier、@caludio、@steerpike 和 @mattthehoople 对指南列表的直接贡献，以及所有其他 Forrst 评论者提供的有益讨论。
感谢我的爸爸校对和审阅！还要感谢 Chris 愿意在 CSS Tricks 上发布这篇帖子！
“没有底层技术的证据”
你如何建议准确地做到这一点？
我知道一种方法，但这似乎有点太复杂了……
使用 CMS 应该可以解决这个问题……几乎所有现代 CMS 都以隐藏 .html（等）部分的方式管理干净的 URI。
至于 .rss 或 .atom，你可以在 CMS 中使用自定义别名设置它（我在想 Drupal），但我见过的最简单的实现来自 Ruby on Rails。
绝对的。Rails 使这变得轻而易举 :)
没错，但我不是 CMS 人员（至少现在还不是 :P）
所以基本上问题是：如果你正在编写一个纯 HTML 网站或不使用 CMS 的东西，你会怎么做。
你需要使用 modrewrite（在 apache 上）将最终用户的 url 修改为你内部使用的任何 url。
基本上，你在网站的 .htaccess 文件中放置一组规则（在 Google 上搜索 htaccess & modrewrite），这些规则会完成重定向网站到其应在位置的繁重工作。
执行此操作的“最坏情况”方案是使用 Web 服务器的默认页面处理功能并在层次结构目录结构中组织你的网站。基本上，每个帖子都成为相应子目录中的一个“index.html”文件。
因此，如果你将 example.com/news 作为 URI，你只需在 /news 目录中放置一个 index.html 文件，它就会“隐藏”正在使用的底层技术。
当然，这有点笨拙，但如果你有一个简单的几页宣传册网站，它可能是可以接受的。
@Speedgun
这里建议的所有解决方案都适用。但是，最简单的方法是在服务器配置或 .htaccess 中使用 Apache 的 DirectoryIndex 指令。
DirectoryIndex 基本上告诉 Apache：“如果未指定文件，则使用此文件”。因此，“DirectoryIndex index.php”将导致http://www.foo.com/bar 实际上访问http://www.foo.com/bar/index.php
当然，对于比几页更复杂的任何内容，其他解决方案效果更好，但这应该可以帮助你在更简单的网站上入门。
使用 apache MultiViews。这样，当你“GET /some/path/file”时，apache 会在“/some/path/”中查找“file.*”并使用正确的 MIME 类型和语言发送它。非常好。
Og 创建一个“file.var”定义根据浏览器请求发送的内容。
有很多可能性。
你使用 Apache 的 Rewrite，而不是 Multiviews 或奇怪的目录结构。要点是用户向服务器请求 URL，并且该 URL 根据某些规则重写，然后重写的 URL 是服务器用来返回页面的内容。
最简单的例子就是重写 URL，在末尾添加“.html”。所以用户请求 /foo，你将其重写为 /foo.html 以返回实际的文件。
如果 URL 中包含下划线，对于几乎所有用户来说都很难输入。因此，如果你有 /what_are_they.html，不要提供该链接，而是使用 /what/are/they，并将斜杠重写为下划线并添加“.html”，正确的文件将被返回。
我个人喜欢直接使用文档标题，将其转换为小写，用斜杠替换空格，作为 URL。例如，CSS-Tricks 上的文章“Guidelines for URI Design”将变为
https://css-tricks.org.cn/guidelines/for/uri/design
然后在整个网站中，链接应该是什么就一目了然了。你可以根据文章的名称推断出 URL。这使得链接出错的可能性大大降低。
如果标题更改，我会保留原始 URL，但添加重定向到新文章，这样旧标题就变成了新标题的同义词，而不是 404 错误。
关于 Hamranhansenhansen 的评论
我不同意用斜杠替换空格是最佳解决方案。斜杠代表目录，目录通常是组织信息的分层方式。人们理解这种约定，机器也肯定理解。
例如“/guidelines/for/uri/design”几乎可以接受，尤其是在网站有多篇标题以“guidelines”开头的文章时，但斜杠方法往往会错误地表达它指向的内容。
考虑一下——如果我看到一个 URL，例如 example.com/guidelines/for/uri/design，我就会认为可能在 example.com/guidelines/ 地址下还有更多文章。尽管这个地址可能什么也没有，只有 404 错误。
因此，我建议将斜杠用于帮助组织网站内容的实际分层目录，并使用连字符“-”替换页面标题中的空格——就像这篇文章的规范 URI 所做的那样。
对于静态网站，我可能会使用 .htaccess 重写规则（或者如果您不使用 Apache，则使用 Nginx 配置）来获取干净的 URI。我假设这是一个相对较小的网站（因为它静态的），所以您可能可以在每次添加页面时更新 .htaccess 规则（显然，对于大型网站来说，这很不实用）。
欢迎访问 我的网站 联系我，我很乐意帮助您处理重写规则。
静态或动态都没有关系。两者都使用 URL。使用重写所做的只是将干净的 URL 转换为技术 URL。因此，您可以将 /products/foo 重写为 /products.php?item=foo 或重写为 /index.html?page=products&item=foo 或您需要的任何内容。
另请参阅
酷！感谢您的解决方案！
是的，谢谢 :)
注意以上关于“www”的指南。如果您运行一个大型网站，请记住，从 .domain.com 提供的 Cookie 会随每次 HTTP 请求一起发送。如果您有大量子域名，您可能需要考虑将所有主要流量重定向到 www，以便您可以从另一个子域名提供例如图片，而无需所有 Cookie 流量。
请注意许多大型网站的做法，例如 Facebook。
这真的很有趣！我之前没有考虑过 Cookie 问题。所以，您的意思是，从 http://domain.com 设置的 Cookie 会发送到 http://*.domain.com 的所有请求？我绝对不是 Cookie 专家！
一种可能的解决方法是为静态内容使用单独的域名，或者可能只使用 CDN URI。但这不如使用 static.domain.com 干净。但是，最终用户是否关心静态域名？
这可能是现实使遵循乐观指南变得不便的地方之一。不过，在我的网站上，我获得的流量（基本上没有），这可能不是问题……
是的，就是这样。但是几乎所有语言都可以指定。例如
setcookie(“TestCookie”, $value, time()+3600, “/scripts/”, “.example.com”);
因此，此 Cookie 仅在“/scripts”目录中可用，但会发送到 example.com 的所有子域名。
setcookie(“TestCookie”, $value, time()+3600, “/”, “www.example.com”);
此 Cookie 仅在发送到 http://www.example.com 的所有请求时发送，但当然，必须由 http://www.example.com 设置。
使用 www 意味着如果您从 media.example.com 或 img.example.com 提供图片，这些请求将不会转发 Cookie。您说得对，使用 examplecdn.com 会达到同样的目的，但您需要多个域名。
我也不会将 URI 的 www 部分称为“不必要”的信息——它是 Web 服务器的主机名。
这在各种情况下都非常重要，包括上面提到的 Cookie 方面。其他立即想到的是对边缘缓存的影响、内联网站点、SSL 流量（因为 http://www.domain.tld 和 domain.tld 可能不会解析到相同的 IP 地址），等等。
关于“www”建议的另一个缺点：发送大量 301 重定向来更改 URI 会降低页面加载速度，因为需要额外访问服务器才能获取重定向。
Yahoo! 对 比重定向更快/更好的替代方案 进行了精彩的讨论。我喜欢使用 mod_rewrite。
非常有趣的一篇文章！
顺便说一句，完全不相关，但你是如何让 Chrome 看起来像那样的？我非常喜欢的第一个修改！
这不是 Chrome。它是 Safari 浏览器。
它似乎是 Chrome 的 Mac 版本。Safari 的标签看起来有点不同。
是的，那是适用于 Macintosh 的 Chrome。
适用于 Mac 的 Chrome 在按钮周围有边框。如果您知道如何关闭它们，请告诉我。这样看起来真的很酷。
不错的文章。您对分页 URL 有什么想法吗？（例如 blah.com/widgets/blue/page-16 或 blah.com/widgets/blue?page=16 或其他）
还有……您对“按…排序”的 URL 有什么看法？（例如 blah.com/widgets/blue?sort=price）
我会倾向于将分页放在查询字符串中（例如 blue?page=16），因为它是一个视图修改器，而不是一个对象（“按…排序”的 URI 也是如此）。
由于 URI 应该永久存在，因此执行类似 blah.com/widgets/blue/page-16 的操作会违反该规则，因为页面的内容会随着新蓝色小部件的添加而不断变化。:) 有道理吗？
另外相关的一点——我真的很不喜欢分页系统将第二页设为 ?page=1。这可能会让人非常恼火，尤其是在您尝试“破解”到更深层的页面时，并且必须记住 URI 中的页码比实际页码少 1。:)
这似乎很明显，但许多网站都使用这种 URI 方案。
因此，指南
* /list
* /list?page=2
* /list?page=3
* 等等。
也对这个问题感兴趣。
Jacob 的回答是正确的。原因是“/widgets/blue”告诉我我正在查看蓝色小部件的资源，而查询 ?page=16 则表示我已告诉您的服务器发送给我蓝色小部件资源的特定子集。
之所以这样做是最佳实践，是因为 HTTP 协议是无状态的。这意味着当我访问 URI 时，我应该检索其正确的表示形式，而不管我在网站上执行的其他任何操作。
URI 中的查询参数应告诉服务器如何发送回资源（例如，特定子集）。不要将此与发送回资源的表示形式混淆（例如 xml、html 或 json），HTTP 的 Accept 和 Content-Type 标头决定这一点。
很棒的解释！
感谢 Jacob！这是一篇关于通用资源设计和 RESTful 原则介绍的精彩文章。干得好！
我有一个关于包含目录的 URL 的问题。一位同事说，应该将所有文件都放在网站的根目录下，这样看起来就像这样：http://www.domain.com/kevin，而不是 http://www.domain.com/about/kevin
他们说这样做是为了 SEO 目的；说页面在根目录下排名更好。我对此进行了一些研究，普遍共识似乎并非如此，并且 URI 中包含多少个目录并不重要。而且，它不应该重要是有道理的，因为 Google 唯一关心的是内容。我知道过去 Google 确实关心 URL 及其形成方式，例如包含长数据库 URL 以及 & 和数字等。
您对此有何看法？我多年来一直试图向我的老板解释这一点，但他们就是不听。
谢谢！
Kevin
我绝对不是专家，但据我了解，URI 中的关键词对 Google 非常重要（这可能已经改变了，我不确定）。因此，如果它前面可能包含的内容与页面本身无关，那么将页面放在根目录下可能是一个好主意。
同样，似乎最佳策略是优化内容和用户友好性，Google 将会善待你。
因此，在你的示例中，/about/kevin 比 /kevin 更好，因为使用 /kevin，并不明显它是一个关于页面。而它是关于页面这一事实是页面重要的一部分。
它也不易被黑客攻击；而使用 /about/kevin，你可以访问 /about 并期望找到所有公司简介（只是一个例子）。
现在，如果 URI 是 /pages/about/kevin 甚至 /db/content/pages/about/kevin，那么 /about/kevin 会更好，因为其他信息对页面来说确实不重要。
无论如何，这只是我的想法……
对于 SEO 来说，搜索引擎认为如果一个页面更靠近根目录，那么它就更重要，但不是指物理目录结构，而是指网站导航结构，这两者有时并不相同。让我们举个例子。
假设你的网站上有 /about/kevin 和 /staff/employee-of-the-month/richard。从首页访问 Kevin 的页面，你必须先去 /about，然后才能到 Kevin 的页面。但是你在首页上有一个指向 Richard 个人资料页面的直接链接。因此，Kevin 距离首页有 2 页（在导航中），而 Richard 只有 1 页。搜索引擎会认为 Richard 的页面比 Kevin 的页面更重要。
此外，回答你的第一个问题，/about/kevin 和 /about/richard 比 /kevin 和 /richard 更好，因为“about”这个词对搜索引擎和人类都提供了语义价值。
我仍然建议将某些项目保留在查询参数中。许多搜索引擎不喜欢重复内容，因此当它看到 ?sort=up ?sort=down …时。顶级竞争对手的许多网站管理员工具允许你删除某些查询参数，以便在你的网站索引中忽略它们。如果你将你的地址重写成类似文件夹结构的样子，你就无法做到这一点……除非你从索引中删除看起来像“/sort/up/”的“文件夹”。
是的……它是网站上相关和顶级内容的平衡，但仍然具有语义。因此，靠近根目录是好的，但是如果你有一个深层结构的网站，那么显示语义路径仍然很重要
关于 URI 设计的精彩回顾！！
太棒了！
这很棒，但如果能提供一些关于如何实现这些 URI 的“技术细节”就好了！
我知道 htaccess 可以做一些这样的事情，比如删除“.html”或“.php”和“www”。
但是如何更改像这样的 URI 呢？
domain.com/portfolio.php?id=24
变成
domain.com/portfolio/chris/
?
是的……我希望在不久的将来在我的网站上进行一些技术后续操作。
更改 portfolio?id 为干净 URI 的最佳方法可能是自定义/预构建的 CMS，所有流量都路由到确定要提供什么内容的 index.php 脚本。
你也可以使用 Apache 的 Rewrite，但你可能希望使用“id=chris”而不是“id=24”。将 /portfolio/chris 重写为 /portfolio.php?id=chris 非常简单，因为信息相同。理想情况下，你的干净和脏 URL 具有完全相同的信息，你只需使用 Rewrite 转换它们的格式。
从今天起，我也会将 URL 称为 URI。
我甚至可能会去掉 www，因为你在这方面也说得对。这是浪费时间。
竖起大拇指，感谢 Chris。
像 Django 和 Rails 这样的现代 Web 框架使得创建不良 URL 变得困难。
我是 Mango 的首席开发人员，Mango 是一个基于文件的博客系统。Mango 使创建优雅的 URL 变得简单，并支持“开箱即用”的短 URL。
人们可以撰写一篇帖子并将其保存为 4=>wordpress-conversion-script.text，这将使帖子可以通过 /wordpress-conversion-script/ 访问，而 /4/ 将自动重定向到规范 URL。
也可以在 WordPress 中设置此功能。在我们的 WordPress 网站上，博客文章使用 example.com/blog/%postid%/%posttitle%/ 的永久链接结构。
这种结构有几个不错的优点。首先，它将 postid 放在首位，这使得 WordPress 更容易确定你请求的是帖子还是页面。
其次，对于像 example.com/blog/123/some-blog-article/ 这样的 URI，我们在规范 URL 中有文章标题，但很酷的是，指向 example.com/blog/123/ 的链接也将显示正确的内容。在这种情况下，我们有一个内置的链接缩短器。
酷帖子 Jacob。我一直都在思考一个即将开展的项目中 URI 设计的事情。
我基本上已经想明白了，但我很好奇更复杂的操作。
例如，对某个类别中的项目进行编辑。
http://myawesomeblog.com/categoryname/postname/edit 或
http://myawesomeblog.com/postname/edit
也许将 edit/delete 放在项目别名前？
Flickr 仍然拥有最酷的 URI 设计方案之一。例如 http://www.flickr.com/photos/username/4846720345/in/contacts/ 用于显示来自您联系人的最近照片。
我建议转向更 RESTful 的方式来与你的 URI 进行交互。
我的意思是，你应该使用 HTTP 方法（GET、POST、PUT、DELETE）来与你的资源进行交互。
这种实践归结为以下模式
GET：从服务器检索资源
POST：在服务器上创建资源
PUT：修改/编辑/与服务器上的资源交互
DELETE：从服务器删除资源
所以，而不是
http://myawesomeblog.com/postname/edit
我建议从客户端执行以下请求
PUT http://myawesomeblog.com/postname/
{…一堆 http 标头}
{请求正文在这里}
我同意，尽管你需要一个用于实际编辑页面的 URI，对吧？所以 /postname/edit 会对 /postname/update 或其他内容执行 HTTP PUT（Rails 就是这么工作的）。
大家好，
完全同意 RESTful 部分，谢谢。
@jacob 是的，你说得对。
我会做的是将原始 URI 附加到操作上，因此是 http://myawesomeblog.com/categoryname/postname/edit。不确定这是否是最好的方法，但它似乎是最佳选择。
我不喜欢像 Drupal 这样的系统，它有 /my/clean/uri，然后是 /node/2443/edit 用于编辑页面。不过，有一个模块可以解决这个问题…… :)
Google 表示，如果你有新闻网站地图，则无需使用 3+ 数字标识符
实际上，可以通过在 .htaccess 中的 mod-rewrite-rules 中添加 [NC] 来捕获所有混合大小写的请求，然后重定向到相应的 lowercase url。
酷！我必须对我的所有项目进行更多研究。
一篇非常棒的文章。我不知道 /about 比使用 /about-company-name 更好。
此外，获取短链接也很不错。
我遇到的一个问题是拥有 /blog/category/
我更希望只有 /blog/interviews 等
我忘记提及的另一个非常重要的 /about 的原因是，现在许多用户只需访问任何域名的 /about 即可找到关于页面。它简洁明了，这一点也不错。
*没有底层技术的证据*
我的网站只是一堆静态 HTML 文件。我只是制作了一个为我生成简单网站的脚本。我应该保留 .html 还是重写它？
看看评论顶部，我问过同样的问题并得到了答案
关于URI的精彩文章！非常有帮助，我完全同意你的观点！ :)
好东西，虽然在我看来
(a) 最好规范化为“www”子域名，并从根域名重定向，而不是反过来。“www”更具体，并与其他服务/子域名（如“mail”、“calendar”、“store”等）区分开来。
(b) URI不应区分大小写，因此您不必担心将其转换为小写。我希望看到官方规范更新以反映这一点。
我将为两者争论另一种说法。
“www”会让用户感到困惑，难以表达，并且当它不存在时，假设您指的是网络。如果您说store.domain.com，那么我们就知道您不是在询问www。而且您创建的每个URL都少4个字符。www浪费的总时间是许多许多人的一生。
有些文件系统区分大小写，有些则不区分。将所有内容都转换为小写可以解决此问题，并且使URL更易于键入。如果您的URL是/Index.html，您想要“Index.html”还是“index.html”？在大多数Web服务器上，它们不是同一个文件。
这是一个很棒的主题，我认为许多创建网站的人经常忽略它。
由于您没有提到它，我想建议蒂姆·伯纳斯-李的酷URI不会改变（1998年）作为进一步阅读。
您没有明确提及，但我认为还必须记住：“没有底层技术的证据”也适用于媒体文件，而不仅仅是网页。或者你怎么认为？
我同意你的最后一条评论，“没有底层技术的证据”。这就是为什么RESTful模式是与服务器交互的绝佳方式的原因——人们只需要知道如何使用HTTP协议。然后，服务器处理客户端应该接收回什么表示形式。
我同意网页：不要在网页上包含.html、.htm、.php、.aspx…
但我不同意媒体类型或出于可用性和可访问性问题的媒体类型（如果我在您的评论中理解正确）。如果您链接到非HTML文档，则应始终在URI中包含扩展名或文件格式。我的意思是，使用“http://example.com/annual-report”在服务器上重定向到“http://example.com/annual-report.pdf”或“http://example.com/annual-report.doc”不是一个好习惯（在我看来）。
想想那些没有安装Adobe Reader或.doc文件查看器的人。如果他们看到没有扩展名的链接，他们会点击它以希望看到另一个HTML页面，但实际上他们会收到一个“下载文件”对话框，并且无法打开该文件。
如果他们在URI中看到文件扩展名（当您将鼠标悬停在链接上时显示在状态栏中），他们可以意识到这些链接指向他们无法打开的文档，并且不会点击该链接。
还要考虑在移动设备（甚至智能手机）或使用屏幕阅读器的人。
您在这里提出了一个有效的观点。如果我看到一个弹出对话框，并且我不知道文件扩展名，我将更加警惕我正在下载的内容（尽管对于PDF文档，浏览器通常会显示它们而不是强制下载）。
同意——媒体和下载的文件扩展名应位于URI中……我同意James的观点；如果我没有看到文件扩展名，我将假设（1）网站已损坏或（2）链接指向下载引导页面。
隐藏技术的另一个原因是在隐藏您在后端使用的内容方面又增加了一步，以防止恶意用户。当然，他们仍然可以很容易地弄清楚您正在使用什么，但这是他们在简单浏览之外需要采取的额外步骤，这有助于保护您免受那些真正懒惰的人的侵害。 :)
Google新闻的要求不一定比其他要求差，也不会造成任何问题。您不必完全替换您的URI
您只需在永久链接结构中添加（对于WordPress）/%post_id%/。
我们运营的新闻网站（http://rvanews.com/）通过在URI末尾添加帖子ID成功地被纳入Google新闻。
非常好的帖子，伙计！
我自己使用WordPress永久链接，结构如下
/%postname%/
这建立了简洁干净的URI
关于这种特定格式对WordPress性能是不好的选择，一直存在争议。不过，这就是我在CSS-Tricks上使用的格式，我不能说这是一个大问题。谁知道呢，我没有任何速度测试或任何东西来证明事情的任何一方。
见上文——/%postid/%postname%/是我们网站上使用的格式。
yourls.org很棒。看看吧 :P
很棒的帖子！
但是，我不同意您关于从URI中删除www并使用301将其重定向到非www页面的说法。
应该反过来。
“www”指定URI是http URI，就像“mail.”指定邮件服务器，或“ftp.”指定FTP服务器一样。
发送到foo.com的http请求应被301重定向到http://www.foo.com，因为http://www.foo.com是http的正确服务器。发送到foo.com的邮件请求也一样，被重定向到mail.foo.com。
http指定URL是HTTP URL。这就是www冗余的原因。它浪费了绝大多数人类的难以置信的时间和精力。
www是Web服务器的名称，mail是邮件服务器的名称。您可以将这些命名为任何您想要的名称。您的邮件服务器可以是fred.foo.com。您的Web服务器可以是web.foo.com。
我同意您所有的观点，除了“无WWW”这一点。对于某些网站，删除它是有意义的，因为它确实不需要，并且可以使域名看起来更好。
但是，删除“www”实际上会使许多域名看起来非常难看。我无法想象像雅虎或谷歌这样的大型网站会删除www，以免显得冗余。我同意删除子域名的www，但对于主域名，保留www看起来更好，更专业。
当然，用户不必键入它，如果您不想，您甚至不必使用WWW链接它。只需使用.htaccess强制添加它：http://dev.myunv.com/snippets/htaccess/force-www-subdomain/
丑陋在主观上更糟糕。少四个字符在客观上更好。如果您向用户显示“www.”，他们会键入它。他们不知道这是不必要的。
他们还会键入“ww.”和“wwww.”。
我认为说主机名不需要是不正确的。主机名是http需要的。不使用它们可能会导致http出现问题，如前面提到的cookie和ssl。
我的投票是保留www。您还说如果人们会按照您的指示键入。根据我的经验，我认为这也是错误的。如果我告诉某人去sub.domain.com，他们几乎总是键入http://www.sub.domain.com。测试不带www的重定向，然后重定向到www。我敢打赌（除非每个人都将您的网站添加到书签），当您删除www时，您将拥有更多重定向，而不是保留www时。
了解键入“google.com”会将您重定向到“www.google.com”并不难。我们应该停止迁就那些不知道这些基本知识的用户，这是他们现在不知道的错。
此外，对于利用通过子域名组织其内容的网站，在前面加上www具有巨大的好处，因为它可以将主页与其他所有内容区分开来。至少在我看来。
嗨，chris，
感谢您总结了这个话题。
此致，mtness。
太棒了。记住孩子们，URL是人们用来称呼你的，URI是你所在的位置！
随机——关于保持简短，我使用/i代替/images，使用/m代替/media，这与您所说的不完全一样，但它适合在那里。
很棒的文章！
类似句子的结构似乎是一个好主意！
后缀怎么样？
使用…/my-article.html更好吗？
而不是…/my-article？
用于文件类型识别和缓存？
你不需要从文件本身移除“.html”，只需要从URL中移除。你使用URL /my-article，然后使用Apache Rewrite添加“.html”，这样服务器返回的就是/my-article.html文件。之后你可能想把这个文件的扩展名改为“.shtml”或“.php”，但URL会保持不变。
非常棒的文章，Chris。
我想在“无WWW”的说明中补充一点。
曾经有一段时间，我坚决反对在域名中包含www，理由和你文章中提到的相同，但随着我开始处理更大的网站，我无法忽视包含www在域名中带来的域名cookie优势。
省略域名中的www的问题在于，你设置的任何cookie都会在来自任何子域名的请求中返回给你。因此，如果你使用static.domain.com提供静态内容，并且为domain.com设置了cookie，那么static.domain.com将不再是无cookie的域名。
或者，为http://www.domain.com设置cookie可以确保你的cookie仅返回给该域名，而static.domain.com将保持无cookie状态。
也就是说，大多数人不需要提供足够多的内容来使用CDN或将此视为问题，在这种情况下我完全同意你的观点。它看起来很丑陋，而且降低了可读性。不幸的是，这是一个技术决定用户体验某个方面的情况：如果可以避免，就不要向后端部门承认这一点；)
由于某些Web服务器处理上下文URL和文件/目录的方式，包含尾部斜杠也是一个好习惯。
这里有很多好的建议，但我感觉很多都是作者的个人观点，却被包装成事实。我对语义化的URL有很强的个人看法，我从未考虑过从静态HTML文件中移除扩展名。事实上，我不认为我曾经听说过有人这样做（因为任何熟悉mod_rewrite并能做到这一点的人可能不会创建很多静态HTML网站）。
如果你使用的是CMS，那么这样做是有道理的，但仅仅为了武断地从URL中移除扩展名而做这么多工作，似乎回报太少了。你暗示.aspx是某种程度上最糟糕的扩展名，这表明至少其中一部分只是你个人的偏见。
关于WWW的部分也让人感觉有点可疑。如果你在任何现代浏览器中输入amazon.com，它会将其转换为http://www.amazon.com并首先尝试该地址。因此，这样做对任何人的唯一好处是，如果他们在浏览器中输入了完整的“http://amazon.com”，但谁会这样做呢？
我并不是说这些都是不好的做法，但它被呈现为“如果你不这样做，你就做错了”，我不确定这是否属实。
> 这里有很多好的建议，但我
> 感觉很多都是作者的
> 个人观点，却被包装成事实。
这就是Web开发。如果你不喜欢这里提出的想法，就不要使用它们。大多数Web开发都是教条，而不是事实。它是传统和最佳实践，不断适应不断变化的Web。如今用户使用URL的方式与10年前不同，用户本身也发生了变化。
>但仅仅为了
>武断地从URL中移除扩展名而做这么多工作，
>似乎回报太少了。
这并不需要很多工作，而且你得到的回报是巨大的。如果你认为回报很小，说明你没有理解它。
URL的重点是不变。否则，我们可以直接提供IP地址。如果你在URL中放置“.php”或“.aspx”，那么你要么承诺永远使用PHP或ASP，要么承诺URL将来会在某个时刻发生变化，从而导致灾难。
想象一下，你买了一部诺基亚手机，你的电话号码是nokia.555.1212。你把它告诉了所有朋友。它变成了“打电话给Grover”的同义词。它存在于各种目录和联系人列表中。然后几年后，你想换一部摩托罗拉手机，但你不能再使用“nokia”，你的号码必须更改为“motorola.555.1212”，现在你所有的历史都被清除了。没有人可以打给你。更好的方法是只使用“555.1212”，通过一个不关心你使用什么手机的系统进行路由。从你的URL中移除“.aspx”也是同样的道理。
目前，Web已经足够老了，我们知道我们会一次又一次地更换技术。即使你坚持使用ASP，也可能会出现使用“.aspx2”的新版本，你可能希望使用它，而你所有的URL都会失效。
你所有的分析数据都与你的URL相关联，包括所有用户的书签以及所有链接到你的网站。
重写URL并不困难。Apache服务器指令中有一个名为Rewrite的命令。
而且，你让所有用户更容易使用你的URL，他们在Twitter和其他社交网络中就是这样做的。
对于正在运行的网站，你可能不想这样做，但在新网站上你绝对应该这样做。此外，客户喜欢干净的URL（尤其是如果他们经历了重设计导致所有链接和分析数据失效），如果你为他们构建一个具有像domain.com/name/of/article这样的链接的网站，他们自己可以解码和输入，他们会对你这个Web开发人员有更高的评价。
我不相信你关于省略扩展名的论点（尽管我个人会为了整洁而这样做）。如果我要构建一个使用.aspx扩展名的网站，然后切换到使用PHP，这根本没有任何区别。你可以使用任何扩展名，并进行相应的重写。运行在PHP上的网站可以轻松配置为显示.aspx扩展名，就像可以配置为不显示任何扩展名一样。
尽管如此，正如我所说，我无论如何都会选择干净的URI。只是不是因为那个原因。:)
抱歉重复发帖，但我本来想补充一点，我确实遇到过新手用户不接受没有WWW的地址的情况。http://amazon.com在我遇到的许多新手用户看来是错误的。
对良好实践的出色总结，我添加了书签并将其添加到每周提示和技巧的汇总中。
我唯一不同意的是“www”的问题，我认为@greg johnson已经很好地解决了这个问题。
Jacob，这篇文章写得很好。这里讨论了一些重要的细节，谢谢。
然而，我必须说，我强烈不同意你对人们如何彼此分享URI的一些假设。例如，你说
以及稍后
一般来说，人们不会尝试亲自“描述”URI，除非是像“关于我们”这样的基本页面。大多数URI（即使是符合你的URI设计标准的简洁URI）也几乎不可能在现实生活中表达，而且几乎不可能记住。这并不是人们相互传递“链接”的方式。在大多数情况下，人们会做以下三种事情之一。
1）他们会说“我发短信/邮件给你链接”；
2）他们会说“去首页（或谷歌）搜索[内容]”；或者
3）他们会说“去首页，点击[内容]”
唯一可能改变这种情况的是一些非常简单的页面，例如“关于我们”或“联系我们”页面，但这些页面在大多数网站上都很容易找到。
无论如何，感谢你在这里提供的信息。不管我上面所说的意见如何，我认为你在这篇文章中做得很好，并且提出了一些非常重要的问题供大家考虑。
我必须同意这一点。就我个人而言，我会说Louis的第1或第3种方法。主要是因为即使是我自己也记不住URI，或者我只是根本没有注意我在网站中的位置。我只是说去whatever.com，然后点击关于我们，你就能找到那个人。
没有人会记住那种东西以外的任何东西。
此外，URL可能不再是正确的术语，但试着让一个普通网页用户客户说出他们的URI。你会得到一个茫然的表情。开发人员可能知道，但普通用户不知道。因此，为了对抗你们所有人，我将继续使用URL！
URL万岁！
我自己在谈话中通常也说URL，仅仅是因为我最初学的就是这个词。是的，我妈妈看了这篇文章后说，“什么是URI？”，我解释说它基本上与URL相同，她理解了。
也许是我们导致公众不知道URI这个术语……我不知道。所以，我将从现在开始尝试使用它，希望能教育周围的人了解他们每天都在使用的工具。
但是，当我不用心思考的时候，我可能仍然会脱口而出URL。:)
我同意你的观点……我很少在谈话中告诉别人完整的URI。我主要是在想，你应该努力使它成为可能，而不是真的去做。更像是对简洁URI的快速测试。从理论上讲，我可以告诉别人去css-tricks.com/guidelines-for-uri-design，但我绝对不能告诉别人去http://www.amazon.com/Designing-Social-Interfaces-Principles-Experience/dp/0596154925/ref=sr_1_1?ie=UTF8&s=books&qid=1280927599&sr=8-1（顺便说一句，这是一本好书）。
我通常通过电子邮件分享链接，或者有时会把链接写在纸上（我想这是老方法）。在纸质情况下，只有设计良好的 URI 才能正常工作。
感谢您的反馈！抱歉我在文章中没有表达清楚。
哦，我觉得表达得很清楚，你做得很好。我只是不认为 URI 可读性对这一点很重要，因为人们根本不做这样的事。
再次感谢这篇文章。
不用 WordPress 吗？
怎么做？
对于那些有兴趣创建自己的短链接的人，请参阅我的教程
http://sean-o.com/short-URL
对我来说，Flickr 是一个很好的 URI 设计来源。
他们为单张图片采用了这样的模式
http://www.flickr.com/photos/%5Buser-name%5D/%5Bpicture-id%5D
而不是
http://www.flickr.com/photos/%5Buser-name%5D/%5Bpicture-TITLE%5D
优点是，用户可以更改标题而不会丢失 URI。
虽然生成的 URI 可能不如博客样式（URI 最后部分的关键词）那么漂亮，但它们符合保持 URI 永久性的原则。
想象一下，有人因为其帖子的标题而陷入法律纠纷。被迫更改标题也会弄乱 URI。
您对此有何看法？
Stefan
我一直认为 Flickr 在这方面做得很好。我认为它看起来仍然不错。当然，不如你说的那样漂亮。但你可以更改标题而不会影响 URI。
但是对于博客，你可以争辩说，嘿，我可能会更改它所在的类别或标签。因此，我还会建议不要将它们用作永久链接。我总是坚持发布日期结构，因为这不会改变。
最终的 ID 总是让我感到困惑。标题是为了可读性，还是数字 ID 为了允许灵活地不必进行重定向。
我同意那些说保留 www 部分的人。cookie 的观点很好，但即使没有它，许多人也会发现 URI 上缺少 www 会令人困惑。这些人往往是使用网络时间较长，但不太频繁且体验不佳的人。
但是，无论您如何操作，它都必须比那些拒绝识别域（如果您不输入 www）的该死的网站更好。现在仍然有相当数量的此类网站。
我同意你的大部分文章。我陷入困境的地方，而且我惊讶的是还没有人提到过，就是你对短链接的使用。它们违背了你文章中建议的所有内容。
如果短链接是用户阅读最多的内容，我认为这种情况越来越普遍，因为社交网络，那么用户很少能从你在规范 URI 上所做的努力中受益。
我不认为大多数用户在地址栏中实际阅读 URI，更不用说修改它们了。我相信，像 Twitter 和 Facebook 这样的服务是用户实际阅读 URI 最多的地方。短链接在大多数情况下是不可读的。
短链接除了节省字符数之外没有其他用途。它们在紧迫的情况下是必要的，但“在共享 URI 时鼓励使用短链接”似乎与你文章的要点背道而驰。
你能更详细地解释一下你建议背后的理由吗？
很棒的文章，为好的内容和好的 SEO 设计，将随之而来，优秀的理论，需要对此进行更多撰写。SEO 应该是精心设计的网站的结果，而不是一个单独的目标。
.aspx 很烦人？相较于 .html、.htm 或 .php 或 .jsp？为什么四个字母的 .NET 页面扩展名比其他服务器端页面扩展名更烦人？能否向所有 .NET 开发人员解释一下？
Chris
只是我个人使用 .NET 网站的经验……并非针对 .NET 开发人员。我访问过的多数 .NET 驱动的网站的 URI 类似于 http://msdn.microsoft.com/en-us/library/015103yb.aspx 或至少重定向到 Default.aspx。（不过，微软多年来在 URI 方面有所改进）
我个人不喜欢“着色”产品的技术……也就是说，你不应该查看网站并说“这是用 ASP 构建的”或“我可以看出这是一个 X 网站”。因此，你应该完全控制网站的 HTML、JS、CSS 和 URI。
我个人没有使用过太多 ASP.NET，它可能有重写 URI 的简单方法……我知道它是一种非常强大的语言。
所以，并非针对 .NET 开发人员…… .jsp 通常也很糟糕（URI 中的会话 ID 等），你是对的，.aspx 比 .1234 并没有更糟糕，只是根据我见过的网站，.aspx 通常伴随着其他不干净的元素。
如果我的评论听起来像是对 .NET 开发人员的攻击，我表示歉意。
它们看起来不像攻击。我不确定我能否说更多的 .net 网站包含 .aspx 比 php 包含 .php 或任何其他内容多。
即使你可以相当简单地克服整个后缀问题，但这在社区中也没有得到真正的讨论。用 .net 编写的 CMS 系统几乎都解决了这个问题，但对于那些使用入门网站的人来说，他们从未对此产生怀疑。
从那时起（亡羊补牢，为时不晚），微软为我们提供了 System.Web.Routing，它内置于系统中，并且使事情变得超级简单（尤其是在 MVC 中）。无论如何，它在 .net 3/3.5 中可用。但它包含在 .net 4 中。
无论如何，微软似乎正在做很多工作来确保人们知道路由命名空间在那里，我相信他们已使其所有入门网站和项目模板在 4.0 中默认使用它，因此希望人们会看到它并开始使用它。
您好，Jacob，
感谢您的回复（顺便说一句，感谢这篇有益的文章，我忘记提了）。
您说得对，在 .NET 的早期，URL 书写非常糟糕。他们最终确实通过更新的重写模块(http://learn.iis.net/page.aspx/460/using-the-url-rewrite-module/) 解决了这个问题，这是一件好事。我认为问题更多在于 IIS 6，而 IIS7 似乎在很大程度上解决了这个问题。
我绝对同意您希望从 URI 中消除服务器端处理。对我们来说，这是一个更大的挑战，因为大多数博客软件（如 WordPress 等）都针对 Linux/PHP 环境进行了更好的优化。希望 .NET 能更多地关注能够轻松重新路由 URI 以及我越来越多地看到的一些其他酷炫功能（以及你的文章提到的功能）。
再次感谢，
Chris
我会尝试一下。ASPX 对我来说很烦人，因为它提醒我我即将查看的网站可能充满了无效且低效的代码。
现在，别误会我的意思。我认为 ASP.NET 是一个构建具有基于 Web 的界面的真实应用程序的绝佳平台，但是我见过的许多基于 ASP.NET 构建的网站和 CMS 系统都很糟糕。
我是在担任 3.5 年高级顾问，管理用 ASP.NET 编写的基于 Web 的大型软件项目后这样说的。
我知道 ASP.NET 可以输出干净的代码，但根据我的经验，在现实世界中找到一个实际的例子非常罕见。
我总是能够让 asp.net 输出非常干净的代码（尤其是在你可以更改 .net 的几乎所有内容之后）。我的问题一直是 webform 和 viewstate。我理解我的 MS 做了 webform（为了让 winform 开发人员更容易），但它真的很乱。同样，使用你自己的处理程序，你可以摆脱 winform（我有时会这样做），但现在我们有了 MVC，它可能还没有达到 rails 的水平。但对我来说，它很接近，而且非常好。
您好，Kurt，
确实如此：基于 ASP.NET 构建的 CMS 系统可能非常有限，并且难以完成简单的任务。似乎 .NET 的 CMS 平台数量不足，而且没有足够的差异/选择。
就像 John 所说，在 .NET 中绝对可以输出干净的代码，而那些没有简单地添加一行代码的开发人员则更多是不知情或懒惰的
到他们的 web.config 文件中（类似于 apache 用户的 .htaccess 文件）。他们还可以做其他事情，但这确实有助于输出更干净的代码。
是的，viewstate 对大多数应用程序来说有点糟糕，但可以关闭。
MVC 似乎是未来，但我可能会切换到 Rails 而不是尝试学习它。
Chris
我发现 MVC 非常容易上手。我也看过 rails。我真的很喜欢它，但 ruby 是我主要的问题。对我来说，学习 .net MVC 比 rails 更简单，仅仅是因为我的 rails 技能最多只能说是基本不存在。
无论如何，我认为它们都很好。我听说过有人说，从性能方面来说，Rails 有时可能会失控。从商业角度来看，我喜欢 .Net 是编译的。
不过，Ruby 社区似乎比 .Net 社区更友好。我的意思是更有帮助。当你问问题时，.Net 的人似乎喜欢试图打断你。
不要使用 WordPress，如何操作？
这显然跑题了，但你是如何在 Chrome 上获得无边框按钮的！？
也许你应该在这个页面上搜索“chrome”，你就会找到答案。
Taggart
网站针对许多帮助进行了优化。适当的研究。
这显然跑题了，但你是如何在 Chrome 上获得无边框按钮的！
感谢您非常有帮助和友好的指导，我已经发布了俄语翻译（http://legco.net/entry-382.php），如果您不介意的话。