URL編碼與解碼

轉載自：www.cnblogs.com/greatverve/archive/2011/12/12/URL-Encoding-Decoding.html【大氣象學習園地：URL編碼與解碼】

一般若是同樣東西須要編碼，說明這樣東西並不適合傳輸。緣由多種多樣，如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編碼。

1	foo://example.com:8042/over/there?name=ferret#nose

2	\_/ \______________/ \________/\_________/ \__/

3	|         |              |         |        |

4	scheme     authority        path     query   fragment

1.哪些字符須要編碼

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編碼，可是仍是有不少老的網關或者傳輸代理會進行編碼。

2.如何對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編碼實現並不徹底遵循這樣的原則，下面會提到。

3.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，須要編碼的字符就更多了。

4. 表單提交

當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。

對於包含中文的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編解碼的時候千萬別被這些假象給迷惑了。

注：

以前在使用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編碼獲得的結果(utf-8編碼結果是%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，並不會受到頁面字符集的影響。