統一資源定位系統

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

正如訪問資源的方法有很多種一樣，對資源進行定位的方案也有好幾種。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－路徑的語法依賴於所使用的方案。也依賴於它在方案中的解釋方法。

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

1、FTP用戶名和密碼

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

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

這裡的到和（可能被編碼）都是字元串，是字元“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協議沒有通用的層次模式，因此當一個改變目錄的命令發出后，如果是一個不同的路徑，那麼一般不可能推斷出下一次將要給另一個目錄發送什麼樣的序列。唯一可靠的演演算法是斷開然後重新建立控制連接。

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

http://:/?

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

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

1、GopherURL語法

GopherURL的形式如下：

gopher://:/

這裡的是%09%09%09之一。

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

2、為Gopher搜索引擎指定URL

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

3、Gopher+項的URL語法

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

4、預設的Gopher+數據表示

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

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

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

6、Gopher+項屬性集

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

7、涉及特定的Gopher+屬性

為了表示特殊的屬性，URL的gopher+_string是“!”或者“$”。例如，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%0D%0A%0D%0A.%0D%0A

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

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

mailto:

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

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

news:

news:

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

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

nntp://://

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

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

telnet://:@:/

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

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

wais://:/

wais://:/?

wais://:///

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

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

file:///

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

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

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

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

prospero://:/;=

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

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

afsAndrew文件系統全局文件名（AndrewFileSystemglobalfilenames）。

mid電子郵件報文標誌（Messageidentifiersforelectronicmail）.

cidMIME主體部分的內容標誌符（ContentidentifiersforMIMEbody

parts）.

nfs網路文件系統（NFS）文件名（NetworkFileSystemfilenames）.

tn3270互動式3270競爭會話(Interactive3270emulationsessions).

mailserver訪問郵件伺服器上的有效數據（Accesstodataavailablefrommail

servers）.

z39.50訪問ANSIZ39.50服務(AccesstoANSIZ39.50services).

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

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

來，可選元素放在方括弧[]內，元素可以用*來開頭表明有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="%"hexhex

unreserved=alpha|digit|safe|extra

uchar=unreserved|escape

xchar=unreserved|reserved|escape

digits=1*digit

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