統一資源定位系統

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

統一資源定位系統是專為標識Internet網上資源位置而設置的一種編址方式，平時所説的網頁地址指的即是URL。 統一資源定位符是對可以從互聯網上得到的資源的位置和訪問方法的一種簡潔的表示，是互聯網上標準資源的地址。互聯網上的每個文件都有一個唯一的URL，它包含的信息指出文件的位置以及瀏覽器應該怎麼處理它。 ^[2] 

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

基本URL包含模式（或稱協議）、服務器名稱（或IP地址）、路徑和文件名，如"協議://授權/路徑?查詢"。 完整的、帶有授權部分的普通URL語法看上去如下：協議://用户名:密碼@子域名.域名.頂級域名:端口號/目錄/文件名.文件後綴?參數=值#標誌。 ^[2] 

第一部分 模式/協議：它告訴瀏覽器如何處理將要打開的文件。最常用的協議是超文本傳輸協議（Hypertext Transfer Protocol，縮寫HTTP），這個協議可以用來訪問網絡。

第二部分 務器的名稱或IP地址，後面是到達這個文件的路徑和文件本身的名稱。

URL以斜槓"/"結尾，而沒有給出文件名，在這種情況下，URL引用路徑中最後一個目錄中的默認文件（通常對應於主頁），這個文件常常被稱為index.html或default.html。

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

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

1、絕對URL：URL顯示文件的完整路徑，這意味着絕對URL本身所在的位置與被引用的實際文件的位置無關。 ^[2] 

2、相對URL： 相對URL以包含URL本身的文件夾的位置為參考點，描述目標文件夾的位置。如果目標文件與當前頁面（也就是包含URL的頁面）在同一個目錄，那麼這個文件的相對URL僅僅是文件名和擴展名，如果目標文件在當前目錄的子目錄中，那麼它的相對URL是子目錄名，後面是斜槓，然後是目標文件的文件名和擴展名。 ^[2] 

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

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

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

//<用户名>:<密碼>@<主機>:<端口>/<url路徑>

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

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

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://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>將執行一個不帶參數的“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 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 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 URL方案是用來指明一個個體或者服務的因特網郵件地址的。它只代表因特網郵件地址，而不表示任何其它的附加信息。Mailto URL的形式如下所示：

mailto:<rfc822-addr-spec>

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

新聞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是不同尋常的，因為它們自身不包含足夠的信息來定位一個單一資源，但是它們的位置是任意的。

（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:形式成為標誌新聞文章的首選方法。

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

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

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

（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 文檔標誌在處理時應該是不透明的；它僅可以被髮布它的服務器分解。

文件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 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）.

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).

這是統一資源定位器語法的類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是非常輕率的。