為什麼要進行URL編碼

作者：降瑞雪，
原文鏈接：http://cnblogs.com/jerrysion/p/5522673.html

我們都知道Http協議中參數的傳輸是"key=value"這種簡直對形式的，如果要傳多個參數就需要用「&」符號對鍵值對進行分割。

如"?name1=value1&name2=value2"，這樣在服務端在收到這種字元串的時候，會用「&」分割出每一個參數，然後再用「=」來分割出參數值。

針對「name1=value1&name2=value2」我們來說一下客戶端到服務端的概念上解析過程:

上述字元串在計算機中用ASCII嗎表示為：

6E616D6531 3D 76616C756531 26 6E616D6532 3D 76616C756532。 6E616D6531：name1 3D：= 76616C756531：value1 26：& 6E616D6532：name2 3D：= 76616C756532：value2

服務端在接收到該數據後就可以遍歷該位元組流，首先一個位元組一個位元組的喫，當喫到3D這位元組後，服務端就知道前面喫得位元組表示一個key，再想後喫，如果遇到26，說明從剛才喫的3D到26子節之間的是上一個key的value，以此類推就可以解析出客戶端傳過來的參數。

現在有這樣一個問題，如果我的參數值中就包含=或&這種特殊字元的時候該怎麼辦？

比如說「name1=value1」,其中value1的值是「va&lu=e1」字元串，那麼實際在傳輸過程中就會變成這樣「name1=va&lu=e1」。我們的本意是就只有一個鍵值對，但是服務端會解析成兩個鍵值對，這樣就產生了奇異。

如何解決上述問題帶來的歧義呢？解決的辦法就是對參數進行URL編碼 URL編碼只是簡單的在特殊字元的各個位元組前加上%，例如，我們對上述會產生奇異的字元進行URL編碼後結果：「name1=va%26lu%3D」，這樣服務端會把緊跟在「%」後的位元組當成普通的位元組，就是不會把它當成各個參數或鍵值對的分隔符。另外一個問題，就是為什麼我們要用ASCII傳輸，可不可以用別的編碼？ 當然可以用別的編碼，你自己可以開發一套編碼，然後自己解析。就像大部分國家都有自己的語言一樣。那國家之間要交流，怎麼辦？用英語把，英語的使用範圍最廣。

通常如果一樣東西需要編碼，說明這樣東西並不適合傳輸。原因多種多樣，如Size過大，包含隱私數據，對於Url來說，之所以要進行編碼，是因為Url中有些字元會引起歧義。

例如，Url參數字元串中使用key=value鍵值對這樣的形式來傳參，鍵值對之間以&符號分隔，如/s?q=abc&ie=utf-8。如果你的value字元串中包含了=或者&，那麼勢必會造成接收Url的伺服器解析錯誤，因此必須將引起歧義的&和=符號進行轉義，也就是對其進行編碼。

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

Url編碼的原則就是使用安全的字元（沒有特殊用途或者特殊意義的可列印字元）去表示那些不安全的字元。

預備知識：URI是統一資源標識的意思，通常我們所說的URL只是URI的一種。典型URL的格式如下所示。下面提到的URL編碼，實際上應該指的是URI編碼。

foo://http://example.com:8042/over/there?name=ferret#nose
\_/ \______________/ \________/\_________/ \__/ | | | | | scheme authority path query fragment

哪些字元需要編碼

RFC3986文檔規定，Url中只允許包含英文字母（a-zA-Z）、數字（0-9）、-_.~4個特殊字元以及所有保留字元。RFC3986文檔對Url的編解碼問題做出了詳細的建議，指出了哪些字元需要被編碼纔不會引起Url語義的轉變，以及對為什麼這些字元需要編碼做出了相應的解釋。

US-ASCII字符集中沒有對應的可列印字元：Url中只允許使用可列印字元。US-ASCII碼中的10-7F位元組全都表示控制字元，這些字元都不能直接出現在Url中。同時，對於80-FF位元組（ISO-8859-1），由於已經超出了US-ACII定義的位元組範圍，因此也不可以放在Url中。

保留字元：Url可以劃分成若干個組件，協議、主機、路徑等。有一些字元（:/?#[]@）是用作分隔不同組件的。例如：冒號用於分隔協議和主機，/用於分隔主機和路徑，?用於分隔路徑和查詢參數，等等。

還有一些字元（!$&()*+,;=）用於在每個組件中起到分隔作用的，如=用於表示查詢參數中的鍵值對，&符號用於分隔查詢多個鍵值對。當組件中的普通數據包含這些特殊字元時，需要對其進行編碼。

RFC3986中指定了以下字元為保留字元：! * ( ) ; : @ & = + $ , / ? # [ ]

