-
URI
(標識、定位任何資源的字符串)
編輯
在電腦術語中,統一資源標識符(Uniform
Resource Identifier,或URI)是一個用於標識某一互聯網資源名稱的字符串。 該種標識容許用戶對任何(包括本地和互聯網)的資源經過特定的協議進行交互操做。URI由包括肯定語法和相關協議的方案所定義。
Web上可用的每種資源 -
HTML文檔、圖像、視頻片斷、程序等 - 由一個通用資源標識符(Uniform Resource Identifier, 簡稱"URI")進行定位。
-
中文名
-
統一資源標識符
-
外文名
-
Uniform
Resource Identifier
-
簡 稱
-
URI
-
應 用
-
萬維網
URI通常由三部分組成:
存放資源的自身的名稱,由路徑表示。
參考下面的URI,它符合當前的RFC4395規範:協議名稱://域名.根域名/目錄/文件名.後綴
例如http://b.c/d/e.f (假設b.c是一個可用的
域名,e.f是一個標準的文件)
這個URI是這樣的:這是一個可經過
HTTP協議訪問的資源,位於
主機b.c上,經過URI中的字符串「/d」訪問主機上的「d」文件夾,經過「e.f」請求訪問主機上「/d/e.f」這個文件。
這是URI的另外一個例子,指向一個用戶的郵箱:mailto:名稱@域名
注:大多數讀者可能熟悉"URL",而不是URI。URL是URI命名機制的一個子集。
2、標誌符
有的URI指向一個資源的內部。 這種URI以"#"結束,並跟着一個
anchor標誌符(稱爲片斷標誌符)。例如,下面是一個指向section_2的URI:
協議://域名/目錄/文件#片斷標示符(例如:/a/b.php#a)
3、相對URI
相對URI不包含任何命名規範信息。它的路徑一般指同一臺機器上的資源。相對URI可能含有
相對路徑(如,「..」表示上一層路徑),還可能包含片斷標誌符。
爲了說明相對URI,假設咱們有一個基本的URI:
協議://域名/目錄a/目錄b/文件c
下面的連接中使用了相對URI:
../文件D
它擴展成徹底的URI就是 "協議://域名/目錄a/文件D",
下面是一個圖像的相對URI:
<IMG src="../icons/logo.gif" alt="logo">
它擴展成徹底的URI就是 "協議://域名/目錄a/icons/logo.gif"。
在HTML中,URI被用來:
連接到另外一個文檔或資源(參看A和LINK元素)。
連接到一個外部樣式表或腳本(參看LINK和
SCRIPT元素)。
指向一個描述文檔的metadata(參看
HEAD元素)。
URL是Uniform Resource Locator的縮寫,譯爲「
統一資源定位符」。
◇ URL的格式
URL的格式由下列三部分組成:
第一部分是協議(或稱爲服務方式);
第二部分是存有該資源的
主機IP地址(有時也包括
端口號);
第三部分是主機資源的具體地址。,如目錄和文件名等。
第一部分和第二部分之間用「://」符號隔開,第二部分和第三部分用「/」符號隔開。第一部分和第二部分是不可缺乏的,第三部分有時能夠省略。
◇ URL示例
文件的URL:
用URL表示文件時,
服務器方式用file表示,後面要有
主機IP地址、文件的存取路徑(即目錄)和文件名等信息。有時能夠省略目錄和文件名,但「/」符號不能省略。
例:file://a:1234/b/c/d.txt
表明獲取資源使用ftp協議,資源目標是a主機的1234端口的b目錄下的c目錄下的d.txt。
HTTP的 URL已經在URI的組成中作過示範,在此再也不陳述。
URI、URL和URN
URI :Uniform Resource Identifier,統一資源
標識符;
URL:Uniform Resource Locator,
統一資源定位符;
URN:Uniform Resource Name,統一資源名稱。
其中,
URL,URN是URI的子集。
Web上地址的基本形式是URI,它表明統一資源
標識符。有兩種形式:
URL:目前URI的最廣泛形式就是無處不在的URL或
統一資源定位器。
URN:URL的一種更新形式,統一資源名稱(URN, Uniform Resource Name)不依賴於位置,而且有可能減小失效鏈接的個數。可是其流行還需假以時日,由於它須要更精密軟件的支持。
URI是以某種統一的(標準化的)方式標識資源的簡單字符串。
典型狀況下,這種字符串以scheme(命名URI的名字空間的
標識符——一組相關的名稱)開頭,語法以下:
[scheme:] scheme-specific-part
URI以scheme和冒號開頭。Scheme用大寫/小寫字母開頭,後面爲空或者跟着更多的大寫/小寫字母、數字、加號、減號和點號。冒號把scheme與scheme-specific-part分開了,而且scheme-specific-part的語法和語義(意思)由URI的名字空間決定。以下面的例子:
http://域名,其中http是scheme,//域名 是scheme-specific-part,而且它的scheme與scheme-specific-part被冒號分開了。
URI有絕對和相對之分,絕對的URI指以scheme(後面跟着冒號)開頭的URI。前面提到的http://域名 就是絕對的URI的一個例子,其它的例子還有mailto:xxx@xxx.xx、news:地址和xyz://whatever。你能夠把絕對的URI看做是以某種方式引用某種資源,而這種方式對
標識符出現的環境沒有依賴。若是使用文件系統做類比,絕對的URI相似於從根目錄開始的某個文件的徑。
與絕對的URI不一樣的,相對的URI不是以scheme(後面跟着冒號)開始的URI。 它的一個例子是articles/articles.html。你能夠把相對的URI看做是以某種方式引用某種資源,而這種方式依賴於標識符出現的環境。若是用文件系統做類比,相對的URI相似於從當前目錄開始的文件路徑。
URL是Uniform Resource Location的縮寫,譯爲"統一資源定位符"。通俗地說,URL是Internet上用來描述信息資源的字符串,主要用在各類WWW客戶程序和
服務器程序上,特別是著名的Mosaic。採用URL能夠用一種統一的格式來描述各類信息資源,包括文件、服務器的地址和目錄等。
目前最大的缺點是當信息資源的存放地點發生變化時,必須對URL做相應的改變。所以人們正在研究新的信息資源表示方法,例如:URI(Universal Resource Identifier)即"通用資源標識"(參見RFC 1630)、URN(Uniform Resource Name)即"統一資源名"和URC(Uniform Resource Citation)即"統一資源引用符"等。
URI還在進一步的研究當中。研究的方向就是彌補URL的缺點。
URI可被視爲定位符(URL),名稱(URN)或二者兼備。統一資源名(URN)如同一我的的名稱,而
統一資源定位符(URL)表明一我的的住址。換言之,URN定義某事物的身份,而URL提供查找該事物的方法。URN僅用於命名,而不指定地址。
用於
標識惟一書目的ISBN系統是一個典型的URN使用範例。例如,ISBN 0486275574(urn:isbn:0-486-27557-4)無二義性地標識出莎士比亞的戲劇《羅密歐與朱麗葉》的某一特定版本。爲得到該資源並閱讀該書,人們須要它的位置,也就是一個URL地址。在類Unix操做系統中,一個典型的URL地址多是一個
文件目錄,例如file:///home/username/RomeoAndJuliet.pdf。該URL
標識出存儲於本地硬盤中的電子書文件。所以,URL和URN有着互補的做用。
技術觀點
URL是
標識一個互聯網資源,並指定對其進行操做或取得該資源的方法的URI。可能經過對主要訪問手段的描述,也可能經過網絡「位置」進行標識。例如一個URL,標識一個特定資源(首頁)並表示該資源的某種形式(例如以編碼
字符表示的,首頁的HTML代碼)是能夠經過URL指定的網絡
主機得到的。URN是基於某命名空間經過名稱指定資源的URI。人們能夠經過URN來指出某個資源,而無需指出其位置和得到方式。資源無需是基於互聯網的。例如,URN urn:isbn:0-395-36341-1 指定標識系統(即國際標準書號ISBN)和某資源在該系統中的惟一表示的URI。它能夠容許人們在不指出其位置和得到方式的狀況下談論這本書。
技術刊物,特別是IETF和W3C發佈的標準中,基本再也不使用「URL」這一術語,由於不多須要區別URL和URI。可是,在非技術文獻和萬維網軟件中,URL這一術語仍被普遍使用。此外,術語「網址」在非技術文獻中時常做爲URL或URI的同義詞出現,雖然每每其指代的只是「http」和「https」協議。
RFC 3305
關於URI的討論多源於題目爲《
W3C/IETF URI規劃聯合小組報告:統一
標識資源符(URI),URL和統一資源名(URN):闡明與建議》的RFC3305文件。這一RFC文件描述了一個,以統一W3C和IETF內部對於各類「UR*」術語之間關係的不一樣見解爲目的而設立的,W3C/IETF聯合工做小組的工做。雖然未做爲標準被這兩個組織所發佈,但該文件確立了上述種種共識,並就此催生了許多標準的誕生。
發展
URI與URL有着共同的歷史。在1990年,Tim Berners-Lee的關於
超文本的提案間接地引入了使用URL做爲一個表示
超連接目標資源的短字符串的概念。當時,人們稱之爲「超文本名」或「文檔名」。
在以後的三年半中,因爲萬維網的HTML(
超文本標記語言)核心技術、HTTP與瀏覽器都獲得了發展,區別提供資源訪問和資源標記的兩種字符串的必要性開始顯現。雖然其時還沒有被正式定義,但「
統一資源定位符」這一術語開始被用於表明前者,然後者則由「統一資源名稱」所表示。
在關於定義URL和URN的爭論中,人們注意到二者事實上基於同一個基礎的「資源
標識」的概念。在1994年6月,IETF發佈了Berners-Lee的RFC 1630,(非正式地)指出了URL和URN的存在,並進一步定義了「通用資源
標識符」——語義和語法由具體協議規定的類URL字符串的規範文法。此外,該RFC文檔亦嘗試定義了其時正被使用着的URL協議的文法,同時指出(但並未標準化)了相對URL和片斷標識符的存在。
標準改良
1994年12月,RFC 1738 正式定義了絕對和相對URL,改進了URL文法,定義瞭如何解析URL爲絕對形式,並更加完善地列舉了其時正處於使用中的URL協議。而URN定義和文法直到1997年5月RFC 2141公佈後才正式統一。
1998年8月,隨着RFC 2396的發表,URI文法造成了獨立的標準,同時RFC 1630和1738中關於URI和URL的許多部分也獲得了修訂和增補。新RFC修改了「URI」中「U」的含義:它開始表明統一(Uniform)而再也不是通用(Universal)。RFC 1738中總結了既存URL協議的部分被移至另一篇獨立文檔中。IANA 保留着這些協議的註冊信息,而RFC 2717首次描述了註冊它們的流程。
在1999年12月,RFC 2732對RFC 2396進行了小幅更新,開始容許URI包括IPv6地址。一段時間之後,在兩個標準中暴露出的一些問題促使了一系列的修訂草案的發展,這些草案被統稱爲rfc2396bis。這一由RFC 2396的共同做者Roy Fielding引導協調的集體努力,由2005年1月RFC 3986的發佈推至了頂峯。該RFC文檔成爲了現今(2009年)於互聯網上被推薦使用的URI文法版本,並使得RFC 2396成爲了歷史。然而,它卻並未替代現有的URL協議細節;RFC 1738繼續管轄着大多數協議,除了某些已被它取而代之的場合——例如被RFC 2616改良的」HTTP」協議等。與此同時,IETF發佈了RFC 3986,亦即完整的STD 66標準,
標識着URI通用文法正式成官方
因特網協議。
在2002年8月,RFC 3305指出,雖然術語「URL」仍被普遍地用於平常用語之中,但其自己已幾乎被廢棄。其功用,僅是做爲對於某些URI因包含某種指示着網絡可達性的協議而做爲地址存在的提醒而已。基於URI的衆多標準,例如資源描述框架等,已經清楚地代表,資源標識本無需指出經過互聯網得到資源副本的方法,亦無須指出資源是否基於網絡。
在2006年2月,RFC 4395用了15頁詳細闡述了《關於新的URI方案的指導方針和登記程序》
[1]
在2006年11月1日,W3C技術架構小組公佈了《鏈接替代副本使查找和發佈可行化》,一個對於發佈給定資源的多個版本的權威URI和其最佳實踐的指導。例如,內容可能因用於訪問資源的設備的支持性和設定不一樣,而語言或大小上有所調整已適應這種差別。
與XML命名空間
XML擁有一個叫命名空間的,一個可包含元素集和屬性名稱的抽象域的概念。命名空間的名稱(一個必須遵照通用URI文法的字符串)用於
標識一個XML命名空間。可是,命名空間的名稱通常不被認爲是一個URI,由於URI規範定義了字符串的「URI性」是根據其目的而不是其詞法組成決定的。一個命名空間名稱同時也並不必定暗示任何URI協議的語義;例如,一個以」http:」開頭的命名空間名稱極可能與HTTP協議沒有任何關係。XML專家們就這一問題在XML開發
電子郵件列表上進行了深刻的辯論;一部分人認爲命名空間名稱能夠是URI,因爲包含一個具體命名空間的名稱集能夠被看做是一個被
標識的資源,也因爲「XML中的命名空間」規範的一個版本指出過命名空間名稱「是」一個URI引用。可是,集體共識彷佛指出一個命名空間名稱只是一個湊巧看起來像URI的字符串,僅此而已。
早先,命名空間名稱是能夠匹配任何非空URI引用的語法的,但後來的一個對於「XML命名空間建議」的訂正廢棄了相對URI引用的使用。一個獨立的、針對XML 1.1的命名空間的規範容許使用IRI引用做爲命名空間名稱的基準,而不只是URI引用。
爲了消除XML新人中產生的對於URI(尤爲是HTTP URL)的使用的困惑,一個被稱爲RDDL(資源目錄描述語言)的描述語言被創建了,雖然RDDL的規範並無正式地位,也並無得到任何相關組織(例如W3C)的檢查和支持。一個RDDL文檔能夠提供關於一個特定命名空間和使用它的XML文檔的,機器與人類都能讀懂的信息。XML文檔的做者鼓勵使用RDDL文檔,這樣一旦文檔中的命名空間名稱被索引,(系統)就會取得一個RDDL文檔。這樣,許多開發者對於讓命名空間名稱指向網絡可達資源的需求就能獲得知足。
-
參考資料
-
- 1. Adobe等5位撰寫人. [RFC4395]Guidelines and Registration Procedures for New URI Schemes [S] 2006-2;