統一資源定位系統

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

中文名稱	統一資源定位系統
英文名稱	uniform resource locator;URL
定　　義	網際網路的全球資訊網服務程式上用於指定信息位置的表示方法。
套用學科	通信科技（一級學科），服務與套用（二級學科）

基本介紹

• 中文名：統一資源定位系統
• 外文名：uniform resource locator;URL

基本介紹

網際網路上的可用資源可以用簡單字元串來表示，該文檔就是描述了這種字元串的語法和語義。而這些字元串則被稱為：“統一資源定位器”（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（檔案傳輸協定）
• httpHypertext Transfer Protocol（超文本傳輸協定）
• gopherThe Gopher protocol（Gopher協定）
• mailtoElectronic mail address（電子郵件地址）
• newsUSENET news（USENET新聞）
• nntpUSENET news using NNTP access（使用NNTP訪問的USENET新聞）
• telnetReference to interactive sessions（互動式會話訪問）
• waisWide Area Information Servers（廣域信息服務系統）
• fileHost-specific file names（特殊主機檔案名稱）
• prospero Prospero Directory Service(prospero目錄服務)

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

通用方案語法

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

//<用戶名>:<密碼>@<主機>:<連線埠>/<url路徑>

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

• 用戶名：任意的用戶名稱。有些方案（例如：ftp）允許使用用戶名稱的描述。
• 密碼：任意的密碼。如果存在的話，它緊跟在用戶名後面並用一個冒號隔開。

用戶名（和密碼）如果存在的話，其後緊跟一個商用符號“@”。在用戶名和密碼欄位中出現的任何“:”，“@”或者“/”都要進行編碼。注意空的用戶名或者密碼不同於沒有用戶名和密碼；決不能在沒有指定用戶名的情況下指定密碼。例如：<URL:ftp://@host.com/>的用戶名為空並且沒有密碼，<URL:ftp://host.com/>沒有用戶名，而<URL:ftp://foo:@host.com/>的用戶名是“foo”並且密碼為空。

• 主機：網路主機的域名，或者它的以“.”分隔的四組十進制數字集合形式的IP位址。域名的形式在RFC1034[13]的3.5節和RFC1123[5]的2.1節中進行了描述，即用“.”分隔的域標誌串，域標誌以字母或者數字開頭和結束，也可能包含“-”字元。最右邊的域標誌不能以數字開頭，這樣就在語法結構上將域名和IP位址區分開來了。
• 連線埠：指明連結的連線埠。大部分方案都給協定指定一個默認的連線埠。也可以隨意指定一個十進制形式的連線埠，並用冒號與主機隔開。如果忽略連線埠，那么這個冒號也要忽略。
• url路徑：定位符的其他部分由方案的特殊數據組成，這些特殊數據被稱為“url－路徑”。它提供了如何對特定資源進行訪問的詳細信息。注意主機（或連線埠）與url－路徑間的“/”不是url－路徑的一部分。url－路徑的語法依賴於所使用的方案。也依賴於它在方案中的解釋方法。

FTP

FTP URL方案可以用來指定網際網路上使用FTP協定（RFC959）的可達主機上的檔案和目錄。FTP URL遵從3.1節所描述的語法。如果:<連線埠>被省略的話，則使用預設連線埠21。

1、FTP 用戶名和密碼

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

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

<cwd1>/<cwd2>/.../<cwdN>/<name>;type=<typecode>

