統一資源標誌符

統一資源標誌符在電腦術語中是用於標誌某一網際網路資源名稱的字串。該種標誌允許使用者對網路中，其目的是透過提供一種途徑。用於在特定的名稱空間資源的標誌，以補充網址。與URL和URN的關係.URI可被視為定位符代表一個人的住址。換言之，URN定義某事物的身份，而URL提供查詢該事物的方法。用於標誌唯一書目的ISBN系統是一個典型的URN使用範例。例如，codice_1無二義性地標誌出莎士比亞的戲劇《羅密歐與朱麗葉》的某一特定版本。為獲得該資源並閱讀該書，人們需要它的位置，也就是一個URL地址。在類Unix作業系統中，一個典型的URL地址可能是一個檔案目錄，例如codice_2。該URL標誌出儲存於本地硬碟中的電子書檔案。因此，URL和URN有著互補的作用。技術觀點.URL是一種URI，它標誌一個網際網路資源，並指定對其進行操作或取得該資源的方法。可能透過對主要訪問手段的描述，也可能透過網路“位置”進行標誌。例如，http://www.wikipedia.org/這個URL，標誌一個特定資源和某資源在該系統中的唯一表示的URI。它可以允許人們在不指出其位置和獲得方式的情況下談論這本書。技術刊物，特別是IETF和W3C釋出的標準中，通常不再使用“URL”這一術語，因為很少需要區別URL和URI。但是，在非技術全球資訊網軟體中，URL這一術語仍被廣泛使用。此外，術語“網址”在非技術時常作為URL或URI的同義詞出現，雖然往往其指代的只是“http”和“https”協議。RFC 3305.關於URI的討論多源於題目為《W3C/IETF URI規劃聯合小組報告：統一標誌資源符：闡明與建議》的 RFC3305 檔案。這一RFC檔案描述了一個，以統一W3C和IETF內部對於各種“UR*”術語之間關係的不同看法為目的而設立的，W3C/IETF聯合工作小組的工作。雖然未作為標準被這兩個組織所釋出，但該檔案確立了上述種種共識，並就此催生了許多標準的誕生。文法.URI文法由URI協議名，一個冒號，和協議對應的內容所構成。特定的協議定義了協議內容的語法和語義，而所有的協議都必須遵循一定的URI文法通用規則，亦即為某些專門目的保留部分特殊字元。URI文法同時也就各種原因對協議內容加以其他的限制，例如，保證各種分層協議之間的協同性。百分號編碼也為URI提供附加資訊。通用URI的格式如下：[協議名]://[使用者名稱]:[密碼]@[主機名]:[埠]/[路徑]?[查詢引數]#[片段ID]例子.下圖展示了兩個 URI 例子及它們的組成部分。歷史.命名、定位與標誌資源.URI與URL有著共同的歷史。在1990年，提姆·柏內茲-李的關於超文字的提案間接地引入了使用URL作為一個表示超連結目標資源的短字串的概念。當時，人們稱之為“超文字名”或“文件名”。在之後的三年半中，由於全球資訊網的超文字標記語言核心技術、HTTP與瀏覽器都得到了發展，區別提供資源訪問和資源標記的兩種字串的必要性開始顯現。雖然其時尚未被正式定義，但“統一資源定位符”這一術語開始被用於代表前者，而後者則由“統一資源名稱”所表示。在關於定義URL和URN的爭論中，人們注意到兩者事實上基於同一個基礎的“資源標誌”的概念。在1994年6月，IETF釋出了Berners-Lee的RFC 1630，了相對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”的含義：它開始代表統一。RFC 1738中總結了既存URL協議的部分被移至另外一篇獨立文件中。IANA 保留著這些協議的註冊資訊，而RFC 2717首次描述了註冊它們的流程。在1999年12月，RFC 2732對RFC 2396進行了小幅更新，開始允許URI包括IPv6地址。一段時間以後，在兩個標準中暴露出的一些問題促使了一系列的修訂草案的發展，這些草案被統稱為rfc2396bis。這一由RFC 2396的共同作者引導協調的集體努力，由2005年1月RFC 3986的釋出推至了頂峰。該RFC文件成為了現今於網際網路上被推薦使用的URI文法版本，並使得RFC 2396成為了歷史。然而，它卻並未替代現有的URL協議細節；RFC 1738繼續管轄著大多數協議，除了某些已被它取而代之的場合——例如被RFC 2616改良的“HTTP”協議等。與此同時，IETF釋出了RFC 3986，亦即完整的STD 66標準，標誌著URI通用文法正式成官方因特網協議。在2002年8月，RFC 3305指出，雖然術語“URL”仍被廣泛地用於日常用語之中，但其本身已幾乎被廢棄。其現在的功用，僅是作為對於某些URI因包含某種指示著網路可達性的協議而作為地址存在的提醒而已。基於URI的眾多標準，例如資源描述框架等，已經清楚地表明，資源標誌本無需指出透過網際網路獲得資源副本的方法，亦無須指出資源是否基於網路。在2006年11月1日，W3C技術架構小組公佈了《連線替代副本使查詢和釋出可行化 》，一個對於釋出給定資源的多個版本的權威URI和其最佳實踐的指導。例如，內容可能因用於訪問資源的裝置的支援性和設定不同，而語言或大小上有所調整已適應這種差異。語義網使用HTTP URI協議以標誌文件和現實世界中的概念：這使得人們就如何區分二者產生了一些困擾。W3C技術架構小組在2005年6月釋出了一封關於如何解決這一問題的電子郵件，該郵件被稱為“http範圍-14 決議” 。為了擴充這個電子郵件，W3C在2008年3月釋出了網際網路組註釋《用於語義網的酷URI》。這一文件詳細闡釋了內容協商和303重定向碼的使用。URI引用.另一種型別的字串——“URI引用”——代表一個URI並代表被該URI所標誌的資源。非正式使用中，URI和URI引用的區別少有被提及，但協議文件自然不應允許歧義的存在。URI引用可取用的格式包括完整URI，URI中協議特定的部分，或其後附部分——甚至是空字串。一個可選的片段標誌符以#開頭，可出現在URI引用的結尾。引用中，#之前的部分間接標誌一個資源，而片段標誌符則標誌資源的某個部分。為從URI引用獲得URI，軟體將URI引用與一個絕對“基址”基於一個固定演算法合併，並轉換為“絕對”形式。系統將URI引用視作相對於基址URI，雖然在絕對引用的情況下基址並無意義。基址URI一般標誌包含URI引用的文件，但仍可被文件內包含的宣告，或外部資料傳輸協議所包括的宣告改寫。若基址URI包括一個片段標誌符，則該標誌符在合併過程中被忽略。如果在URI引用中出現片段標誌符，則在合併過程中被保留。網路文件標記語言時常使用URI引用指向其它資源，如外部文件或同一邏輯文件的其他部分等。URI引用的例子./relative/URI/with/absolute/path/to/resource.txtURI解析.“解析”一個URI意味著將一個相對URI引用轉換為絕對形式，或者透過嘗試獲取一個可解引URI或一個URI引用所代表的資源來解引用這個URI。文件處理軟體的“解析”部分通常同時提供這兩種功能。一個URI引用可以是一個同文檔引用：一個指向包含URI引用自身的文件的引用。文件處理軟體可有效地使用其當前的文件資源來完成對於同文檔引用的解析而不需要重新取得一份資源。這只是一個建議——文件處理軟體自然可以選用另外的方法來決定是否獲取新資源。當前截至2009年 (2009)[ [update]]的URI規範，RFC 3986，將一個同文檔引用的URI定義為“當解析為絕對形式時與引用的基文件地址完全一致的文件”。一般來說，基文件URI就是包含引用的文件的URI。例如，XSLT 1.0包括codice_15函式以實現這一功能。RFC 3986同時也正式定義了URI等效性，一個可以被用來判斷一個與基URI不同的URI是否表示同一個資源，並因此可以被認為是同文檔引用。RFC 2396給出了一個不同的判斷同文檔引用的方法；RFC 3986替代了RFC 2396，但RFC 2396仍舊作為許多規範和實現的基礎而存在。這一規範將一個空字串或僅包括#字元和可選的片段標誌符組成的URI引用定義為同文檔引用。與XML名稱空間的關係.XML擁有一個叫名稱空間的，一個可包含元素集和屬性名稱的抽象域的概念。名稱空間的名稱用於標誌一個XML名稱空間。但是，名稱空間的名稱一般不被認為是一個URI，因為URI規範定義了字串的“URI性”是根據其目的而不是其詞法組成決定的。一個名稱空間名稱同時也並不一定暗示任何URI協議的語義；例如，一個以“http:”開頭的名稱空間名稱很可能與HTTP協議沒有任何關係。XML專家們就這一問題在XML開發電子郵件列表上進行了深入的辯論；一名稱空間名稱可以是URI，由於包含一個具體名稱空間的名稱集可以被看作是一個被標誌的資源，也由於“XML中的名稱空間”規範的一個版本指出過名稱空間名稱“是”一個URI引用。但是，集體共識似乎指出一個名稱空間名稱只是一個湊巧看起來像URI的字串，僅此而已。早先，名稱空間名稱是可以匹配任何非空URI引用的語法的，但後來的一個對於“XML名稱空間建議”的訂正廢棄了相對URI引用的使用。一個獨立的、針對XML 1.1的名稱空間的規範允許使用IRI引用作為名稱空間名稱的基準，而不僅是URI引用。為了消除XML新人中產生的對於URI就會取得一個RDDL文件。這樣，許多開發者對於讓名稱空間名稱指向網路可達資源的需求就能得到滿足。