統一資源標識符

統一資源標識符
縮寫	Uri
領域	全球資訊網

統一資源標識符（ URI ）是一個獨特的字符序列，可以標識Web技術使用的邏輯或物理資源。烏里斯（Uris）可用於識別任何東西，包括現實世界中的對象，例如人，地點，概念或信息資源，例如網頁和書籍。一些URI提供了一種在網絡上找到和檢索信息資源的方法（無論是在Internet還是在另一個專用網絡上，例如計算機文件系統或Intranet ）；這些是統一的資源定位器（URL）。 URL提供資源的位置。 URI在指定位置或URL處按名稱標識資源。其他URI僅提供一個唯一的名稱，而沒有找到或檢索有關它的資源或信息的方法；這些是統一的資源名稱（urns）。使用URI的Web技術不僅限於Web瀏覽器。 URI用於使用資源描述框架（RDF）來識別任何描述的內容，例如，使用網絡本體論語言（OWL）定義的本體論的一部分，以及使用朋友詞彙的朋友進行描述的人有一個單獨的URI。

歷史

概念

Uris和URL具有共同的歷史。在1990年，蒂姆·伯納斯·李（Tim Berners-Lee）對超文本的提議隱含地引入了URL作為代表超鏈接目標的資源的簡短字符串的想法。當時，人們將其稱為“超文本名稱”或“文檔名稱”。

在接下來的三年半中，隨著全球Web的HTML，HTTP和Web瀏覽器的核心技術的開發，需要區分一個字符串，該字符串與僅命名出現的資源的字符串中提供了一個地址的字符串。儘管尚未正式定義，但“統一資源定位器”一詞代表了前者，而更具爭議性的統一資源名稱代表了後者。 1992年7月，Berners-Lee關於IETF “ UDI（通用文檔標識符） BOF ”的報告提到了URL（作為統一的資源定位器），urns（最初是作為獨特的資源編號），以及租賃新工作組的需求。 1992年11月，IETF“ URI工作組”首次開會。

在定義URL和URN的辯論中，很明顯，這兩個術語所體現的概念僅僅是資源識別基本，總體，總體，概念的方面。 1994年6月， IETF發表了Berners-Lee的第一個請求，該請求認可了URL和URN的存在。最重要的是，它為通用資源標識符定義了形式的語法（即，類似於URL的字符串，其精確的語法和語義取決於其方案）。除此之外RFC 1630試圖總結當時使用的URL方案的語法。它承認 -但沒有標準化- 相對URL和碎片標識符的存在。

精緻

1994年12月， RFC 1738正式定義了相對和絕對URL，完善了一般URL語法，定義瞭如何將相對URL解析為絕對形式，並更好地列舉了當時使用的URL方案。 urn的商定定義和語法必須等到1997年5月的IETF RFC 2141發表。

1998年8月，IETF RFC 2396發表的URI語法已成為一個單獨的規範，而與URIS和URL有關的RFCS 1630和1738的大部分部分都由IETF進行了修訂和擴展。新的RFC將“ URI”中的“ U”的含義更改為“通用”的“統一”。

1999年12月， RFC 2732向RFC 2396提供了較小的更新，允許URI可容納IPv6地址。在這兩個規格中發現的許多缺點導致了社區努力，由RFC 2396合著者羅伊·菲爾丁（Roy Fielding）協調，最終導致了2005年1月的IETF RFC 3986的出版物。雖然滲透了先前的標準，但並未使詳細信息提供詳細信息。現有的URL方案已過時； RFC 1738繼續管理此類計劃，除非另有取代。例如，IETF RFC 2616，完善http方案。同時，IETF將RFC 3986的內容作為完整的標準性STD 66發表，反映了URI通用語法作為官方Internet協議的建立。

2001年，W3C的技術架構組（TAG）發布了一份最佳實踐和規範URI指南，用於發布給定資源的多個版本。例如，內容可能因語言或大小而有所不同，以調整用於訪問該內容的設備的容量或設置。