這裡的<cwd1>到<cwdN>和<name>（可能被編碼）都是字元串，<typecode>是字元“a”，“i”和“d”之一。“;type=<typecode>”這一部分可以被省略。<cwdx>和<name>部分可以為空。整個url－路徑，包括它和包含用戶名，密碼，主機及連線埠的前綴間的分界符“/”都可以被省略。url－路徑可以被解釋成如下的一串FTP命令：每個<cwd>元素被作為CWD（改變工作目錄）命令的參數傳送。如果類型編碼是“d”，則執行一個以<name>作為參數的NTLS（名字列表）命令，並把結果解釋為一個檔案目錄列表。否則，執行一個用<typecode>作為參數的TYPE命令，然後訪問檔案名稱為<name>的檔案（例如，使用RETR命令）。name或者CWD部分的字元“/”和“;”都是保留字元，必須進行編碼。在FTP協定中，這些部分在使用前被解碼。特別的是，如果訪問一個特定檔案的適當FTP命令序列需要傳送一個包含“/”的字元串作為CWD或者RETR命令的參數，那么必須對每個“/”都進行編碼。例如，URL<URL:ftp://[email protected]/%2Fetc/motd>被FTP解釋為“host.dom”，並以用戶名“myname”登錄（如果需要，則提示輸入密碼），然後執行“CWD /etc”，再接著執行“RETR motd”。這和<URL:ftp://myname @host.dom/etc/motd>的含義不一樣，它先執行“CWD etc”然後執行“RETR motd”；開始的“CWD”可能被執行，進入用戶“myname”的預設目錄。另一方面，<URL:ftp://[email protected]//etc/motd>將執行一個不帶參數的“CW D”命令，然後執行“CWD etc”，接著執行“RETR moth”。FTP URL也可以用於其他操作；例如，可以更新遠程檔案伺服器上的檔案，或者根據它的目錄列表來推斷它的一些信息。完成這些功能的機制在這兒沒有仔細介紹。

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

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

4、層次

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

5、最佳化

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

HTTP

HTTP URL 方案是用來標誌網際網路上使用HTTP(HyperText Transfer Protocol，超文本傳輸協定)的可達資源。HTTP協定在其他的地方進行了詳細說明。本文只介紹了HTTP URL的語法。HTTP URL的形式如下：

http://<host>:<port>/<path>?<searchpart>

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

GOPHER

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

1、Gopher URL 語法

Gopher URL的形式如下：

gopher://<host>:<port>/<gopher-path>

這裡的<gopher-path>是<gophertype><selector><gophertype><selector>%09<search><gophertype><selector>%09<search>%09<gopher+_string>之一。

如果:<port>被省略，那么使用預設連線埠70。<gophertype>是一個單字元域，它表示URL引用的資源的Gopher類型。<gopher-path>部分也可以整個為空。在這種情況下，分隔設定“/”也是可選擇的，並且<gophertype>的預設值是“1”。<selector>是Gopher選擇器字元串。在Gopher協定中，Gopher 選擇器字元串一個八位位元組串，它包括除了十六進制的09（US-ASCII HT 或tab），0A(US-ASCII 字元 LF)和0D(US-ASCII 字元CR)外的所有八位位元組。Gopher客戶通過向Gopher伺服器傳送Gopher選擇器字元串來指定要獲得的項。<gopher-path>中沒有保留字元。需要注意的是：有些Gopher<selector>字元串是以<gophertype>字元的一個拷貝來開頭，在這種情況下，這個字元將會連續出現兩次。Gopher選擇器可能是空字元串；Gopher客戶端就是這樣來查詢Gopher伺服器的高層目錄的。

2、為Gopher搜尋引擎指定URL

如果URL被提交到Gopher搜尋引擎進行查詢，那么選擇器後將緊跟一個已編碼的tab（%09）和一個搜尋字元串。Gopher客戶為了向Gopher搜尋伺服器提交一個搜尋必須向Gopher伺服器傳送<selector>字元串（編碼後），一個tab字元，和一個搜尋字元串。

3、Gopher+項的URL語法

Gopher+項的URL有一個已編碼的tab字元（%09）和一個Gopher+字元串。注意儘管<search>元素可以是空字元串，但在這種情況下必須提供%09<search>字元串。<gopher+_string>被用來表示取得Gopher+項所需要的信息。Gopher+項可以擁有交替視圖，任意的屬性系，也可以有與它們相關聯的電子表格。客戶為了獲得與Gopher+URL相關聯的數據，必須連線到伺服器並且傳送Gopher選擇器，這個選擇器的後面緊跟一個tab字元和搜尋字元串（可以為空）然後是一個tab字元和Gopher+命令。

4 、預設的Gopher+數據表示

當一個Gopher伺服器向客戶返回目錄列表時，Gopher+項後面跟著一個“+”（表示Gopher+項）或者一個“?”（表示具有與它們相關聯的+ASK形式的Gopher+項）。Gopher+字元串只有一個字元“+”的Gopher URL採用項的預設的視圖（數據表示），而Gopher+字元串只有一個字元“?”的Gopher URL則採用具有相關聯的Gopher電子表格的項。

5 、具有電子表格的Gopher+項

