維基百科

統一資源標識符

用於標識互聯網資源名稱的字符串

統一資源標識符[1][2]（英語：Uniform Resource Identifier，縮寫：URI）是在互聯網中唯一的字符序列[3]，用於標識各類抽象或物理資源等對象的統一符號和編碼規則，例如網頁上的資源、郵件地址、電話號碼、書籍和現實世界的對象如人和地點、概念等[4][5] 。它由三部分組成：統一資源名稱（URN），作為對象的邏輯名稱；統一資源屬性（英語：Uniform Resource Characteristic）（URC），作為對象的元數據；統一資源定位器（URL），作為對象的定位和獲取。URI用於標識任何使用資源描述框架（RDF）描述的事物，例如使用網絡本體語言（OWL）定義的本體中的概念，以及使用FOAF（英語：FOAF）詞彙描述的人，都將各自有一個獨立的URI。

該種標誌允許用戶對網絡中（一般指萬維網）的資源通過特定的協議進行交互操作。URI的最常見的形式是統一資源定位符（URL），經常指定為非正式的網址。更罕見的用法是統一資源名稱（URN），其目的是通過提供一種途徑。用於在特定的命名空間資源的標誌，以補充網址。

與URL和URN的關係

 
URL方案分類圖。URL(定位符)和URN(名稱)方案屬於URI的子類，URI可以為URL或URN兩者之一或同時是URI和URN。技術上講，URL和URN屬於資源ID；但是，人們往往無法將某種方案歸類於兩者中的某一個：所有的URI都可被作為名稱看待，而某些方案同時體現了兩者中的不同部分。

URI可被視為定位符（URL），名稱（URN）或兩者兼備。統一資源名（URN）如同一個人的名稱，而統一資源定位符（URL）代表一個人的住址。換言之，URN定義某事物的身份，而URL提供查找該事物的方法。

用於標誌唯一書目的ISBN系統是一個典型的URN使用範例。例如，ISBN 0-486-27557-4無二義性地標誌出莎士比亞的戲劇《羅密歐與朱麗葉》的某一特定版本。為獲得該資源並閱讀該書，人們需要它的位置，也就是一個URL地址。在類Unix操作系統中，一個典型的URL地址可能是一個文件目錄，例如file:///home/username/RomeoAndJuliet.pdf。該URL標誌出存儲於本地硬盤中的電子書文件。因此，URL和URN有着互補的作用。

技術觀點

URL是一種URI，它標誌一個互聯網資源，並指定對其進行操作或取得該資源的方法。可能通過對主要訪問手段的描述，也可能通過網絡「位置」進行標誌。例如，http://www.wikipedia.org/這個URL，標誌一個特定資源（首頁）並表示該資源的某種形式（例如以編碼字符表示的，首頁的HTML代碼）是可以通過HTTP協議從www.wikipedia.org這個網絡主機獲得的。URN是基於某命名空間通過名稱指定資源的URI。人們可以通過URN來指出某個資源，而無需指出其位置和獲得方式。資源無需是基於互聯網的。例如，URN urn:ISBN 0-395-36341-1 指定標誌系統（即國際標準書號ISBN）和某資源在該系統中的唯一表示的URI。它可以允許人們在不指出其位置和獲得方式的情況下談論這本書。

技術刊物，特別是IETF和W3C發布的標準中，通常不再[何時？]使用「URL」這一術語，因為很少需要區別URL和URI。[6]但是，在非技術文獻和萬維網軟件中，URL這一術語仍被廣泛使用。此外，術語「網址」（沒有正式定義）在非技術文獻中時常作為URL或URI的同義詞出現，雖然往往其指代的只是「http」和「https」協議。

RFC 3305

關於URI的討論多源於題目為《W3C/IETF URI規劃聯合小組報告：統一標誌資源符（URI），URL和統一資源名（URN）：闡明與建議》的 RFC3305 文件。這一RFC文件描述了一個，以統一W3C和IETF內部對於各種「UR*」術語之間關係的不同看法為目的而設立的，W3C/IETF聯合工作小組的工作。雖然未作為標準被這兩個組織所發布，但該文件確立了上述種種共識，並就此催生了許多標準的誕生。