不安全字元：還有一些字元，當他們直接放在Url中的時候，可能會引起解析程序的歧義。這些字元被視為不安全字元，原因有很多。

空格：Url在傳輸的過程，或者用戶在排版的過程，或者文本處理程序在處理Url的過程，都有可能引入無關緊要的空格，或者將那些有意義的空格給去掉。
引號以及<>：引號和尖括弧通常用於在普通文本中起到分隔Url的作用
#：通常用於表示書籤或者錨點
%：百分號本身用作對不安全字元進行編碼時使用的特殊字元，因此本身需要編碼
{}|^[]`~：某一些網關或者傳輸代理會篡改這些字元

需要注意的是，對於Url中的合法字元，編碼和不編碼是等價的，但是對於上面提到的這些字元，如果不經過編碼，那麼它們有可能會造成Url語義的不同。因此對於Url而言，只有普通英文字元和數字，特殊字元$-_.+!*()還有保留字元，才能出現在未經編碼的Url之中。其他字元均需要經過編碼之後才能出現在Url中。

但是由於歷史原因，目前尚存在一些不標準的編碼實現。例如對於~符號，雖然RFC3986文檔規定，對於波浪符號~，不需要進行Url編碼，但是還是有很多老的網關或者傳輸代理會進行編碼。

如何對Url中的非法字元進行編碼

Url編碼通常也被稱為百分號編碼（Url Encoding，also known as percent-encoding），是因為它的編碼方式非常簡單，使用%百分號加上兩位的字元——0123456789ABCDEF——代表一個位元組的十六進位形式。

Url編碼默認使用的字符集是US-ASCII。例如a在US-ASCII碼中對應的位元組是0x61，那麼Url編碼之後得到的就是%61，我們在地址欄上輸入http://g.cn/search?q=%61%62%63，實際上就等同於在google上搜索abc了。又如@符號在ASCII字符集中對應的位元組為0x40，經過Url編碼之後得到的是%40。

對於非ASCII字元，需要使用ASCII字符集的超集進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。對於Unicode字元，RFC文檔建議使用utf-8對其進行編碼得到相應的位元組，然後對每個位元組執行百分號編碼。如"中文"使用UTF-8字符集得到的位元組為0xE4 0xB8 0xAD 0xE6 0x96 0x87，經過Url編碼之後得到"%E4%B8%AD%E6%96%87"。

如果某個位元組對應著ASCII字符集中的某個非保留字元，則此位元組無需使用百分號表示。例如"Url編碼"，使用UTF-8編碼得到的位元組是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81，由於前三個位元組對應著ASCII中的非保留字元"Url"，因此這三個位元組可以用非保留字元"Url"表示。最終的Url編碼可以簡化成"Url%E7%BC%96%E7%A0%81" ，當然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81"也是可以的。

由於歷史的原因，有一些Url編碼實現並不完全遵循這樣的原則，下面會提到。

Javascript中的escape, encodeURI和encodeURIComponent的區別

JavaScript中提供了3對函數用來對Url編碼以得到合法的Url，它們分別是escape / unescape, encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由於解碼和編碼的過程是可逆的，因此這裡只解釋編碼的過程。

這三個編碼的函數——escape，encodeURI，encodeURIComponent——都是用於將不安全不合法的Url字元轉換為合法的Url字元表示，它們有以下幾個不同點。

安全字元不同：

下面列出了這三個函數的安全字元（即函數不會對這些字元進行編碼）

escape（69個）：*/@+-._0-9a-zA-Z
encodeURI（82個）：!#$&()*+,/:;=?@-._~0-9a-zA-Z
encodeURIComponent（71個）：!()*-._~0-9a-zA-Z

兼容性不同：

escape函數是從Javascript 1.0的時候就存在了，其他兩個函數是在Javascript 1.5才引入的。但是由於Javascript 1.5已經非常普及了，所以實際上使用encodeURI和encodeURIComponent並不會有什麼兼容性問題。

對Unicode字元的編碼方式不同：

這三個函數對於ASCII字元的編碼方式相同，均是使用百分號+兩位十六進位字元來表示。但是對於Unicode字元，escape的編碼方式是%uxxxx，其中的xxxx是用來表示unicode字元的4位十六進位字元。

這種方式已經被W3C廢棄了。但是在ECMA-262標準中仍然保留著escape的這種編碼語法。encodeURI和encodeURIComponent則使用UTF-8對非ASCII字元進行編碼，然後再進行百分號編碼。這是RFC推薦的。因此建議儘可能的使用這兩個函數替代escape進行編碼。

適用場合不同：encodeURI被用作對一個完整的URI進行編碼，而encodeURIComponent被用作對URI的一個組件進行編碼。從上面提到的安全字元範圍表格來看，我們會發現，encodeURIComponent編碼的字元範圍要比encodeURI的大。

我們上面提到過，保留字元一般是用來分隔URI組件（一個URI可以被切割成多個組件，參考預備知識一節）或者子組件（如URI中查詢參數的分隔符），如：號用於分隔scheme和主機，?號用於分隔主機和路徑。由於encodeURI操縱的對象是一個完整的的URI，這些字元在URI中本來就有特殊用途，因此這些保留字元不會被encodeURI編碼，否則意義就變了。

組件內部有自己的數據表示格式，但是這些數據內部不能包含有分隔組件的保留字元，否則就會導致整個URI中組件的分隔混亂。因此對於單個組件使用encodeURIComponent，需要編碼的字元就更多了。

表單提交

當Html的表單被提交時，每個表單域都會被Url編碼之後纔在被發送。由於歷史的原因，表單使用的Url編碼實現並不符合最新的標準。

例如對於空格使用的編碼並不是%20，而是+號，如果表單使用的是Post方法提交的，我們可以在HTTP頭中看到有一個Content-Type的header，值為application/x-www-form-urlencoded。

大部分應用程序均能處理這種非標準實現的Url編碼，但是在客戶端Javascript中，並沒有一個函數能夠將+號解碼成空格，只能自己寫轉換函數。還有，對於非ASCII字元，使用的編碼字符集取決於當前文檔使用的字符集。例如我們在Html頭部加上

<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />

這樣瀏覽器就會使用gb2312去渲染此文檔（注意，當HTML文檔中沒有設置此meta標籤，則瀏覽器會根據當前用戶喜好去自動選擇字符集，用戶也可以強制當前網站使用某個指定的字符集）。當提交表單時，Url編碼使用的字符集就是gb2312。

之前在使用Aptana（為什麼專指aptana下面會提到）遇到一個很迷惑的問題，就是在使用encodeURI的時候，發現它編碼得到的結果和我想的很不一樣。下面是我的示例代碼：

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="Content-Type" content="text/html; charset=gb2312" /> </head> <body> <script type="text/javascript"> document.write(encodeURI("中文")); </script> </body> </html>

運行結果輸出%E6%B6%93%EE%85%9F%E6%9E%83。顯然這並不是使用UTF-8字符集進行Url編碼得到的結果（在Google上搜索"中文"，Url中顯示的是%E4%B8%AD%E6%96%87）。

所以我當時就很質疑，難道encodeURI還跟頁面編碼有關，但是我發現，正常情況下，如果你使用gb2312進行Url編碼也不會得到這個結果的纔是。後來終於被我發現，原來是頁面文件存儲使用的字符集和Meta標籤中指定的字符集不一致導致的問題。

Aptana的編輯器默認情況下使用UTF-8字符集。也就是說這個文件實際存儲的時候使用的是UTF-8字符集。但是由於Meta標籤中指定了gb2312，這個時候，瀏覽器就會按照gb2312去解析這個文檔，那麼自然在"中文"這個字元串這裡就會出錯，因為"中文"字元串用UTF-8編碼過後得到的位元組是0xE4 0xB8 0xAD 0xE6 0x96 0x87，這6個位元組又被瀏覽器拿gb2312去解碼，那麼就會得到另外三個漢字"涓枃"（GBK中一個漢字佔兩個位元組），這三個漢字在傳入encodeURI函數之後得到的結果就是%E6%B6%93%EE%85%9F%E6%9E%83。因此，encodeURI使用的還是UTF-8，並不會受到頁面字符集的影響。

對於包含中文的Url的處理問題，不同瀏覽器有不同的表現。例如對於IE，如果你勾選了高級設置"總是以UTF-8發送Url"，那麼Url中的路徑部分的中文會使用UTF-8進行Url編碼之後發送給服務端，而查詢參數中的中文部分使用系統默認字符集進行Url編碼。為了保證最大互操作性，建議所有放到Url中的組件全部顯式指定某個字符集進行Url編碼，而不依賴於瀏覽器的默認實現。

另外，很多HTTP監視工具或者瀏覽器地址欄等在顯示Url的時候會自動將Url進行一次解碼（使用UTF-8字符集），這就是為什麼當你在Firefox中訪問Google搜索中文的時候，地址欄顯示的Url包含中文的緣故。但實際上發送給服務端的原始Url還是經過編碼的。你可以在地址欄上使用Javascript訪問location.href就可以看出來了。在研究Url編解碼的時候千萬別被這些假象給迷惑了。