具有與之相關聯的+ASK的Gopher+項（也就是跟著一個“?”的Gopher+項）要求客戶端取得該項的+ASK屬性來獲得表格定義，然後讓用戶填寫這個表格並將用戶應答和獲得項的選擇器字元串一起返回。Gopher+客戶端知道如何完成這些工作，但需要依賴於Gopher+項描述中的“？”標籤來知道什麼時候處理這種情況。Gopher+項中的“?”被用來與Gopher+協定中這種符號的用法相兼容。

6 、Gopher+項屬性集

為了表示項的Gopher+屬性，Gopher URL的Gopher+字元串由“!”或者“$”組成。“!”涉及Gopher+項的所有屬性。“$”則涉及Gopher目錄中所有項的所有項屬性。

7、涉及特定的Gopher+屬性

為了表示特殊的屬性，URL的gopher+_string是“!<attribute_name>”或者“$<attribute_name>”。例如，gopher+_string的值為“!+ABSTRACT” 表示屬性包含一個項的抽象。為了表示幾個屬性，gopher+_string可以由幾個屬性名組成，並且用已編碼的空格分隔開。例如，“!+ABSTRACT%20+SMELL”代表一個項的+ABSTRACT和+SMELL屬性。

8、Gopher+交替視圖的URL語法

Gopher+允許項有最佳化的交替數據表示(交替視圖)。Gopher+客戶端傳送適當的視圖和語言標誌（出現在項的+VIEW屬性里）來獲得Gopher+的交替視圖。為了引用一個特定的Gopher+交替視圖試圖，URL的Gopher+字元串的形式必須如下所示：

+<視圖名稱>%20<語言名稱>

例如，Gopher+字元串"+application/postscript%20Es_ES"引用了一個Gopher+項的交替視圖的西班牙語附註。

9、 Gopher+電子表格的URL語法

一個引用了填充有特定數據的Gopher+電子表格（一個ASK塊）所參考的項的URL的Gopher+字元串是通過對客戶送給伺服器的gopher+字元串進行編碼得到的。這個gopher+字元串的形式如下所示：

+%091%0D%0A+-1%0D%0A<ask_item1_value>%0D%0A<ask_item2_value>%0D%0A.%0D%0A

Gopher客戶端為了獲得這個項，它傳送如下信息給Gopher伺服器：

<a_gopher_selector><tab>+<tab>1<cr><lf>+-1<cr><lf><ask_item1_value><cr><lf> <ask_item2_value><cr><lf><cr><lf>

MAILTO

mailto URL方案是用來指明一個個體或者服務的網際網路郵件地址的。它只代表網際網路郵件地址，而不表示任何其它的附加信息。Mailto URL的形式如下所示：

mailto:<rfc822-addr-spec>

這裡的<rfc822-addr-spec>是地址說明（的編碼），這在RFC822[6]中進行了詳細的說明。在mailto URL中沒有保留字。注意百分符號（"%"）在RFC822中用得比較普遍，它必須被編碼。不像許多URL，mailto方案不代表可直接訪問的數據對象；也沒有跡象表面它代表一個對象。它的使用方法不同於MIME中的報文/外部實體類型。

NEWS

新聞URL方案被用來查閱新聞組或者USENET新聞上的獨立文章，這一點在RFC1036中詳細說明了。新聞URL的形式是下面兩個之一：

news:<newsgroup-name>

news:<message-id>

<newsgroup-name>

是一個用句點分隔的層次名稱，例如：“comp.infosystems.www.misc”。<message-id>與RFC1036中的2.1.5節中的Message-ID一樣，只是後者沒有用“<”和“>”括起來；它的形式如下<unique>@<full_domain_name>。訊息標誌符通過代表“在（at）”的“@”字元和新聞組名稱相區分。除此之外，在新聞URL組件中沒有其它的保留字元。如果<newsgroup-name>是“*”（例如：<URL:news:*>），那么它表示“所有可用的新聞組”。新聞URL是不同尋常的，因為它們自身不包含足夠的信息來定位一個單一資源，但是它們的位置是任意的。

NNTP

（Network News Transfer Protocol,網路新聞傳輸協定）URL方案是引用新聞文章的另一個方法，這個方案在用來從NNTP伺服器指定新聞文章時是非常有用的（RFC977）。網路新聞傳輸協定URL的形式如下：

nntp://<host>:<port>/<newsgroup-name>/<article-number>