文法

URI文法由URI協議名（例如http、ftp、mailto、file），一個冒號，和協議對應的內容所構成。特定的協議定義了協議內容的語法和語義，而所有的協議都必須遵循一定的URI文法通用規則，亦即為某些專門目的保留部分特殊字符。URI文法同時也就各種原因對協議內容加以其他的限制，例如，保證各種分層協議之間的協同性。百分號編碼也為URI提供附加信息。

通用URI的格式如下：

[協議名]://[用戶名]:[密碼]@[主機名]:[端口]/[路徑]?[查詢參數]#[片段ID]

例子

下圖展示了一些 URI 示例及它們的組成部分。 

          userinfo       host      port
          ┌──┴───┐ ┌──────┴──────┐ ┌┴┐
  https://[email protected]:123/forum/questions/?tag=networking&order=newest#top
  └─┬─┘   └─────────────┬────────────┘└───────┬───────┘ └────────────┬────────────┘ └┬┘
  scheme          authority                  path                  query           fragment

  ldap://[2001:db8::7]/c=GB?objectClass?one
  └┬─┘   └─────┬─────┘└─┬─┘ └──────┬──────┘
  scheme   authority   path      query

  mailto:[email protected]
  └─┬──┘ └────┬─────────────┘
  scheme     path

  news:comp.infosystems.www.servers.unix
  └┬─┘ └─────────────┬─────────────────┘
  scheme            path

  tel:+1-816-555-1212
  └┬┘ └──────┬──────┘
  scheme    path

  telnet://192.0.2.16:80/
  └─┬──┘   └─────┬─────┘│
  scheme     authority  path

  urn:oasis:names:specification:docbook:dtd:xml:4.1.2
  └┬┘ └──────────────────────┬──────────────────────┘
  scheme                    path

歷史

命名、定位與標誌資源

URI與URL有着共同的歷史。在1990年，提姆·柏內茲-李的關於超文本的提案[7]間接地引入了使用URL作為一個表示超鏈接目標資源的短字符串的概念。當時，人們稱之為「超文本名」[8]或「文檔名」。

在之後的三年半中，由於萬維網的超文本標記語言核心技術、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文法形成了獨立的標準[9]，同時RFC 1630和1738中關於URI和URL的許多部分也得到了修訂和增補。[誰？]。新RFC修改了「URI」中「U」的含義：它開始代表統一（Uniform）而不再是通用（Universal）。RFC 1738中總結了既存URL協議的部分被移至另外一篇獨立文檔中。[10]IANA 保留着這些協議的註冊信息[11]，而RFC 2717首次描述了註冊它們的流程。

在1999年12月，RFC 2732對RFC 2396進行了小幅更新，開始允許URI包括IPv6地址。一段時間以後，在兩個標準中暴露出的一些問題促使了一系列的修訂草案的發展，這些草案被統稱為rfc2396bis。這一由RFC 2396的共同作者Roy Fielding（英語：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年11月1日，W3C技術架構小組（W3C's Technical Architecture Group，TAG）公布了《連接替代副本使查找和發布可行化 （頁面存檔備份，存於網際網路檔案館）》，一個對於發布給定資源的多個版本的權威URI和其最佳實踐的指導。例如，內容可能因用於訪問資源的設備的支持性和設定不同，而語言或大小上有所調整已適應這種差異。

語義網使用HTTP URI協議以標誌文檔和現實世界中的概念：這使得人們就如何區分二者產生了一些困擾。W3C技術架構小組在2005年6月發布了一封關於如何解決這一問題的電子郵件，該郵件被稱為「http範圍-14 決議」 。[12]

為了擴充這個（相當簡短的）電子郵件，W3C在2008年3月發布了互聯網組注釋《用於語義網的酷URI》[13]。這一文檔詳細闡釋了內容協商和303重定向碼的使用。

URI引用

另一種類型的字符串——「URI引用」——代表一個URI並（相應地）代表被該URI所標誌的資源。非正式使用中，URI和URI引用的區別少有被提及，但協議文檔自然不應允許歧義的存在。