2002年8月，IETF RFC 3305指出，儘管公眾廣泛使用，“ URL”一詞卻幾乎逐漸衰落，並且僅通過提醒一些URIS來提醒某些URI，無論是否有任何此類unternets網絡可訪問性，實際使用。由於基於URI的標準（例如資源描述）框架使資源識別不必暗示通過Internet檢索資源表示的檢索，也不需要它們根本暗示基於網絡的資源。

語義Web使用HTTP URI方案來識別用於實際用途的文檔和概念，這是對如何區分兩者引起的混亂的區別。該標籤在2005年發表了一封電子郵件，該電子郵件解決了該問題，該電子郵件被稱為HTTPRANGE-14分辨率。 W3C隨後發布了一個興趣組，標題為“ Cool Uris for Sminantic Web” ，該說明說明了內容談判的使用和HTTP 303響應代碼，以更詳細地進行重定向。

設計

URL和urns

統一的資源名稱（URN）是一個URI，在特定名稱空間中識別名稱的資源。 urn可用於談論資源，而無需暗示其位置或如何訪問它。例如，在國際標準簿號（ISBN）系統中， ISBN 0-486-27557-4標識了莎士比亞的Play Romeo和Juliet的特定版本。該版本的urn將是urn：isbn：0-486-27557-4 。但是，它沒有提供有關在哪裡找到該書副本的信息。

統一的資源定位器（URL）是一個URI，它指定了對資源表示或獲得代表的手段，即指定其主要訪問機制和網絡位置。例如，URLhttp://example.org/wiki/Main_Page指的是確定為/wiki/Main_Page，通過超文本傳輸協議（ http :)的網絡主機，其域名為example.org。（在這種情況下，HTTP通常意味著它是以HTML和相關代碼的形式。實際上，不一定是這種情況，因為HTTP允許在其標題中指定任意格式。）

urn類似於一個人的名字，而URL類似於他們的街道地址。換句話說，urn識別一個項目，URL提供了一種查找它的方法。

技術出版物，尤其是IETF和W3C制定的標準，通常反映了2001年7月30日的W3C建議中概述的觀點，該觀點承認URI一詞的優先級，而不是認可任何正式的細分中的URL和URN。

URL是一個有用但非正式的概念：URL是通過其主要訪問機制的表示（例如，其網絡“位置”）來標識資源的一種類型，而不是通過可能具有的其他某些屬性。

因此，URL只是一個URI，它恰好指向網絡上的資源。但是，在非技術環境和萬維網軟件中，“ URL”一詞仍然廣泛使用。此外，“ Web地址”一詞（沒有形式定義）通常在非技術出版物中作為使用HTTP或HTTPS方案的URI的同義詞。這樣的假設可能會導致混亂，例如，在XML名稱空間的情況下，與可分解的URI具有視覺相似性。

Whatwg產生的規格比URI更喜歡URI ，因此較新的HTML5 API使用URL而不是URI 。

標準化術語URL。 URI和IRI（國際化資源標識符）令人困惑。在實踐中，單個算法都用於兩者，因此使它們與眾不同並不能幫助任何人。 URL還可以輕鬆贏得搜索結果的受歡迎程度。

雖然大多數URI方案最初被設計為與特定協議一起使用，並且通常具有相同的名稱，但它們在語義上與協議不同。例如，該方案HTTP通常用於使用HTTP與Web資源進行交互，但是該方案文件沒有協議。

句法

URI的方案是指在該方案中分配標識符的規範。因此，URI語法是一種聯合且可擴展的命名系統，其中每個方案的規範可以使用該方案進一步限制標識符的語法和語義。 URI通用語法是所有URI方案的語法的超集。它最初是在1998年8月出版的RFC 2396中定義的，並於2005年1月發佈於RFC 3986中。

URI由由保留字符組成的一組允許的ASCII字符組成（通用：：:,/,?,#,[,]，和@;方案或特定實施：!,$,&,',(,),*,+,,,;，和=），未保留的字符（大寫和小寫字母，十進制數字，-,.,_，和~）和角色%。語法組件和子組件與保留字符（僅來自組件的通用保留字符）分開，並定義表示為未保留字符的識別數據，保留字符，這些數據分別為組件和子組件中的定界符，以及當時不分別為子組件的定義器，以及百分比編碼時，以及百分比的數量編碼。相應的字符在允許的集合之外或用作組件內部或內部的定界符。識別數據八位字的編碼百分比是三個字符的序列，由字符組成%其次是兩個十六進制的數字，代表了八位位數值。

