統一資源定位系統（uniform resource locator;URL）是因特網的 萬維網服務 程序上用于指定信息位置的表示方法。它最初是由蒂姆·伯納斯·李發明用來作為萬維網的地址。現在它已經被 萬維網聯盟 編制為 互聯網標準 RFC1738。

基本介紹

因特網上的可用資源可以用簡單字符串來表示，該文檔就是描述了這種字符串的語法和語義。而這些字符串則被稱為：“統一資源定位器”（URL）。這篇說明源于萬維網全球信息主動組織（World Wide Web global informationinitiative）介紹的概念。RFC1630《通用資源標志符》描述了一些對象數據，他們自1990年起就開始使用這些對象數據。這篇URL說明符合《因特網資源定位符的功能需求（Functional Requirements for Internet Resource Locators》中說明的需求。這篇文檔是由工程任務組織（IETF）的URI工作小組寫的。

URL語法

正如訪問資源的方法有很多種一樣，對資源進行定位的方案也有好幾種。URL的一般語法只是為使用協議來建立新方案提供了一個框架，當然除了已經在這篇文檔中定義過的。URL通過提供資源位置的一種抽象標志符來對資源進行定位。系統定位了一個資源后，可能會對它進行各種各樣的操作，這些操作可以抽象為下面的幾個詞：訪問，更新，替換，發現屬性。一般來說，只有訪問方法這一項在任何URL方案中都需要進行描述。

主要部分

第五部分給出了URL語法的完整BNF描述。

URL通常被寫成如下形式：<方案>:<方案描述部分>

一個URL包含了它使用的方案名稱（<方案>）,其后緊跟一個 冒號 ，然后是一個字符串（<方案描述部分>），這部分的解釋由所使用的方案來決定。方案名稱由一串字符組成。小寫字母“a”——“z”，數字，字符加號（“+”），句點（“.”）和連字號（“-”）都可以。為了方便起見，程序在解釋URL的時候應該視方案名稱中的大寫字母和小寫字母一樣。（例如：視“HTTP”和“http”一樣）。

字符編碼

URL是由一串字符組成，這些字符可以是字母，數字和 特殊符號 。一個URL可以用多種方法來表現，例如：紙上的字跡，或者是用字符集編碼的 八位字節 序列。URL的解釋僅取決于所用字符的特性。在大多數URL方案中，都是使用URL不同部分的字符序列來代表因特網協議中所使用的八位字節序列。例如，在ftp方案中主機名，目錄名和文件名就是這樣的八位字節序列，它們用URL的不同部分代表。在這些部分里，一個八位字節數可以用這樣的字符來表示：該字符在US—ASCII[20]編碼字符集中的編碼是這個八位字節數。另外，八位字節數可以被編成如下形式的代碼：“%”后加兩個十六進制數字（來自于“0123456789ABCDEF”），這兩個十六進制數字代表了這八位字節數的值。(字符“abcdef”也可以用于十六進制編碼)。如果存在下面的情況：八位字節數在US-ASCII字符集中沒有相應的可顯示字符，或者使用相應字符會產生不安全因素，或者相應的字符被保留用于特定的URL方案的解釋，那么它們必須被編成代碼。

• 沒有相應的可顯示字符：URL只能用US-ASCII字符編碼集中的可顯示字符表示。US-ASCII中沒有用到十六進制的八位字節80-FF，并且00－1F和7F代表了控制字符，這些字符必須進行編碼。

