這份備忘錄的情況
本備忘錄詳細說明了一種為因特網團體提供的因特網標準追蹤協議（track protocol），
懇請大家討論并提出寶貴意見。如果你想了解這個協議的情況及標準化狀態，請參考《因
特網正式協議標準（Internet Official Protocol Standards）》（STD 1）的最新版本。
本備忘錄可以自由發布發布，不受任何限制。
摘要
該文檔詳細說明了統一資源定位器、定位的語法和語義以及如何通過因特網來訪問資源。
目錄
1．緒論 2
2．常規URL語法 2
2．1 URL的主要部分 2
2．2 URL字符編碼問題 3
2．3 分層方案和關系鏈接 4
3．特殊方案 4
3．1通用因特網方案語法 4
3．2 FTP 5
3．3 HTTP 7
3．4 GOPHER 7
3．5 MAILTO 9
3．6 NEWS（新聞） 10
3．7 NNTP（Network News Transfer Protocol,網絡新聞傳輸協議） 10
3．8 TELNET 10
3．9 WAIS（Wide Area Information Servers,廣域信息服務系統） 11
3．10 FILES(文件) 11
3．11 PROSPERO 12
4． 新方案的注冊 13
5．特定URL方案的BNF（巴柯斯范式） 13
6．安全事項 16
7．感謝 16
附錄：上下文URL的推薦標準 17
參考文獻： 17
編者地址： 19
1．緒論
因特網上的可用資源可以用簡單字符串來表示，該文檔就是描述了這種字符串的語法和語
義。而這些字符串則被稱為：“統一資源定位器”（URL）。
這篇說明源于萬維網全球信息主動組織（World Wide Web global information
initiative）介紹的概念。RFC1630《通用資源標志符》描述了一些對象數據，他們自1990
年起就開始使用這些對象數據。這篇URL說明符合《因特網資源定位符的功能需求
（Functional Requirements for Internet Resource Locators）》[12]中說明的需求。
這篇文檔是由工程任務組織（IETF）的URI工作小組寫的。如果你有什么建議和意見的
話，你可以給編輯或者URI工作小組< uri@bunyip.com>寫信.這個小組的討論檔案存放
在URL:http://www.acl.lanl.gov/URI/archive/uri-archive.index.html。
2．常規URL語法
正如訪問資源的方法有很多種一樣，對資源進行定位的方案也有好幾種。
URL的一般語法只是為使用協議來建立新方案提供了一個框架，當然除了已經在這篇文檔
中定義過的。
URL通過提供資源位置的一種抽象標志符來對資源進行定位。系統定位了一個資源后，可
能會對它進行各種各樣的操作，這些操作可以抽象為下面的幾個詞：訪問，更新，替換，
發現屬性。一般來說，只有訪問方法這一項在任何URL方案中都需要進行描述。
2．1 URL的主要部分
第五部分給出了URL語法的完整BNF描述。
URL通常被寫成如下形式：
<方案>:<方案描述部分>
一個URL包含了它使用的方案名稱（<方案>）, 其后緊跟一個冒號，然后是一個字符串
（<方案描述部分>），這部分的解釋由所使用的方案來決定。
方案名稱由一串字符組成。小寫字母“a”——“z”，數字，字符加號（“+”），句點（“.”）
和連字號（“-”）都可以。為了方便起見，程序在解釋URL的時候應該視方案名稱中的大
寫字母和小寫字母一樣。（例如：視“HTTP”和“http”一樣）。
2．2 URL字符編碼問題
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的特定部位，只要
它們不用作保留目的，則可進行編碼。
2．3 分層方案和關系鏈接
URL有時候被用來定位那些包含指示器的資源，而這些指示器又指向其他資源。有時候這
些指示器用關系鏈接表示，在關系鏈接中第二資源的位置表示符原則上“和那些除了帶有
次相關路徑的表示符相同”。在這篇文檔中沒有對關系鏈接進行描述。但是，關系鏈接的
使用依賴于包含分層結構的原始URL，它是關系鏈接的基礎。
有些URL方案（例如ftp，http，和文件方案）包含的名字可以被認為是分層次的；這些
層次之間用“/”分隔。
3．特殊方案
一些已經存在的標準協議和正處于試驗中的協議之間的映射關系的輪廓用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目錄服務)
在以后的說明書中可能會對其他一些方案加以描述。這篇文檔的第四部分介紹了如何注冊
新的方案，并且列出了一些正在研究中的方案名。
3．1通用因特網方案語法
雖然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－路徑的語法依賴于所使用的方案。也依賴于它在方案中的解釋方法。
3．2 FTP
FTP URL方案可以用來指定因特網上使用FTP協議（RFC959）的可達主機上的文件和目錄。
FTP URL遵從3.1節所描述的語法。如果:<端口>被省略的話，則使用缺省端口21。
3．2．1 FTP 用戶名和密碼
在連接上FTP服務器后，可以用“USER”和“PASS”命令來指定用戶名和密碼。如果沒
有提供用戶名或者密碼并且FTP服務器只要求一項，那么將使用到“匿名”服務器的轉
換，如下所示：
用戶名“anonymous”被發送。
訪問資源的終端用戶的因特網電子郵件地址被作為密碼發送。
如果URL提供用戶名但不提供密碼，那么遠程服務器將要求提供密碼，而解釋FTP URL
的程序則要求用戶輸入密碼。
3．2．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://myname@host.dom/%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://myname@host.dom//etc/motd>將執行一個不帶參數
的“CWD”命令，然后執行“CWD etc”，接著執行“RETR moth”。
FTP URL也可以用于其他操作；例如，可以更新遠程文件服務器上的文件，或者根據它的
目錄列表來推斷它的一些信息。完成這些功能的機制在這兒沒有仔細介紹。
3．2．3 FTP 類型編碼是可選擇的
FTP URL的整個;type=<typecode>部分都是可選擇的。如果這一部分被省略，那么解釋
URL的客戶程序必須猜測適當模式來使用。一般來說，文件數據內容的類型只能從文件名
來猜測，例如根據文件名后綴猜測；用來傳輸文件的合適的類型編碼于是可以從文件的數
據內容推斷出來。
3．2．4層次
在有些文件系統中，用來表示URL的層次結構的“/”與用來構建文件系統層次的分隔符
相同，這樣一來，文件名和URL路徑看起來就很像。但這并不意味著URL是一個Unix文
件名。
3．2．5優化
客戶端通過FTP對資源進行訪問時可能會使用一些額外的搜索方法來優化交互過程。例
如，對一些FTP服務器來說，當訪問同一個服務器的多個URL的時候，則保持控制連接
一直打開是比較合理的。但FTP協議沒有通用的層次模式，因此當一個改變目錄的命令
發出后，如果是一個不同的路徑，那么一般不可能推斷出下一次將要給另一個目錄發送什
么樣的序列。唯一可靠的算法是斷開然后重新建立控制連接。
3．3 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
中用來表示層次結構。
3．4 GOPHER
Gopher URL方案用來標志因特網上使用Gopher協議的可達資源。
基本Gopher協議是在RFC1436中介紹的，它支持項和項（目錄）集合。Gopher+ 協議則
在基本Gopher協議的基礎上進行了擴展，并且向上兼容。[2]中對它進行了介紹。Gopher+
支持聯合屬性的任意集合和使用Gopher項的替換數據表示。Gopher URL提供了Gopher
與Gopher+的項和項屬性。
3．4．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服務器的高層目錄的。
3．4．2為Gopher搜索引擎指定URL
如果URL被提交到Gopher搜索引擎進行查詢，那么選擇器后將緊跟一個已編碼的tab
（%09）和一個搜索字符串。Gopher客戶為了向Gopher搜索服務器提交一個搜索必須向
Gopher服務器發送<selector>字符串（編碼后），一個tab字符，和一個搜索字符串。
3．4．3Gopher+項的URL語法
Gopher+項的URL有一個已編碼的tab字符（%09）和一個Gopher+字符串。注意盡管
<search>元素可以是空字符串，但在這種情況下必須提供%09<search>字符串。
<gopher+_string>被用來表示取得Gopher+項所需要的信息。Gopher+項可以擁有交替視
圖，任意的屬性系，也可以有與它們相關聯的電子表格。
客戶為了獲得與Gopher+URL相關聯的數據，必須連接到服務器并且發送Gopher選擇器，
這個選擇器的后面緊跟一個tab字符和搜索字符串（可以為空）然后是一個tab字符和
Gopher+命令。
3．4．4 缺省的Gopher+數據表示
當一個Gopher服務器向客戶返回目錄列表時，Gopher+項后面跟著一個“+”（表示
Gopher+項）或者一個“?”（表示具有與它們相關聯的+ASK形式的Gopher+項）。Gopher+
字符串只有一個字符“+”的Gopher URL采用項的缺省的視圖（數據表示），而Gopher+
字符串只有一個字符“?”的Gopher URL則采用具有相關聯的Gopher電子表格的項。
3．4．5 具有電子表格的Gopher+項
具有與之相關聯的+ASK的Gopher+項（也就是跟著一個“?”的Gopher+項）要求客戶端
取得該項的+ASK屬性來獲得表格定義，然后讓用戶填寫這個表格并將用戶應答和獲得項
的選擇器字符串一起返回。Gopher+客戶端知道如何完成這些工作，但需要依賴于Gopher+
項描述中的“？”標簽來知道什么時候處理這種情況。Gopher+項中的“?”被用來與Gopher+
協議中這種符號的用法相兼容。
3．4．6 Gopher+項屬性集
為了表示項的Gopher+屬性，Gopher URL的Gopher+字符串由“!”或者“$”組成。“!”
涉及Gopher+項的所有屬性。“$”則涉及Gopher目錄中所有項的所有項屬性。
3．4．7涉及特定的Gopher+屬性
為了表示特殊的屬性，URL的gopher+_string是“!<attribute_name>”或者
“$<attribute_name>”。例如，gopher+_string的值為“!+ABSTRACT” 表示屬性包含
一個項的抽象。
為了表示幾個屬性，gopher+_string可以由幾個屬性名組成，并且用已編碼的空格分隔
開。例如，“!+ABSTRACT%20+SMELL”代表一個項的+ABSTRACT和+SMELL屬性。
3．4．8 Gopher+交替視圖的URL語法
Gopher+允許項有優化的交替數據表示(交替視圖)。Gopher+客戶端發送適當的視圖和語
言標志（出現在項的+VIEW屬性里）來獲得Gopher+的交替視圖。為了引用一個特定的
Gopher+交替視圖試圖，URL的Gopher+字符串的形式必須如下所示：
+<視圖名稱>%20<語言名稱>
例如，Gopher+字符串"+application/postscript%20Es_ES"引用了一個Gopher+項的交
替視圖的西班牙語附注。
3．4．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>
3．5 MAILTO
mailto URL方案是用來指明一個個體或者服務的因特網郵件地址的。它只代表因特網郵
件地址，而不表示任何其它的附加信息。
Mailto URL的形式如下所示：
mailto:<rfc822-addr-spec>
這里的<rfc822-addr-spec>是地址說明（的編碼），這在RFC822[6]中進行了詳細的說明。
在mailto URL中沒有保留字。
注意百分符號（"%"）在RFC822中用得比較普遍，它必須被編碼。
不像許多URL，mailto方案不代表可直接訪問的數據對象；也沒有跡象表面它代表一個
對象。它的使用方法不同于MIME中的報文/外部實體類型。
3．6 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是不同尋常的，因為它們自身不包含足夠的信息來定位一個單一資源，但是它
們的位置是任意的。
3．7 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:形式成為標志新聞文章的首選方法。
3．8 TELNET
遠程登錄URL方案被用來指明交互式服務，這種服務可以通過Telnet協議來進行訪問。
telnet URL的形式如下：
telnet://<user>:<password>@<host>:<port>/
向3.1節所講的那樣，最后面的“/”字符可以被省略。如果:<port>被省略，那么端口
缺省為23。:<password>也可以被省略，<user>:<password>部分也可以整個被省略。
這個URL并不指定一個數據對象，而是指定一個交互式的服務。遠程交互式服務在允許
遠程登錄的方法上差別很大。實際上，提供的<user>和<password>僅供參考：正在訪問
一個telnet URL的客戶端僅僅建議所暗示的用戶名和密碼的用戶。
3．9 WAIS（Wide Area Information Servers,廣域信息服
務系統）
WAIS URL 方案用來指示WAIS數據庫，搜索或者WAIS數據庫中可用的單個文檔。WAIS
在[7]中進行了描述。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 文檔標志在處理時應該是不透明的；它僅可以被發布它的服務器分解。
3．10 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方案是與眾不同的，因為它不指定一個因特網協議或者訪問這些文件的方法；
這樣它在主機間網絡協議上的效用是有限的。
3．11 PROSPERO
Prospero URL方案是用來指定那些可以通過Prospero目錄服務訪問的資源。Prospero
協議在其它地方介紹了[14]。
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域可以被用來標志對象的特定版
本。
4． 新方案的注冊
可以通過定義一個到相應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）.
cid MIME主體部分的內容標志符（ 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).
5．特定URL方案的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 = "http://" 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
6．安全事項
URL方案自身并不會造成安全威脅。用戶需要小心的是：在一個時刻指向一個給定對象的
URL并不會保證一直指向這個對象。甚至也不保證因服務器上對象的移動而會在后來指向
另一個不同的對象。
一種同URL相關的安全威脅是：構建一個試圖執行像取回對象這樣無害的等冪操作的URL
有時可能會導致發生破壞性的遠程操作。這個不安全的URL通常是通過指定一個除了那
些保留給正在討論的網絡協議用的端口數產生的。客戶端在無意間同一個服務器打了交
道，而這個服務器實際上正在運行一個不同的協議，這樣就導致URL內容中包含的指令
被其他的協議解釋了，從而產生意外操作。一個例子就是使用gopher URL來生成一個原
始的消息并通過SMTP服務器來發送。在使用那些指定端口不是缺省端口的URL時應該進
行警告，尤其是在這個端口數出現在保留空間里面的情況下。
當URL包含有嵌入式已編碼的特定協議中的分隔符（例如，telnet協議的CR和LF字符）
并且在傳輸前沒有被解碼時應該引起注意。這樣除了可能被用來模擬一個超出其范圍的操
作或者參數，會干擾這個協議，并再一次引起執行意想不到的而且可能是有害的遠程操作。
使用包含應該作為秘密的密碼的URL是非常輕率的。
7．感謝
這份文件建立在基本WWW設計（RFC1630）和許多人在網絡上對這個觀點進行的諸多討論
的基礎上。這些討論受到了Clifford Lynch，Brewster Kahle [10] 和 Wengyik Yeong
[18]的文章的極大鼓舞。這份文件綜合了John Curran, Clifford Neuman, Ed Vielmetti
和后來的IETF URL BOF與URI工作小組的成果。
Dan Connolly, Ned Freed, Roy Fielding, Guido van Rossum, Michael Dolan, Bert
Bos, John Kunze, Olle Jarnefors, Peter Svanberg最近詳細審閱了這份文件并提出
了寶貴的意見。還有許多人為這份RFC的完善提供了很大幫助。
附錄：上下文URL的推薦標準
URI（統一資源標志符），包括URL，趨向于通過這樣的協議來傳輸：這些協議為它們的解
釋提供了上下文。
在有些情況下，有必要區分URL和語法結構中其他可能的數據結構。在這種情況下，建
議在URL之前加上一個有字符“URL:”組成的前綴，這個前綴可以用來把URL和其它種
類的URI區分開。
此外，其它種類的文字中包含URL的情況也很常見。例如包含在電子郵件中，USENET 新
聞消息中或者印在紙上。在這些情況下，可以很方便的用一個單獨的語法分隔符號來分隔
URL并把它和文字的其它部分相分離。在一些特殊情況下，標點符號標記可能會造成URL
的其它部分出錯。因為這個原因，建議使用尖括號（“<”和“>”）并使用“URL:”前綴
來界定URL。這些界定符號不會出現在URL中，也不應該出現在指定這個界定符的上下文
中。
在一個“片斷/錨點”（fragment/anchor）標志符和一個URL（在一個“#”之后）相關聯
的情況下，這個標志符也應該放到括號中。
在有些情況下，需要加一些額外的空白（空格，回車，制表符等）來打斷那些超過一行的
長URL。在提取URL時這些空白應該被忽略。
在連字符（“-”）后不應該加入空白。因為有些排字機和打印機在打斷一行是可能會（錯
誤地）在行末加入一個連字符，解釋程序在解釋一個在連字符后包含一個行中斷的URL
時應該忽略行中斷左右所有未編碼的空白,并且應該注意到連字符可能是也可能不是URL
的一個部分。
例如：
是的，Jim，我發現它在<URL:ftp://info.cern.ch/pub/www/doc;type=d>上，但是你可
能能夠從<URL:ftp://ds.internic.net/rfc>那兒獲得它。請注意
<URL:http://ds.internic.net/instructions/overview.html#WARNING>上的警告。
參考文獻：
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol
(a distributed document search and retrieval protocol)",
RFC 1436, University of Minnesota, March 1993.
<URL:ftp://ds.internic.net/rfc/rfc1436.txt;type=a>
[2] Anklesaria, F., Lindner, P., McCahill, M., Torrey, D.,
Johnson, D., and B. Alberti, "Gopher+: Upward compatible
enhancements to the Internet Gopher protocol",
University of Minnesota, July 1993.
<URL:ftp://boombox.micro.umn.edu/pub/gopher/gopher_protocol
/Gopher+/Gopher+.txt>
[3] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web", RFC
1630, CERN, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1630.txt>
[4] Berners-Lee, T., "Hypertext Transfer Protocol (HTTP)",
CERN, November 1993.
<URL:ftp://info.cern.ch/pub/www/doc/http-spec.txt.Z>
[5] Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, IETF, October 1989.
<URL:ftp://ds.internic.net/rfc/rfc1123.txt>
[6] Crocker, D. "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, April 1982.
<URL:ftp://ds.internic.net/rfc/rfc822.txt>
[7] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
Functional Specification", (v1.5), Thinking Machines
Corporation, April 1990.
<URL:ftp://quake.think.com/pub/wais/doc/protspec.txt>
[8] Horton, M. and R. Adams, "Standard For Interchange of USENET
Messages", RFC 1036, AT&T Bell Laboratories, Center for Seismic
Studies, December 1987.
<URL:ftp://ds.internic.net/rfc/rfc1036.txt>
[9] Huitema, C., "Naming: Strategies and Techniques", Computer
Networks and ISDN Systems 23 (1991) 107-110.
[10] Kahle, B., "Document Identifiers, or International Standard
Book Numbers for the Electronic Age", 1991.
<URL:ftp://quake.think.com/pub/wais/doc/doc-ids.txt>
[11] Kantor, B. and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego & UC Berkeley, February 1986.
<URL:ftp://ds.internic.net/rfc/rfc977.txt>
[12] Kunze, J., "Functional Requirements for Internet Resource
Locators", Work in Progress, December 1994.
<URL:ftp://ds.internic.net/internet-drafts
/draft-ietf-uri-irl-fun-req-02.txt>
[13] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, USC/Information Sciences Institute,
November 1987.
<URL:ftp://ds.internic.net/rfc/rfc1034.txt>
[14] Neuman, B., and S. Augart, "The Prospero Protocol",
USC/Information Sciences Institute, June 1993.
<URL:ftp://prospero.isi.edu/pub/prospero/doc
/prospero-protocol.PS.Z>
[15] Postel, J. and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/Information Sciences Institute,
October 1985.
<URL:ftp://ds.internic.net/rfc/rfc959.txt>
[16] Sollins, K. and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1737.txt>
[17] St. Pierre, M, Fullton, J., Gamiel, K., Goldman, J., Kahle, B.,
Kunze, J., Morris, H., and F. Schiettecatte, "WAIS over
Z39.50-1988", RFC 1625, WAIS, Inc., CNIDR, Thinking Machines
Corp., UC Berkeley, FS Consulting, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1625.txt>
[18] Yeong, W. "Towards Networked Information Retrieval", Technical
report 91-06-25-01, Performance Systems International, Inc.
<URL:ftp://uu.psi.com/wp/nir.txt>, June 1991.
[19] Yeong, W., "Representing Public Archives in the Directory",
Work in Progress, November 1991.
[20] "Coded Character Set -- 7-bit American Standard Code for
Information Interchange", ANSI X3.4-1986.
編者地址：
Tim Berners-Lee
World-Wide Web project
CERN,
1211 Geneva 23,
Switzerland
電話：+41 (22)767 3755
傳真：+41 (22)767 7155
Email：timbl@info.cern.ch
Larry Masinter
Xerox PARC
3333 Coyote Hill Road
Palo Alto, CA 94034
電話: (415) 812-4365
傳真: (415) 812-4333
EMail: masinter@parc.xerox.com
Mark McCahill
Computer and Information Services,
University of Minnesota
Room 152 Shepherd Labs
100 Union Street SE
Minneapolis, MN 55455
電話: (612) 625 1300
EMail: mpm@boombox.micro.umn.edu
RFC1738——Uniform Resource Locators (URL) 統一資源定位器（URL）
1
RFC文檔中文翻譯計劃