URI通用語法由五個組成的組成部分組成，以從左到右的意義下降的順序進行層次組織：

URI = scheme ":" ["//" authority] path ["?" query] ["#" fragment]

如果組件具有關聯的定界符，並且定界符沒有出現在URI中，則不確定。方案和路徑組件始終定義。如果組件沒有字符，則為空；該方案組件始終是非空的。

權威組成部分由子組件組成：

authority = [userinfo "@"] host [":" port]

這在語法圖中表示為：

URI包括：

非空方案成分，然後是結腸（:），由一系列字符組成，以字母開頭，然後是字母，數字和+），時期（.），或連字符（-）。儘管方案是對病例不敏感的，但規範形式是小寫，並且指定方案必須使用小寫字母進行的文檔。流行計劃的例子包括http,https,ftp,mailto,file,data和irc。儘管在實踐中使用了未註冊的方案，但應在Internet分配的數字授權（IANA）中註冊URI計劃。
可選權威組成部分之前有兩個斜線（//），包括：
- 可選UserInfo子組件後面是AT符號（@），可能由用戶名和可選密碼組成，先於結腸（:）。使用格式username:password出於安全原因，在UserInfo子組件中被棄用。第一個結腸後，應用程序不應作為清晰文本的任何數據（:）在UserInfo子組件中找到，除非結腸後的數據是空字符串（指示沒有密碼）。
- A主機子組件，由註冊名稱（包括但不限於主機名）或IP地址組成。 IPv4地址必須以dot-decimal符號為中[]).
- 可選端口子組件之前是結腸（:），由十進制數字組成。
A路徑分量，由一系列路徑段組成/）。儘管定義的路徑可能為空（零長度），但始終為URI定義路徑。一個段也可能是空的，導致兩個連續的斜線（//）在路徑組件中。路徑組件可以完全類似於或映射到文件系統路徑，但並不總是暗示與一個路徑的關係。如果定義了權限組件，則路徑組件必須為空或以斜線開頭（/）。如果授權組件不確定，則該路徑不能以一個空段開始 - 也就是說，有兩個斜線（//） - 以下字符將被解釋為權威組成部分。

按照慣例，在http和https uris中，路徑的最後一部分被命名Pathinfo ，是可選的。它由不參考現有物理資源名稱（例如文件，內部模塊程序或可執行程序）的零或更多路徑段組成單獨傳遞到路徑的第一部分，該路徑識別由Web服務器管理的可執行模塊或程序；這通常用於選擇動態內容（文檔等）或根據要求進行調整（另請參見： CGI和PATH_INFO等）。

例子：

URI："http://www.example.com/questions/3456/my-document"

在哪裡："/questions"是路徑的第一部分（可執行模塊或程序）和"/3456/my-document"是名為Pathinfo的路徑的第二部分，該路徑傳遞給可執行模塊或程序"/questions"選擇請求的文檔。

HTTP或HTTPS URI包含沒有查詢部分的Pathinfo部分的HTTP URI也可以稱為“乾淨URL ”，其最後一部分可能是“ slug ”。

查詢定界符	例子
Ampersand（`&`)	`key1=value1&key2=value2`
半隆（`;`)	`key1=value1;key2=value2`

可選查詢組件之前是問號（?），由一組非層次數據組成。它的語法不是很好的定義，但是按照慣例通常是由定界符隔開的屬性 - 值對序列。
可選片段成分之前是哈希（#）。該片段包含一個碎片標識符，該片段提供了方向，例如剩餘的URI確定的文章中的部分。當主要資源是HTML文檔時，片段通常是id特定元素的屬性，Web瀏覽器將將此元素滾動到視圖中。

