什么是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才能得到相應的搜索結果”。