URI引用可取用的格式包括完整URI，URI中協議特定的部分，或其後附部分——甚至是空字符串。一個可選的片段標誌符以#開頭，可出現在URI引用的結尾。引用中，#之前的部分間接標誌一個資源，而片段標誌符則標誌資源的某個部分。

為從URI引用獲得URI，軟件將URI引用與一個絕對「基址」基於一個固定算法合併，並轉換為「絕對」形式。系統將URI引用視作相對於基址URI，雖然在絕對引用的情況下基址並無意義。基址URI一般標誌包含URI引用的文檔，但仍可被文檔內包含的聲明，或外部數據傳輸協議所包括的聲明改寫。若基址URI包括一個片段標誌符，則該標誌符在合併過程中被忽略。如果在URI引用中出現片段標誌符，則在合併過程中被保留。

網絡文檔標記語言時常使用URI引用指向其它資源，如外部文檔或同一邏輯文檔的其他部分等。

標記語言中URI引用的使用

  • 在HTML中，img元素的src屬性值是URI引用，a或link元素的href屬性值亦如是。
  • 在XML中，在一個DTD中的SYSTEM關鍵字之後出現的系統描述符是一個無片段的URI引用。
  • 在XSLT中，xsl:import元素/指令的href屬性值是一個URI引用，document()函數的第一個參數與之相仿。

絕對URI的例子

  • http://example.org/absolute/URI/with/absolute/path/to/resource.txt
  • ftp://example.org/resource.txt
  • urn:issn<XSLT>:1535-3613

URI引用的例子

  • http://zh.wikipedia.org/wiki/URI#Examples_of_URI_references （"http" 指定協議名, "zh.wikipedia.org"是「典據」, "/wiki/URI"是指向英文維基頁面的「路徑」，而"#Examples_of_URI_references"是指向中文維基頁面相應片段的「URI」。)
  • http://example.org/absolute/URI/with/absolute/path/to/resource.txt
  • //example.org/scheme-relative/URI/with/absolute/path/to/resource.txt

/relative/URI/with/absolute/path/to/resource.txt

  • relative/path/to/resource.txt
  • ../../../resource.txt
  • ./resource.txt#frag01
  • resource.txt
  • #frag01
  • (空字符串)

URI解析

「解析」一個URI意味着將一個相對URI引用轉換為絕對形式，或者通過嘗試獲取一個可解引URI或一個URI引用所代表的資源來解引用這個URI。文檔處理軟件的「解析」部分通常同時提供這兩種功能。

一個URI引用可以是一個同文檔引用：一個指向包含URI引用自身的文檔的引用。文檔處理軟件可有效地使用其當前的文檔資源來完成對於同文檔引用的解析而不需要重新取得一份資源。這只是一個建議——文檔處理軟件自然可以選用另外的方法來決定是否獲取新資源。

當前截至2009 年 (2009 -Missing required parameter 1=month!)的URI規範，RFC 3986，將一個同文檔引用的URI定義為「當解析為絕對形式時與引用的基文檔地址完全一致的文檔」。一般來說，基文檔URI就是包含引用的文檔的URI。例如，XSLT 1.0包括document()函數以實現這一功能。RFC 3986同時也正式定義了URI等效性，一個可以被[誰？]用來判斷一個與基URI不同的URI是否表示同一個資源，並因此可以被認為是同文檔引用。

RFC 2396給出了一個不同的判斷同文檔引用的方法；RFC 3986替代了RFC 2396，但RFC 2396仍舊作為許多規範和實現的基礎而存在。這一規範將一個空字符串或僅包括#字符和可選的片段標誌符組成的URI引用定義為同文檔引用。

與XML命名空間的關係

XML擁有一個叫命名空間的，一個可包含元素集和屬性名稱的抽象域的概念。命名空間的名稱（一個必須遵守通用URI文法的字符串）用於標誌一個XML命名空間。但是，命名空間的名稱一般[14]不被認為是一個URI，因為URI規範定義了字符串的「URI性」是根據其目的而不是其詞法組成決定的。一個命名空間名稱同時也並不一定暗示任何URI協議的語義；例如，一個以「http:」開頭的命名空間名稱很可能與HTTP協議沒有任何關係。XML專家們就這一問題在XML開發電子郵件列表上進行了深入的辯論；一部分人認為[誰？]命名空間名稱可以是URI，由於包含一個具體命名空間的名稱集可以被看作是一個被標誌的資源，也由於「XML中的命名空間」規範的一個版本指出過命名空間名稱「是」一個URI引用。[15]但是，集體共識似乎指出一個命名空間名稱只是一個湊巧看起來像URI的字符串，僅此而已。

