什么是URI(URL)
定义
URI: Uniform Resource Locators
URL:Uniform Resource Identicators
URI分两部分，scheme, scheme-specific，这两部分由冒号分割开。schema包括HTTP,FTP,NEWS,GOPHER等，详情参见RFC1738（ftp://ds.internic.net/rfc/rfc1738.txt）
语法
HTTP,FTP的语法很相像，都是这样:
schema://user:password@host:port/directory/file.extension
编码
URI中理论上只允许ASCII字符。
部分特殊符号必须编码，不能直接出现在URI中，如“~”
Web项目中，这些都是URI：
链接地址（a标签的href属性）
图片的源（img标签的src属性）
多媒体文件的源（object标签的src属性）
CSS，JavaScript地址（link标签的href 属性，script标签的src属性）
为什么要设计好的URI
重要的入口
便于传播
便于用户挖掘内容
URI的常见问题
难以输入
URI不必要的冗长
比如：
http://www.bigcompany.com/PR/announcements/1994/dec/new-server-version.txt
这个还算好的，看看这个：http://www.globeandmail.com/servlet/ArticleNews/PEstory/TGAM/20020909/RVCRR/Business/business/business_temp/2/2/5/
莫明其妙的大写字母
比如：
ftp://ftp.bigstate.edu/pub/docs/OnTBGHill.txt
不常见的标点符号
ftp://ftp.bigstate.edu/pub/docs/moon_3+manual
在纸介质上显示很困难
一些字符在纸上打印出来不容易辨认，例如
“～”（数字键1旁边那个键）在不同的字体下面显示不同，有时候在一行的顶部，有时候在底部。
“l”（字母L的小写版本）和“1”（数字一）几乎无法分辨——在纸介质上的时候，同样的还有“O”和“0”。
“`”太微小，以致于人们在某些情况下看不到它。
主机和端口的问题
除了 scheme-specific 部分，domain和port也可能给用户带来困惑。
http://admin.bigstate.edu:8001/docs/thesis/jones
设计URI应该遵循的原则
URI是网站UI的一部分，因此，可用的网站应该满足这些URL要求
-
简单，好记的域名
-
简短（short）的URI
-
容易录入的URI
-
URI能反应站点的结构
-
URI是可以被用户猜测和hack的（也鼓励用户如此）
-
永久链接，Cool URI don't change
聪明的选择URI
一定要短
为了URI能被方便的录入，写下，拼写和记忆，URI要尽可能的短，根据w3c提供的参考数据，一个URI的长度最好不要超过80个字节（这并非一个技术限制，经验和统计提供的数据），包括schema和host,port等。
大小写策略
URI的大小写策略要适当，要么全部小写，要么首字母大写，应避免混乱的大小写组合，在Unix世界，文件路径队大小写是敏感的，而在Windows世界，则不对大小写敏感，所以，http://www.example.com/FOO和http://www.example.com/foo是两个不同的URI（尽管他们在Windows平台有相同的含义）
允许URI管理
URI映射
管理员可以重新组织服务器上的文件系统结构，而无需改动URI，这就需要URI和真实的服务器文件系统结构之间有一个映射机制，而不是生硬的对应。
这种映射机制可以通过如下技术手段实现：
Aliases，别名，Apache上的目录别名，IIS上的虚拟目录
Symbolic links，符号链接，Unix世界的符号链接
Table or database of mappings，数据库映射，URI和文件系统结构的对应关系存储在数据库中
标准的重定向
管理员可以简单的通过修改HTTP状态代码来实现服务器文件系统结构变更之后的URI兼容，可以利用的HTTP Status Code有：
301 Moved Permanently ([RFC2616] section 10.3.2)
302 Found (undefined redirect scheme, [RFC2616] Section 10.3.3)
Temporary Redirect ([RFC2616] Section 10.3.8)
用独立的URI
技术无关的URI
-
提供动态内容服务时，应使用技术无关的URI
即URI不暴露服务器端使用的脚本语言，平台引擎，而这些语言，平台，引擎的变化也不会导致URI的变更。因此，sevelet,cgi-bin之类的单词不应该出现在URI中。
-
提供静态内容服务时，应当隐去文件的扩展名
取而代之的技术是content-negotiation, proxy, 和URI mapping
身份标志和Session机制
-
使用标准的身份认证机制，而不是每个用户一个特定的URI
-
使用标准的Session机制，而不是把Session ID放在URI中
使用Tomcat和PHP3的站点容易犯这类错误，将Session ID放在URI中，实际上，他们应当用HTTP Header来实现之。
内容变更时使用标准转向
对变更的内容使用标准的重定向
对删除的资源使用HTTP410
提供索引代理
索引策略
Content-Location
Content-MD5
提供适当的缓存信息
缓存相关的HTTP头
缓存策略
缓存生成内容
HTTP HEAD和HTTP GET
总结
本文详细描述了URI的定义和作用，揭示了目前Web开发中普遍存在的问题，并给出了URI设计原则和规范，希望本文的读者能在开发和设计Web应用程序的时候体会和运用这些知识。
-
URI是Web UI的一部分，应当像对待网站Logo和公司品牌一样对待它
-
URI是网站和普通用户之间的唯一接口，应当像对待你的商务电话号码一样对待它
读懂并记住上面两句话，你下次设计URI的时候就会给它应有的重视了。
-
URL应当是用户友好的
-
URI应当是可读的
-
URI应当是可预测的
-
URI应当是统一的
==========================================================================================
网站设计中经常容易被大家忽视的一个因素就是URL的设计。虽然现在的内容管理系统都允许各种不同程度的URL自定义，但默认的URL地址往往并不是就适合你的网站，在网站设计的最后一步通常要考虑对默认的URL进行替换。简洁的URL是网站非常重要的一个组成部分。所以，这篇文章将谈谈URL设计的一些指导原则以及执行这些原则时的技术细节。
原则
URL的唯一性和永久性
URL背后最基本的理念就是一个URL代表互联网上的一个数据对象。保证URL的唯一性是非常重要的，这样才能保证一个URL与一个数据对象匹配。虽然这是我们的目标，但是有时候却也不是那么容易实现的，很多站长由于考虑不周全就会出现“重复”问题。使用 Canonical URL标签可以减少重复内容被搜索引擎发现，因而可以提升网站在搜索结果中的表现。像谷歌这样的大型搜索引擎比较关注“重复问题”，因此强烈建议使用 canonical URL来轻松解决这个问题。
URL还必需具有永久性。这主要是说在网站发布之前计划URL的时就必需选一个比较好的URL设计。否则可能以后就可能会需要修改URL结构来改进。如果真的有必要这么做时，请确保在服务器上设置了 HTTP 301永久迁移重定向。这样服务器才会告知浏览器和搜索引擎内容的新位置，同时才能保住旧的URL地址所积累的PR值。
尽可能对用户友好
这点是URL设计时需要考虑的最根本因素。URL设计时首先必需考虑最终用户。搜索引擎优化（SEO ）和是否易于开发应该放在第二位。
而保持URL对用户友好的一种方式就是要使其言简意赅。这意味着说要使用尽可能少的字符同时又能保证可用性。也就是说 /about 就比 /about-acme-corp-page来得好。但是在争取简洁的同时，不能牺牲用户的友好性， 像 /13d2 这样的URL地址对终端用户来说一点意义都没有。
相反的，在一些分享URL的场合下，却鼓励大家使用短链接。这对微薄还有其他共享的社交网站来说比较方便。关于URL短网址服务，可以使用Bit.ly，也可以使用PrettyLink Pro (WordPress插件)或Short URL插件。
对内容或用户来说不重要的信息就不必在URL中出现。比较常见的反面例子就是使用数据库ID作为URL的一部分，如 /products/23。最终用户并不会关心该产品在数据库中的记录号是多少， 因此，/products/ballpoint-pen这样的URL相对而言对用户更加友好。
测试URL是否对用户友好的一种方法就是看它是否 “语音友好” ，也就是说你对一个朋友念一个地址的话，你的朋友能否听懂你在说什么。
一致性
一个站点的所有URL必需在格式上保持一致。一旦选定一种URL结构之后，那么就一直遵照这种格式保持下去。整个网站中只有部分URL结构比较良好的话，说明网站整体而言，URL结构还是糟糕的。为了让用户能够明白你的URL地址是以某种格式运行的，那么整个网站的URL格式就必需要统一。如果你一定要改变结构（可能更新一个之前URL设计欠佳的网站），那么记得使用前面讲到的301重定向。
易处理性
与一致性相关，URL结构应清晰明了易更改。例如，如果 /events/2010/01显示的是2010年1月份的事件，那么
- /events/2009/01 应该显示2009年1月份的事件
- /events/2010 应该显示2010年整年的事件
- /events/2010/01/21应该显示2010年1月21日的事件
关键词
URI应该由该页面内容的重要关键词组成。因此，如果一篇博客文章的标题非常长，那么只有那些对内容来说非常重要的关键词才应该出现在URL中。例如，如果博客文章的标题是 “My Trip to Best Buy for Memory Cards,” ，那么URL中那些不重要的虚词就没必要写进去了， /posts/2010/07/02/trip-best-buy-memory-cards就足够了。在URL中使用重要的关键词的一个好处就是可以提高SEO效果。
技术细节
不要显示使用的技术语言
URL地址里不应该出现.html, .htm, .aspx或其他任何相关的语言标识。最终用户不会关心你的网站是用ASP.NET (.aspx), ColdFusion (.cfm), 还是使用服务器端嵌入(.shtml) 制作的，至少大部分用户都不会关心这一点。增加这些信息只会增加书写错误的可能性。
不过，唯一例外的就是请求返回特定格式时，URL上需加上.atom, .rss, 或 .json之类的后缀。
不要加“WWW”
网站URL应该丢弃www，因为它不是必需的，与尽可能对用户友好以及不加入不必要的信息这两条原则都是相悖的。
不过，由于现在仍然有很多用户会输入www. 前缀，因此， www.domain.com 应该用301重定向到 domain.com。同样地，子域名也需要执行301重定向，将 www.subdomain.domain.com重定向到 subdomain.domain.com.。
格式
URI应该以下面的格式出现:
domain.com/[关键信息]/[名称]/?[修饰符]
关键信息是指非对象识别的信息(如博文标题)，但对对象访问来说仍然非常关键，它可能包括：
- 对象的类型(如，博文)
- 大的父类别 (如，科技)
- 关键数据 (如，发布日期)
修饰符是修饰浏览情况而非数据数据模型，因此它们是查询字符串的组成部分并不是URL本身。
关键信息应该保持在最低的限度，URL不应该过分嵌套。在关键信息部分的任何一个字词都必需对寻找该页面具有非常关键的作用。
最后，URL应该呈现一个降级的次序，例如：
- 域名
- 类型
- 分类
- 标题
例子: http://domain.com/posts/servers/nginx-ubuntu-10.04。碰到日期相关的条目，也应该遵守降级的格式：
- 年
- 月
- 日
例子: http://domain.com/news/tech/2007/11/05/google-announces-android.
如果你希望网站内容能够被收录到谷歌新闻里，URL需符合这些需求 。其中第三条说你的URL至少要包含一个三位以上的唯一数字。两位（或以下）的数字http://www.google.com/news/article23.html 就无法被抓取，而且它们会无视看起来像年份的数字，因此最好选择五位数。
全部小写
所有字符都必需小写，URL中大小写混杂是非常不可取的。如果用户输入的URL是大小写混杂的情况下，应该用301重定向到小写的页面。实施起来就是将所有的请求都重定向到某个文件，这个文件的脚步将301重定向到小写状态。
URL识别符必需对URL友好
URL可能包含了文章的标题，而标题可能包含了对URL不友好的字符。因此文章的标题应该尽量对URL友好，例如：
- 所有的大写字母改成小写字母
- 字符 é应该转换成e (等)
- 空格用连字符代替
- 不常见的字符(!, @, #, $, %, ^, &, *, etc.) 应该用连字符代替
- 双连字符应该用一个连字符来代替
URL 设计是 Web 设计中常被忽视的东西，事实上 URL 非常重要，这不仅是一个网页唯一的路径，还涉及到你的站点是否干净，友好。本文讲述 URL 这个司空见惯的 Web 元素中包含的大量不应为忽视的知识，准则与最佳实践。需要注意的是 W3C 建议使用 URI 取代 URL 一说 。
关于 URL 的一些准则
首先是与 URL 有关的一些准则。
一个 URL 必须唯一地，永久地代表一个在线对象
URL 的最基本的使命是唯一地代表 Internet 上的一个对象，URL 必须和 Internet 上的对象一对一匹配。然而现实中，这很难实现，我们经常可以通过多个 URL 到达同一个页面，比如， http://mysite.com/product/tv 和 http://mysite.com/product?name=tv，这种情形在现代 CMS 中更是比比皆是，针对这个问题，SEO moz 有一篇很好的文章，讲到了如何使用 Canonical URL 机制解决站点中的重复 URL 问题 。
URL 应该是永久的，这就要求你在站点上线前就非常严谨地规划 URL。如果有一天，你不得不更改 URL，一定使用 HTTP 301 机制，告诉浏览器和搜索引擎，你的那个 URL 所代表的对象，已经搬迁到新地址，这个机制可以保证你旧地址所获得 PR 不会被清零。
尽可能用户友好
这是 URL 设计的根本，你的 URL 应该为最终用户而设计。保持 URL 友好的一个好办法是在保证可读性的同时让它尽可能短。比如 /about 就好过 /about-acme-corp-page，当然，保持简短不能牺牲可读性， /13d2 一类的地址短则短矣，但并不友好。如果要在 Twitter， Facebook 一类的社会媒体网络分享你的 URL，可以使用 Bit.ly 一类的网址缩短工具，但这种工具产生的缩短 URL 并不友好，在 Wordpress 一类的 CMS 中，可以使用 PrettyLink Pro 或 Short URL plugin 一类的可控制的地址缩短插件。
URL 的设计切忌使用一些对用户来说没有意义的内容，比如数据库的 ID 号， /products/23 这样的 URL 地址对用户是极不友好的，应当使用 /products/ballpoint-pen 一类的地址。
保持一致性
站点内的所有 URL 必须保持一致的格式和结构，这样可以为用户带来信任感，如果你必须更改 URL 格式和结构，需要使用 HTTP 301 机制。
可预测的 URL
这也是 URL 一致性的一个表现，如果你的 URL 拥有很好的一致性，用户可以根据 URL 猜测别的内容的 URL，假如 /events/2010/01 指向 2010 年 1 月份的日程内容，那
- /events/2009/01 应当指向 2009 年 1 月的日程。
- /events/2010 应当指向 2010 年全年的日程。
- /events/2010/01/21 应当指向2010年1月21日的日程。
URL中的关键词
URL 中应该包含本页重点内容的关键词，比如 /posts/2010/07/02/trip-best-buy-memory-cards 一类的 URL 本身就是对页面内容的反应。在 URL 包含重点内容关键词，也可以提高 SEO 性能。SEO 的一个很重要的原则就是，在 URL 地址中包含内容关键词。
关于 URL 的技术细节
下面说的是有关 URL 的一些技术细节。
URL 不应包含 .html, aspx, cfm 一类的后缀
这类信息对最终用户是没有意义的，却占了额外的空间，一个例外是 .atom, .rss, .json 一类的特殊地址，这类地址是有特别的意义的。译者注：在某些虚拟主机式 Web 服务器，这种做法未必现实。
URL 不应包含 WWW 部分
WWW 部分并不包含任何意义，是一个额外的负担，不友好。可以使用 HTTP 301 机制，将 www.domain.com 定向到 domain.com 。
URL 的格式
URL 的格式如下:
domain.com/[key information]/[name]/?[modifiers]
Key information 部分一般代表信息的类型或类别。Modifiers 部分则属于查询字符串范畴，它不应当代表数据结构，应当代表数据的修饰。Key information 部分应当尽可能简短，同时应当表现出一种层级关系，比如 http://domain.com/posts/servers/nginx-ubuntu-10.04，或 http://domain.com/news/tech/2007/11/05/google-announces-android。
Google News 对新闻源有一个有趣的要求 ，Google 要求新闻源页面的 URL 中必须包含至少 3 位唯一的数字，因为他们会忽略年份数字，因此，应该使用一个5位或5位以上的数字。另外，也应该提供 Google News 站点地图 。如果你想向 Google 提供新闻，必须按这样的结构提供 URL，当然保持一致性，可以预测性也是必需的。
使用小写字符
URL 中所有字符都应使用小写，这更容易阅读。
URL 中包含的行为元素
URL 查询字符串中可能包含一些表示行为的元素，比如 show, delete, edit 等。非破坏性的行为可以体现在 URL 中，破坏性的行为应该使用 POST 。
使用 URL 友好字符
在 URL 中体现网页标题的时候，往往会用到一些特殊字符，应当把它们转换为 URL 友好字符：
- 全部大写字符换成小写
- 诸如 é 一类的字符应转换成对应的 e
- 空格使用短划线代替
- 诸如 !, @, #, $, %, ^, &, * 一类的字符应该使用短划线代替
- 双短划线应该使用单短划线代替
另外，没有必要的话，避免使用 %20 一类的 URL 逃逸符。
更多观点
Chris Shiflett 建议，可以使用一些类似句子的 URL，如：
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
译者补充：URL 的长度上限
URL 的最大长度是多少？W3C 的 HTTP 协议 并没有限定，然而，在实际应用中，经过试验，不同浏览器和 Web 服务器有不同的约定：
- IE 的 URL 长度上限是 2083 字节，其中纯路径部分不能超过 2048 字节。
- Firefox 浏览器的地址栏中超过 65536 字符后就不再显示。
- Safari 浏览器一致测试到 80000 字符还工作得好好的。
- Opera 浏览器测试到 190000 字符的时候，还正常工作。
Web 服务器：
- Apache Web 服务器在接收到大约 4000 字符长的 URL 时候产生 413 Entity Too Large" 错误。
- IIS 默认接收的最大 URL 是 16384 字符。
=========================================================
URL中不能包含中文或“.”等非英文字符的解决方法
.Net工程命名规则形如“company.project.web”的格式。而最近当我安装微软URLScan防注入工具后，竟然导致IIS中所有网站都无法访问。起初怀疑IIS坏了，卸载IIS重装后问题依旧，后来建了个测试站点，发现凡是URL中包含“.”或非英文的路径均拒绝访问，会跳转至404错误。Google搜索问题发现是URLScan导致的，找到了原因就可对症下药。
参考官方URLScan配置说明http://support.microsoft.com/kb/326444/zh-cn。
打开“C:\WINDOWS\system32\inetsrv\urlscan”，找到UrlScan.ini文件，修改其中两个配置节。
AllowHighBitCharacters=1
AllowDotInPath=1
重启IIS生效，问题解决。
英文url中的中划线dash和下划线underscore的区别
谷歌官方对于使用连字符还是下划线问题的建议是：我们建议您在网址中使用连字符（-）而尽量避免使用下划线 （_）。
举个例子，如果你有一个像word1_word2网址，而用户搜索word1_word2（虽然几乎不会用这样的方式来搜索），谷歌将只返回该网页。如果你有一个像word1 - word2网址，该网页可以返回的搜索结果为word1，word2，甚至“word1 word2”。
上面的话实际告诉我们，word1_word2 这种形式中，实际上下划线符号起到前后连接的作用，即把word1_word2整个连成整体（这是1个单词而非词组，实际上这种关键词组是不存在的，因为搜索的时候没人会故意去加下划线），并没有正常词组中的分隔空格的意思，否则就和许多计算机常规应用法则相冲突了。
GoogleGuy 也曾暗示过连字符（-）是最佳选择。后来GoogleGuy最终站出来对于其中的原因作了解释：“如果你使用下划线‘_’，Google就会把这两个字联起来看待。所以，yoursite.com/keyword1_keyword2.html 不会看作是keyword1与keyword2两个关键字。你必须输入keyword1_keyword2才能得到相应的搜索结果”。
