跳至內容

統一資源識別碼

本頁使用了標題或全文手工轉換
維基百科，自由的百科全書

統一資源識別碼[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 （中文（中國大陸））. 
  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=82554192」