這裡的<host>和<port>在3.1節進行了闡述。如果省略:<port>，那么連線埠預設為119。<newsgroup-name>是組名，<article-number>是新聞組中文章的數字編號。注意nntp:URL指定了文章資源的一個唯一的位置，大多數網際網路上的NNTP伺服器目前進行的配置只允許本地客戶端訪問，因此nntp URL並不代表全球可訪問的資源。這樣URL的news:形式成為標誌新聞文章的首選方法。

TELNET

遠程登錄URL方案被用來指明互動式服務，這種服務可以通過Telnet協定來進行訪問。telnet URL的形式如下：

telnet://<user>:<password>@<host>:<port>/

向3.1節所講的那樣，最後面的“/”字元可以被省略。如果:<port>被省略，那么連線埠預設為23。:<password>也可以被省略，<user>:<password>部分也可以整個被省略。這個URL並不指定一個數據對象，而是指定一個互動式的服務。遠程互動式服務在允許遠程登錄的方法上差別很大。實際上，提供的<user>和<password>僅供參考：正在訪問一個telnet URL的客戶端僅僅建議所暗示的用戶名和密碼的用戶。

WAIS

（Wide Area Information Servers,廣域信息服務系統）WAIS URL 方案用來指示WAIS資料庫，搜尋或者WAIS資料庫中可用的單個文檔。WAIS在中進行了描述。RFC1625[17]對WAIS協定進行了闡述。雖然WAIS協定是基於Z39.50-1988的，但 WAIS URL方案並不是特意用來和任意的Z39.50服務一起使用的。WAIS URL有如下幾個形式：

wais://<host>:<port>/<database>

wais://<host>:<port>/<database>?<search>

wais://<host>:<port>/<database>/<wtype>/<wpath>

這裡的<host>和<port>在3.1節闡述過了。如果省略了:<port>，那么連線埠預設為210。第一種形式指定了一個可以用來搜尋的WAIS伺服器。第二種形式表明了一個特定的搜尋。<database>是被查詢的WAIS資料庫名。第三種形式表明了WAIS數據中的一個要獲取的特定文檔。在這種形式中<wtype>是對象類型的WAIS表示。許多WAIS實現需要一個在取得信息之間就能夠認識對象“類型”的客戶端，這個類型和搜尋回響中的內部對象標誌符一起返回。<wtype>包含在URL中，這是為了讓客戶端能理解URL的足夠信息來取得文檔。WAIS URL的<wpath>由WAIS文檔標誌組成，這個文檔標誌使用了2.2節所敘述的方法進行編碼。WAIS 文檔標誌在處理時應該是不透明的；它僅可以被發布它的伺服器分解。

FILES

檔案URL方案被用來指定那些特定主機上的可訪問的檔案。這個方案和其它大多數方案不一樣，因為它並不表示一個在網際網路上普遍可訪問的資源。檔案URL的形式如下：

file://<host>/<path>

這裡的<host>是系統域名的全稱，在這個系統中<path>是可訪問的，它是形如<directory>/<directory> /.../<name>的層次目錄。例如，一個VMS檔案：DISK$USER:[MY.NOTES]NOTE123456.TXT的形式如下：

<URL:file://vms.host.edu/disk$user/my/notes/note12345.txt>

有一種特殊情況，就是<host>可以是字元串“localhost”或者空字元串；它被解釋為解釋這個URL的主機。

檔案URL方案是與眾不同的，因為它不指定一個網際網路協定或者訪問這些檔案的方法；這樣它在主機間網路協定上的效用是有限的。

PROSPERO

Prospero URL方案是用來指定那些可以通過Prospero目錄服務訪問的資源。Prospero協定在其它地方介紹了。Prospero URL的形式如下：

prospero://<host>:<port>/<hsoname>;<field>=<value>

