1.7 URI 和 URL
1.7 URI 和 URL
與URI（統一資源識別符號）相比，我們更熟悉URL（Uniform Resource Locator，統一資源定位符）。URL 正是使用 Web 瀏覽器等訪問 Web 頁面時需要輸入的網頁結構。比如，http://hackr.jp/ 就是URL
1.7.1 統一資源識別符號
URI 是 Uniform Resource Identifier 的縮寫。RFC2396 分別對這 3 個單詞進行了如下定義。
Uniform
規定統一的格式可方便處理多種不同型別的資源，而不用根據上下文環境來識別資源指定的訪問方式。另外，加入新增的協議方案（如 http: 或 ftp:
Resource
資源的定義是“可標識的任何東西”。除了文件檔案、影象或服務（例如當天的天氣預報）等能夠區別於其他型別的，全都可作為資源。另外，資源不僅可以是單一的，也可以是多數的集合體。
Identifier
表示可標識的物件。也稱為識別符號。
綜上所述，URI 就是某個協議方案表示的資源的定位識別符號。協議方案是指訪問資源所使用的協議型別名稱。
採用 HTTP 協議時，協議方案就是 http。除此之外，還有 ftp、mailto、telnet、file等。標準的 URI 協議方案有 30 種左右，由隸屬於國際網際網路資源管理的非盈利社團 ICANN（Internet Corporation for Assigned Names and Numbers，網際網路名稱與數字地址分配機構）的 IANA （Internet Assigned Numbers Authority，網際網路號碼分配局）
- IANA - Uniform Resource Identifier （URI）SCHEMES（統一資源識別符號方案）
http://www.iana.org/assignments/uri-schemes
URI 用字串標識某一網際網路資源，而 URL 標識資源的地點（網際網路上的位置）。可見 URL 是 URI 的子集。
“RFC3986：統一資源識別符號（URI）通用語法”中列舉了幾種 URI 例子，如下所示。
ftp://ftp.is.co.za/rfc/rfc1808.txt http://www.ietf.org/rfc/rfc2396.txt ldap://[2001:db8::7]/c=GB?objectClass?one mailto:[email protected] news:comp.infosystems.www.servers.unix tel:+1-816-555-1212 telnet://192.0.2.16:80/ urn:oasis:names:specification:docbook:dtd:xml:4.1.2
1.7.2 URI 格式
表示指定的URI，要使用涵蓋全部必要資訊的絕對 URI、絕對 URL 以及相對 URL 。相對 URL，是指從瀏覽器中基本 URI處指定的 URL ，形如 /image/logo.gif。
使用 http: 或https: 等協議方案名獲取資源時要指定協議型別。不區分字母大小寫，最後附一個冒號（ : ）
也可使用data: 或 javascript: 這類指定資料或指令碼程式的方案名
登入資訊（認證）
指定使用者名稱和密碼作為從伺服器端獲取資源時必要的登入資訊（身份認證）。此項是可選項。
伺服器地址
使用絕對 URI 必須指定待訪問的伺服器地址。地址可以是類似 hackr.jp 這種 DNS 可解析的名稱，或是 192.168.1.1 這類 IPv4 地址名，還可以是[0:0:0:0:0:0:0:1] 這種用方括號括起來的 IPv6 地址名。
伺服器埠名
指定伺服器連線的網路埠號。此項也是可選項，若使用者省略則自動使用預設埠號。
帶層次的檔案路徑
指定伺服器上的檔案路徑來定位特指的資源。這與 UNIX 系統的檔案目錄結構相似。
查詢字串
針對已指定的檔案路徑內的資源，可以使用查詢字串傳入任意引數。此項可選。
片段識別符號
使用片段識別符號通常可標記出已獲取資源中的子資源（文件內的某個位置）。但在 RFC 中並沒有明確規定其使用方法。該項也為可選項。
並不是所有的應用程式都符合 RFC
有一些用來制定 HTTP 協議技術標準的文件，它們被稱為 RFC（Request for Comments，徵求修正意見書）。
通常，應用程式會遵照有 RFC 確定的標準實現。可以說， RFC是網際網路的設計文件，鑰匙不按照 RDC標準執行，就有可能導致無法通訊的狀況。比如，有一臺 Web 伺服器內的應用服務沒有遵照 RFC 的標準實現，那 Web 瀏覽器就很可能無法訪問這臺伺服器。
由於不遵照 RFC 標準實現就無法進行 HTTP 協議通訊，所以基本上客戶端和伺服器端都會以 RFC 為標準來實現 HTTP 協議。但也存在某些應用因客戶端或伺服器端的筆筒，而未遵照 RFC 標準，反而將自成一套的“標準”擴充套件的情況。
不按 RFC 標準來實現，當然也不必勞心費力讓自己的“標準”符合其他所有的客戶端和伺服器端。但設想一下，如果這款應用程式的使用者非常多，那會發生什麼情況？不難想象，其他的客戶端或伺服器端必然都不得不去配合它。
實際在網際網路上，已經實現了 HTTP 協議的一些伺服器端和客戶端裡就存在上述情況。