早先，命名空間名稱是可以匹配任何非空URI引用的語法的，但後來的一個對於「XML命名空間建議」的訂正廢棄了相對URI引用的使用。一個獨立的、針對XML 1.1的命名空間的規範允許使用IRI引用作為命名空間名稱的基準，而不僅是URI引用。

為了消除XML新人中產生的對於URI（尤其是HTTP URL）的使用的困惑，一個被稱為RDDL（資源目錄描述語言）的描述語言被建立了，雖然RDDL的規範並沒有正式地位，也並沒有獲得任何相關組織（例如W3C）的檢查和支持。一個RDDL文檔可以提供關於一個特定命名空間和使用它的XML文檔的，機器與人類都能讀懂的信息。XML文檔的作者鼓勵使用RDDL文檔，這樣一旦文檔中的命名空間名稱被索引，（系統）就會取得一個RDDL文檔。這樣，許多開發者對於讓命名空間名稱指向網絡可達資源的需求就能得到滿足。

參見

參考文獻

  1. ^ joannaleecy; KevinAsgari. 统一资源标识符 (URI) 参考. Microsoft Learn. 2023-05-09 [2024-05-07]. （原始內容存檔於2024-05-07） （中文（中國大陸））. 
  2. ^ Uniform Resource Identifier. 術語在線. 全國科學技術名詞審定委員會.  （簡體中文）
  3. ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry 2005，第1頁, "Abstract"
  4. ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry 2005，第7頁; "1.1.2. Examples", "1.1.3. URI, URL, and URN"
  5. ^ Berners-Lee, Tim; Fielding, Roy T.; Masinter, Larry 2005，第5頁, "Resource: the term "resource" is used in a general sense for whatever might be identified by a URI"
  6. ^ URI Planning Interest Group, W3C/IETF. URIs, URLs, and URNs: Clarifications and Recommendations 1.0. 2001-09-21 [2009-07-27]. （原始內容存檔於2012-12-19）. 
  7. ^ Palmer, Sean B. The Early History of HTML. [2009-04-30]. （原始內容存檔於2009-04-17）. 
  8. ^ W3 Naming Schemes. W3. [2009-07-24]. （原始內容存檔於2011-11-12）. The format of a hypertext name consists of the name of the naming sub-scheme to be used, then a name in a format particular to that sub-scheme, then an optional anchor identifier within the document. For example, the format is for all internet-based access methods: scheme : // host.domain:port / path / path # anchor 
  9. ^ FAQS.org. [2010-08-14]. （原始內容存檔於2010-08-24）. 
  10. ^ This separate document is not explicitly linked[誰？], RFC 2717 and RFC 4395 point to the IANA registry as the official URI scheme registry.
  11. ^ IANA registry of URI schemes. [2010-08-14]. （原始內容存檔於2010-08-24）. 
  12. ^ The httpRange-14 resolution consists of three bullet points: see Fielding, Roy T. [httpRange-14] Resolved. 2005-06-18 [2009-07-24]. （原始內容存檔於2009-07-24）. , and did not help much to reduce the confusion.
  13. ^ W3.org. [2010-08-16]. （原始內容存檔於2019-01-30）. 
  14. ^ Harold, Elliote Rusty (2004). XML 1.1 Bible, Third Edition, Wiley Publishing Inc., p. 291. ISBN 0-7645-4986-3.
  15. ^ World Wide Web Consortium. Namespaces in XML (PDF). W3C. 1999-01-14 [2009-09-14]. （原始內容 (PDF)存檔於2011-02-02）. [Definition:] The attribute's value, a URI reference, is the namespace name identifying the namespace. 

引用作品

取自「https://zh.wikipedia.org/w/index.php?title=统一资源标识符&oldid=84958043」