這裡<host>和<port>和3.1節介紹的一樣。如果省略了:<port>，那么連線埠預設為1525。這裡不需要用戶名和密碼。<hsoname>是Prospero協定中特定主機的對象名稱，它需要被編碼。這個名稱是不透明的，它是由Prospero伺服器解釋。分號“;”是保留字元，它不能不經過引用就出現在<hsoname>中.Prospero URL是通過聯繫特定主機和連線埠上的Prospero目錄伺服器來解釋的，然後用來決定訪問資源的合適的方法，這些資源自身可能被表示成不同的URL。外部的Prospero連結被表示成採用底層訪問方法的URL，而不是表示成Prospero URL。注意斜線“/”可以不經過引用就出現在<hsoname>中，應用程式假定它不代表任何意義。儘管斜線在伺服器上可以用來表示層次結構，但是這些結構並不被承認。注意許多<hsoname>是由斜線開頭，在這種情況下，主機或者連線埠之後將緊跟一個雙斜線：前面是URL語法的斜線，後面是<hsoname>的開始斜線。（舉例來說：<URL:prospero://host.dom//pros/name>表示<hsoname>為“/pros/name”）。另外，與Prospero連結相關聯的任意的欄位和值都可以成為URL中<hsoname>之後的一個部分。在這種情況下，每個“欄位/值”組合對都用一“;”（分號）相互以及與URL的其它部分分隔開。欄位名稱和它的值用一個“=”（等號）分隔開。如果出現這種情況，這些域將用來標誌URL的目標。例如，OBJECT-VERSION域可以被用來標誌對象的特定版本。

新方案註冊

可以通過定義一個到相應URL語法的映射和使用一個新的前綴來引入一個新的方案。URL試驗方案可以通過團體間的共同協定來使用。用字元“x-”開頭的方案名稱是保留給試驗方案用的。國際數字分配權威（IANA，Internet Assigned Numbers Authority）將管理URL方案的註冊。任何提交的新URL方案都必須包含一個訪問該方案中資源的法則的定義還必須包含描述這個方案的語法。URL方案必須具有可論證的實用性和可操作性。提供這樣一個示範的方法就是藉助一個為使用已有協定的客戶端提供新方案中的對象的網關。如果新方案不能夠定位一個數據對象資源，那么這個新領域中的名稱的屬性必須要進行清晰的定義。新方案應該在適當的地方努力遵從與已有方案相同的語法規則。對於可以用URL訪問的協定的地方也是同樣的。客戶端軟體被規定配置成使用特定網關定位符來通過新的命名方案間接訪問。下面的方案已經多次被提議，但這個文檔沒有定義它自己的語法。它建議IANA保留它們的方案名以備將來定義：

afs Andrew 檔案系統全局檔案名稱（Andrew File System global file names）。

mid電子郵件報文標誌（Message identifiers for electronic mail）.

cidMIME主體部分的內容標誌符（ Content identifiers for MIME body

parts）.

nfs 網路檔案系統（NFS）檔案名稱（Network File System file names）.

tn3270互動式3270競爭會話(Interactive 3270 emulation sessions).

mailserver 訪問郵件伺服器上的有效數據（Access to data available from mail

servers）.

z39.50 訪問ANSI Z39.50服務(Access to ANSI Z39.50 services).

BNF

這是統一資源定位器語法的類BNF描述，它使用了RFC822中的約定，除了用“|”表示

選擇，用方括弧[]將可選或者重複的元素括起來之外。簡單地說就是文字用引號""引起

來，可選元素放在方括弧[]內，元素可以用<n>*來開頭表明有n個或者更多個此元素；n

預設為0。

;URL的一般形式如下：

genericurl = scheme ":" schemepart

;特定的預定義方案在這裡進行定義；新方案可以在IANA那兒註冊

url = httpurl | ftpurl | newsurl |

nntpurl | telneturl | gopherurl |

waisurl | mailtourl | fileurl |

prosperourl | otherurl

;新方案遵從一般語法

otherurl = genericurl

;方案都是小寫的；解釋程式應該忽略大小寫

scheme = 1*[ lowalpha | digit | "+" | "-" | "." ]

schemepart = *xchar | ip-schemepart

;基於協定的ip的URL方案部分：

ip-schemepart = "//" login [ "/" urlpath ]

login = [ user [ ":" password ] "@" ] hostport

hostport = host [ ":" port ]

host = hostname | hostnumber

hostname = *[ domainlabel "." ] toplabel

domainlabel = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit

toplabel = alpha | alpha *[ alphadigit | "-" ] alphadigit

alphadigit = alpha | digit

hostnumber = digits "." digits "." digits "." digits

port = digits

user = *[ uchar | ";" | "?" | "&" | "=" ]

password = *[ uchar | ";" | "?" | "&" | "=" ]

urlpath = *xchar ;建立在3.1節的協定基礎上

;預定義方案：

;FTP(檔案傳輸協定，請參考RFC959)