方案或特定於實施的保留字符+可以在該方案，UserInfo，主機，路徑，查詢和片段中使用，以及方案或實現特定的保留字符!,$,&,',(,),*,,,;，和=可以在UserInfo，主機，路徑，查詢和片段中使用。另外，通用的保留字符:可以在UserInfo，路徑，查詢和片段，通用的保留字符中使用@和/可以在路徑，查詢和碎片以及通用的保留字符中使用?可以在查詢和碎片中使用。

示例烏里斯

下圖顯示了示例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

DOI（數字對象標識符）適合手柄系統，並適合通過適當語法的促進的URI系統。

URI參考

當URI參考是在不以方案成分開頭的uri或相對參考的後面，然後是結腸（:）。一個包含結腸特徵的路徑段（例如，foo:bar）如果其路徑組件不以斜線開頭，則不能用作相對參考的第一個路徑段（/），因為它會誤認為是方案組件。這樣的路徑段必須先於點路徑段（例如，./foo:bar).

Web文檔標記語言經常使用URI引用指向其他資源，例如外部文檔或同一邏輯文檔的特定部分：

在HTML中，src屬性img元素提供了URI參考，href屬性a或者link元素;
在XML中，系統標識符在SYSTEMDTD中的關鍵字是無碎片的URI參考；
在XSLT中，href屬性xsl:import元素/指令是URI參考；同樣，第一個論點document()功能。

https://example.com/path/resource.txt#fragment
//example.com/path/resource.txt
/path/resource.txt
path/resource.txt
../resource.txt
./resource.txt
resource.txt
#fragment

解決

針對基本URI解決URI參考會導致目標URI 。這意味著基本URI存在，並且是絕對URI （沒有碎片分量的URI）。可以按優先順序獲得基礎URI：

如果是URI，則引用URI本身；
表示的內容；
封裝表示形式的實體；
用於實際檢索的URI；
應用程序的上下文。

在具有明確定義的基礎URI的代表中

http://a/b/c/d;p?q

相對參考可以解決其目標URI，如下所示：

"g:h"     -> "g:h"
"g"       -> "http://a/b/c/g"
"./g"     -> "http://a/b/c/g"
"g/"      -> "http://a/b/c/g/"
"/g"      -> "http://a/g"
"//g"     -> "http://g"
"?y"      -> "http://a/b/c/d;p?y"
"g?y"     -> "http://a/b/c/g?y"
"#s"      -> "http://a/b/c/d;p?q#s"
"g#s"     -> "http://a/b/c/g#s"
"g?y#s"   -> "http://a/b/c/g?y#s"
";x"      -> "http://a/b/c/;x"
"g;x"     -> "http://a/b/c/g;x"
"g;x?y#s" -> "http://a/b/c/g;x?y#s"
""        -> "http://a/b/c/d;p?q"
"."       -> "http://a/b/c/"
"./"      -> "http://a/b/c/"
".."      -> "http://a/b/"
"../"     -> "http://a/b/"
"../g"    -> "http://a/b/g"
"../.."   -> "http://a/"
"../../"  -> "http://a/"
"../../g" -> "http://a/g"

URL彈im

URL彈出是一種將命令附加到URL的技術，通常是在“？”之後結束時的命令。令牌。它通常在WebDAV中用作將功能添加到HTTP的機制。例如，在版本控制系統中，要在URL中添加“結帳”命令，將其寫成http://editing.com/resource/file.php?command=checkout。在這種情況下，它具有CGI解析器和基礎資源之間的中介。

與XML名稱空間有關

在XML中，命名空間是一個抽象域，可以分配元素和屬性名稱的集合。名稱空間名稱是一個必須遵守通用URI語法的字符串。但是，該名稱通常不被視為URI，因為URI規範不僅基於詞彙組件，而且基於其預期用途。名稱名稱並不一定意味著URI方案的任何語義；例如，以HTTP開頭的名稱名稱：可能對HTTP的使用沒有任何含義。

最初，命名空間名稱可以與任何非空的URI參考的語法匹配，但是使用相對URI引用的使用是由W3C貶低的。 XML 1.1中名稱空間的單獨的W3C規範允許國際資源標識符（IRI）參考作為除URI參考之外的名稱名稱的基礎。