• 不安全：字符不安全的原因很多。空格字符就是不安全的，因為URL在被轉錄或者被排版或者被字處理程序處理后其中重要的空格可能被忽略，而可忽略的空格卻有可能被解釋了。“<”和“>”字符也是不安全的，因為它們被用來作為URL在文本中的分隔符；而在有些系統中用引號“"”來界定URL。“#”字符也是不安全的，因為它在萬維網和其他一些系統中被用來從“片段/ 錨點 ”標志符中界定URL，所以它通常都要被編碼。字符“%”被用來對其他字符進行編碼，它也是不安全的。其他一些字符，如："{","}","|","\","^","~","[","]",和"`"，由于網關和其他傳輸代理有時會對這些字符進行修改，所以它們也是不安全的。必須對URL中所有不安全的字符進行編碼。例如，URL中的字符“#”即使是在通常不處理片斷或者錨點標志符的系統也需要進行編碼，這樣如果這個URL被拷貝到使用這些標志符的系統中，也不必改變URL編碼了。

• 保留：許多URL方案保留了一些字符并賦予特定的含義：它們出現在URL的特定部位并表示特定的含義。如果一個字符對應的八位字節在方案中被保留了，那么這個八位字節必須進行編碼。字符";","/","?",":","@","="和"&"可能被某個方案所保留，除此之外沒有其他的保留字符。通常情況下一個八位字節被用一個字符表示后或者被編碼之后，URL的解釋都是一樣的。但這對于保留字符來說就不適用了：對某一特定方案的保留字符進行編碼可能會改變URL的語義。這樣，在URL中只有字母與數字，以及 特殊字符 “$-_.+!*'(),”和用作保留目的的保留字符可以不進行編碼。另一方面，不必進行編碼的字符（包括字母與數字）如果出現在URL的特定部位，只要它們不用作保留目的，則可進行編碼。

方案和關系

URL有時候被用來定位那些包含指示器的資源，而這些指示器又指向其他資源。有時候這些指示器用 關系鏈接 表示，在關系鏈接中第二資源的位置表示符原則上“和那些除了帶有次相關路徑的表示符相同”。在這篇文檔中沒有對關系鏈接進行描述。但是，關系鏈接的使用依賴于包含分層結構的原始URL，它是關系鏈接的基礎。有些URL方案（例如ftp，http，和文件方案）包含的名字可以被認為是分層次的；這些層次之間用“/”分隔。

特殊方案

一些已經存在的標準協議和正處于試驗中的協議之間的映射關系的輪廓用BNF語法定義進行描述。下面對一些協議進行了注釋：

• ftp File Transfer protocol（文件傳輸協議）

• http Hypertext Transfer Protocol （超文本傳輸協議）

• gopher The Gopher protocol（Gopher協議）

• mailto Electronic mail address（ 電子郵件地址 ）

• news USENET news（USENET新聞）

• nntp USENET news using NNTP access（使用NNTP訪問的USENET新聞）

• telnet Reference to interactive sessions（交互式會話訪問）

• wais Wide Area Information Servers（ 廣域信息服務系統 ）

• file Host-specific file names（特殊主機文件名）

• prospero Prospero Directory Service(prospero目錄服務)

在以后的說明書中可能會對其他一些方案加以描述。這篇文檔的第四部分介紹了如何注冊新的方案，并且列出了一些正在研究中的方案名。

通用方案語法

雖然URL其他部分的語法因方案的不同而不同，但那些直接使用基于IP的協議來定位因特網上的主機的URL方案都使用了如下形式的通用語法來表示特定的方案數據：

//<用戶名>:<密碼>@<主機>:<端口>/

可能會省略“<用戶名>:<密碼>@”，“:<密碼>”，“:<端口>”，和“/”這些部分的某些或者全部。這些方案的特定數據以雙斜線“//”開頭來表明它遵從通用因特網方案語法。各個部分分別遵守如下規則：

• 用戶名：任意的用戶名稱。有些方案（例如：ftp）允許使用用戶名稱的描述。

• 密碼：任意的密碼。如果存在的話，它緊跟在用戶名后面并用一個冒號隔開。

用戶名（和密碼）如果存在的話，其后緊跟一個商用符號“@”。在用戶名和密碼字段中出現的任何“:”，“@”或者“/”都要進行編碼。注意空的用戶名或者密碼不同于沒有用戶名和密碼；決不能在沒有指定用戶名的情況下指定密碼。例如：的用戶名為空并且沒有密碼，沒有用戶名，而的用戶名是“foo”并且密碼為空。

• 主機：網絡主機的域名，或者它的以“.”分隔的四組十進制數字集合形式的IP地址。域名的形式在RFC1034[13]的3.5節和RFC1123[5]的2.1節中進行了描述，即用“.”分隔的域標志串，域標志以字母或者數字開頭和結束，也可能包含“-”字符。最右邊的域標志不能以數字開頭，這樣就在語法結構上將域名和IP地址區分開來了。

• 端口：指明鏈接的端口。大部分方案都給協議指定一個默認的端口。也可以隨意指定一個十進制形式的端口，并用冒號與主機隔開。如果忽略端口，那么這個冒號也要忽略。

• url路徑：定位符的其他部分由方案的特殊數據組成，這些特殊數據被稱為“url－路徑”。它提供了如何對特定資源進行訪問的詳細信息。注意主機（或端口）與url－路徑間的“/”不是url－路徑的一部分。url－路徑的語法依賴于所使用的方案。也依賴于它在方案中的解釋方法。

FTP

FTPURL方案可以用來指定因特網上使用FTP協議（RFC959）的可達主機上的文件和目錄。FTPURL遵從3.1節所描述的語法。如果:<端口>被省略的話，則使用缺省端口21。

1、FTP用戶名和密碼

在連接上FTP服務器后，可以用“USER”和“PASS”命令來指定用戶名和密碼。如果沒有提供用戶名或者密碼并且FTP服務器只要求一項，那么將使用到“匿名”服務器的轉換，如下所示：用戶名“anonymous”被發送。訪問資源的終端用戶的因特網電子郵件地址被作為密碼發送。如果URL提供用戶名但不提供密碼，那么遠程服務器將要求提供密碼，而解釋FTPURL的程序則要求用戶輸入密碼。

2、FTPURL-路徑FTPURL的URL-路徑語法如下：

/< cwd 2>/...//;type=

這里的到和（可能被編碼）都是字符串，是字符“a”，“i”和“d”之一。“;type=”這一部分可以被省略。和部分可以為空。整個url－路徑，包括它和包含用戶名，密碼，主機及端口的前綴間的分界符“/”都可以被省略。url－路徑可以被解釋成如下的一串FTP命令：每個元素被作為CWD（改變工作目錄）命令的參數發送。如果類型編碼是“d”，則執行一個以作為參數的NTLS（名字列表）命令，并把結果解釋為一個文件目錄列表。否則，執行一個用作為參數的TYPE命令，然后訪問文件名為的文件（例如，使用RETR命令）。name或者CWD部分的字符“/”和“;”都是保留字符，必須進行編碼。在FTP協議中，這些部分在使用前被解碼。特別的是，如果訪問一個特定文件的適當FTP命令序列需要發送一個包含“/”的字符串作為CWD或者RETR命令的參數，那么必須對每個“/”都進行編碼。例如，URL被FTP解釋為“host.dom”，并以用戶名“myname”登錄（如果需要，則提示輸入密碼），然后執行“CWD/etc”，再接著執行“RETRmotd”。這和的含義不一樣，它先執行“CWDetc”然后執行“RETRmotd”；開始的“CWD”可能被執行，進入用戶“myname”的缺省目錄。另一方面，將執行一個不帶參數的“CWD”命令，然后執行“CWDetc”，接著執行“RETRmoth”。FTPURL也可以用于其他操作；例如，可以更新遠程 文件服務器 上的文件，或者根據它的目錄列表來推斷它的一些信息。完成這些功能的機制在這兒沒有仔細介紹。

3、FTP類型編碼是可選擇的

FTPURL的整個;type=部分都是可選擇的。如果這一部分被省略，那么解釋URL的客戶程序必須猜測適當模式來使用。一般來說，文件數據內容的類型只能從文件名來猜測，例如根據 文件名后綴 猜測；用來傳輸文件的合適的類型編碼于是可以從文件的數據內容推斷出來。

4、層次

在有些文件系統中，用來表示URL的層次結構的“/”與用來構建文件系統層次的分隔符相同，這樣一來，文件名和URL路徑看起來就很像。但這并不意味著URL是一個Unix文件名。

5、優化

客戶端通過FTP對資源進行訪問時可能會使用一些額外的搜索方法來優化交互過程。例如，對一些FTP服務器來說，當訪問同一個服務器的多個URL的時候，則保持控制連接一直打開是比較合理的。但FTP協議沒有通用的層次模式，因此當一個改變目錄的命令發出后，如果是一個不同的路徑，那么一般不可能推斷出下一次將要給另一個目錄發送什么樣的序列。唯一可靠的算法是斷開然后重新建立控制連接。

HTTP

HTTPURL方案是用來標志因特網上使用HTTP(HyperTextTransferProtocol，超文本傳輸協議)的可達資源。HTTP協議在其他的地方進行了詳細說明。本文只介紹了HTTPURL的語法。HTTPURL的形式如下：

http://:/?

其中和已經在3.1節說明過了。如果:部分省略，那么就使用缺省的端口80。不需要用戶名和密碼。是一個HTTP選擇器，是查詢字符串。,和它前面的“?”都是可選擇的。如果和部分都沒有，則“/”也可以省略。和部分中的“/”，“;”和“？”都是保留字符。“/”字符可以在HTTP中用來表示層次結構。

GOPHER

GopherURL方案用來標志因特網上使用Gopher協議的可達資源。基本Gopher協議是在RFC1436中介紹的，它支持項和項（目錄）集合。Gopher+協議則在基本Gopher協議的基礎上進行了擴展，并且 向上兼容 。中對它進行了介紹。Gopher+支持聯合屬性的任意集合和使用Gopher項的替換數據表示。GopherURL提供了Gopher與Gopher+的項和項屬性。

1、GopherURL語法

GopherURL的形式如下：

gopher://:/

這里的是%09