ftpurl = "ftp://" login [ "/" fpath [ ";type=" ftptype ]]

fpath = fsegment *[ "/" fsegment ]

fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]

ftptype = "A" | "I" | "D" | "a" | "i" | "d"

;FILE(檔案)

fileurl = "file://" [ host | "localhost" ] "/" fpath

;HTTP(超文本傳輸協定)

httpurl = "http://" hostport [ "/" hpath [ "?" search ]]

hpath = hsegment *[ "/" hsegment ]

hsegment = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

search = *[ uchar | ";" | ":" | "@" | "&" | "=" ]

;GOPHER(請參考RFC1436)

gopherurl = "gopher://" hostport [ / [ gtype [ selector

[ "%09" search [ "%09" gopher+_string ] ] ] ] ]

gtype = xchar

selector = *xchar

gopher+_string = *xchar

;MAILTO(請參考RFC822)

mailtourl = "mailto:" encoded822addr

encoded822addr = 1*xchar ;在RFC822中進一步定義了

;NEWS（新聞,請參考RFC1036）

newsurl = "news:" grouppart

grouppart = "*" | group | article

group = alpha *[ alpha | digit | "-" | "." | "+" | "_" ]

article = 1*[ uchar | ";" | "/" | "?" | ":" | "&" | "=" ] "@" host

;NNTP（網路新聞傳輸協定,請參考RFC977）

nntpurl = "nntp://" hostport "/" group [ "/" digits ]

;TELNET(遠程登錄協定)

telneturl = "telnet://" login [ "/" ]

;WAIS(廣域信息服務系統，請參考RFC1625)

waisurl = waisdatabase | waisindex | waisdoc

waisdatabase = "wais://" hostport "/" database

waisindex = "wais://" hostport "/" database "?" search

waisdoc = "wais://" hostport "/" database "/" wtype "/" wpath

database = *uchar

wtype = *uchar

wpath = *uchar

;PROSPERO

prosperourl = "prospero://" hostport "/" ppath *[ fieldspec ]

ppath = psegment *[ "/" psegment ]

psegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]

fieldspec = ";" fieldname "=" fieldvalue

fieldname = *[ uchar | "?" | ":" | "@" | "&" ]

fieldvalue = *[ uchar | "?" | ":" | "@" | "&" ]

其他的定義

lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |

"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |

"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |

"y" | "z"

hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |

"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |

"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"

alpha = lowalpha | hialpha

digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |

"8" | "9"

safe = "$" | "-" | "_" | "." | "+"

extra = "!" | "*" | "'" | "(" | ")" | ","

national = "{" | "}" | "|" | "\" | "^" | "~" | "[" | "]" | "`"

punctuation = "<" | ">" | "#" | "%" | <">

reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="

hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |

"a" | "b" | "c" | "d" | "e" | "f"

escape = "%" hex hex

unreserved = alpha | digit | safe | extra

uchar = unreserved | escape

xchar = unreserved | reserved | escape

digits = 1*digit

安全事項

URL方案自身並不會造成安全威脅。用戶需要小心的是：在一個時刻指向一個給定對象的URL並不會保證一直指向這個對象。甚至也不保證因伺服器上對象的移動而會在後來指向另一個不同的對象。一種同URL相關的安全威脅是：構建一個試圖執行像取回對象這樣無害的等冪操作的URL有時可能會導致發生破壞性的遠程操作。這個不安全的URL通常是通過指定一個除了那些保留給正在討論的網路協定用的連線埠數產生的。客戶端在無意間同一個伺服器打了交道，而這個伺服器實際上正在運行一個不同的協定，這樣就導致URL內容中包含的指令被其他的協定解釋了，從而產生意外操作。一個例子就是使用gopher URL來生成一個原始的訊息並通過SMTP伺服器來傳送。在使用那些指定連線埠不是預設連線埠的URL時應該進行警告，尤其是在這個連線埠數出現在保留空間裡面的情況下。當URL包含有嵌入式已編碼的特定協定中的分隔設定（例如，telnet協定的CR和LF字元）並且在傳輸前沒有被解碼時應該引起注意。這樣除了可能被用來模擬一個超出其範圍的操作或者參數，會干擾這個協定，並再一次引起執行意想不到的而且可能是有害的遠程操作。使用包含應該作為秘密的密碼的URL是非常輕率的。