[[396149]]

本文針對URL（Uniform Resource Locator）簡單介紹URL的結構和URL的編碼與解碼等問題。為什么需要對 URL 進行編碼，對其編碼的好處體現在哪里？首先，URL是統一資源標識，通常所說的URL只是URI的一部分。典型的URL的格式如圖1所示。

圖1  URL格式

而下面所提到的URL編碼，實際也應該指的是URI編碼。

需要進行編碼的部分通常來說是不方便傳輸或會造成歧義的。原因還有很多，對于URL來說，需要編碼是因為 URL 中的某些字符會造成歧義。例如，在傳輸的過程中，通常會使用鍵值對的方式，username=12345；這種方式對于人而言很好理解，這是一個賦值的過程，而接收URL的服務器卻不知道“=”這個字符是字符串數據的一部分還是賦值的需要，所以這里的字符在傳輸過程中是需要進行編碼的。

又例如，URL的編碼格式采用的是ASCII碼，而不是Unicode，這也就是說URL中不能包含任何非ASCII字符，如中文。否則，如果客戶端瀏覽器和服務端瀏覽器支持的字符集不同，中文可能會造成問題。

所以，URL編碼的原則是使用安全字符去表示那些不安全的字符，如百分號編碼。

1. 百分號編碼

在介紹百分號編碼前，還要了解URL需要對哪些字符進行編碼。

RFC3986文檔規定，URL中只允許包含英文字母（a～z、A～Z）、數字（0～9）、“-”“_”“.”“～” 4個特殊字符以及所有保留字符。

所謂的保留字符就是劃分URL的，分隔不同組件的字符。

RFC3986中指定了以下字符為保留字符，如圖2所示。

圖2  RFC3986保留字符

百分號編碼的編碼方式非常簡單，使用百分號（%）加上兩個字符（0123456789ABCDEF），表示為一個字節的十六進制的形式。URL編碼默認使用的字符集是ASCII碼。例如，井號（#）對應的十六進制是0x23，所以它的URL編碼就為%23。對于非ASCII字符，需要使用ASCII字符集的超集進行編碼得到相應的字節，然后對每個字節執行百分號編碼。

2. URL解析

在傳輸前，瀏覽器會對 URL 進行編碼。接收 URL 的服務器主要負責對接收到的 URL進行解析。URL的使用過程當中，由于互聯網上的每個網頁大多會引用與它同服務器甚至是同級目錄下的文件，就會使用到相對URL的概念。在介紹URL編碼時，展示的是絕對URL，這就相當于電腦中的相對路徑與絕對路徑的區別。所以在解析的時候，服務器需要區分相對URL與絕對URL。

按照規范里的說法，要區分兩者非常簡單。如果 URL 字符串不是一個有效的協議名，后面跟的不是冒號（:）或雙斜杠（//），那么它就是一個需要被引用的相對 URL。其實在實際應用中，對于相對 URL 的解析是有規范的，因為不同瀏覽器的具體實現千差萬別，有效協議名稱的字符集也各有不同，還有各種替代雙斜杠（//）分隔符的方法，因此，接下來會對相對URL的解析進行一個歸類。

（1）有協議名稱，但沒有授權信息（http:abc.txt）。這是一個比較有名的漏洞，它的產生是由RFC3986規范疏忽所致。在規范中將這些地址描述為無效的絕對地址，但在提供的解析算法中又將這種地址的解析搞錯了。所以這種形式的URL，在執行過程中會被理解為相對地址來進行處理。例如，在某些情況下，http:abc.txt會被理解為相對地址，而https:example.com會被解釋為絕對地址。

（2）沒有協議名，但有授權信息（//example.com）。這種寫法在規范中給出了較為完整的處理。面對這種URL，瀏覽器會自動補全該URL。

（3）沒有協議名，沒有授權信息，但有路徑（../robots.txt）。這是一種比較常見的用法，協議和授權信息都從引用URL里復制過來，然后將這個相對地址進行補全。

（4）沒有協議名，沒有授權信息，沒有路徑，但有查詢的字符串（?username=abc）。在這種情況下，協議、授權信息、路徑全都會原封不動地從原引用 URL 復制過來。查詢字符串和字段ID則來自于相對URL。

（5）只有片段 ID（#bunnies）。這種方式也是如此，其他部分全部原封不動地從原引用URL復制，只替換字段ID的部分。