網(wǎng)址URL中特殊字符轉(zhuǎn)義編碼

字符 - URL編碼值

空格 - %20
" - %22
# - %23
% - %25
& - %26
( - %28
) - %29
+ - %2B
, - %2C
/ - %2F
: - %3A
; - %3B
< - %3C
= - %3D
> - %3E
? - %3F
@ - %40
\ - %5C
| - %7C

URL特殊字符轉(zhuǎn)義，URL中一些字符的特殊含義，基本編碼規(guī)則如下：

1、空格換成加號(+)

2、正斜杠(/)分隔目錄和子目錄

3、問號(?)分隔URL和查詢

4、百分號(%)制定特殊字符

5、#號指定書簽

6、&號分隔參數(shù)

如果需要在URL中用到，需要將這些特殊字符換成相應(yīng)的十六進制的值

+ %2B
/ %2F
? %3F
% %25
# %23
& %26

本文主要針對URI編解碼的相關(guān)問題做了介紹，對Url編碼中哪些字符需要編碼、為什么需要編碼做了詳細的說明，并對比分析了Javascript 中和編解碼相關(guān)的幾對函數(shù)escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。

預(yù)備知識

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

URI是統(tǒng)一資源標識的意思，通常我們所說的Url只是URI的一種。典型Url的格式如上面所示。下面提到的Url編碼，實際上應(yīng)該指的是URI編碼。

為什么需要Url編碼

通常如果一樣?xùn)|西需要編碼，說明這樣?xùn)|西并不適合傳輸。原因多種多樣，如Size過大，包含隱私數(shù)據(jù)，對于Url來說，之所以要進行編碼，是因為Url中有些字符會引起歧義。

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

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

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

哪些字符需要編碼

RFC3986文檔規(guī)定，Url中只允許包含英文字母（a-zA-Z）、數(shù)字（0-9）、-_.~4個特殊字符以及所有保留字符。

RFC3986文檔對Url的編解碼問題做出了詳細的建議，指出了哪些字符需要被編碼才不會引起Url語義的轉(zhuǎn)變，以及對為什么這些字符需要編碼做出了相應(yīng)的解釋。

US-ASCII字符集中沒有對應(yīng)的可打印字符

Url中只允許使用可打印字符。US-ASCII碼中的10-7F字節(jié)全都表示控制字符，這些字符都不能直接出現(xiàn)在Url中。同時，對于80-FF字節(jié)（ISO-8859-1），由于已經(jīng)超出了US-ACII定義的字節(jié)范圍，因此也不可以放在Url中。

保留字符

Url可以劃分成若干個組件，協(xié)議、主機、路徑等。有一些字符（:/?#[]@）是用作分隔不同組件的。例如:冒號用于分隔協(xié)議和主機，/用于分隔 主機和路徑，?用于分隔路徑和查詢參數(shù)，等等。還有一些字符（!$&'()*+,;=）用于在每個組件中起到分隔作用的，如=用于表示查詢參數(shù)中 的鍵值對，&符號用于分隔查詢多個鍵值對。當組件中的普通數(shù)據(jù)包含這些特殊字符時，需要對其進行編碼。

RFC3986中指定了以下字符為保留字符：

不安全字符

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

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

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

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

Url編碼通常也被稱為百分號編碼（Url Encoding，also known as percent-encoding），是因為它的編碼方式非常簡單，使用%百分號加上兩位的字符——0123456789ABCDEF——代表一個字節(jié)的 十六進制形式。Url編碼默認使用的字符集是US-ASCII。例如a在US-ASCII碼中對應(yīng)的字節(jié)是0x61，那么Url編碼之后得到的就 是%61，我們在地址欄上輸入http://g.cn/search?q=%61%62%63，實際上就等同于在google上搜索abc了。又如@符號 在ASCII字符集中對應(yīng)的字節(jié)為0x40，經(jīng)過Url編碼之后得到的是%40。

常見字符的Url編碼列表：

對于非ASCII字符，需要使用ASCII字符集的超集進行編碼得到相應(yīng)的字節(jié)，然后對每個字節(jié)執(zhí)行百分號編碼。 對于Unicode字符，RFC文檔建議使用utf-8對其進行編碼得到相應(yīng)的字節(jié)，然后對每個字節(jié)執(zhí)行百分號編碼。如“中文”使用UTF-8字符集得到 的字節(jié)為0xE4 0xB8 0xAD 0xE6 0x96 0x87，經(jīng)過Url編碼之后得到“%E4%B8%AD%E6%96%87”。

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

由于歷史的原因，有一些Url編碼實現(xiàn)并不完全遵循這樣的原則，下面會提到。

Javascript中的escape,encodeURI和encodeURIComponent的區(qū)別

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

這三個編碼的函數(shù)——escape，encodeURI，encodeURIComponent——都是用于將不安全不合法的Url字符轉(zhuǎn)換為合法的Url字符表示，它們有以下幾個不同點。

安全字符不同

下面的表格列出了這三個函數(shù)的安全字符（即函數(shù)不會對這些字符進行編碼）

兼容性不同

escape函數(shù)是從Javascript1.0的時候就存在了，其他兩個函數(shù)是在Javascript1.5才引入的。但是由于 Javascript1.5已經(jīng)非常普及了，所以實際上使用encodeURI和encodeURIComponent并不會有什么兼容性問題。

對Unicode字符的編碼方式不同

這三個函數(shù)對于ASCII字符的編碼方式相同，均是使用百分號+兩位十六進制字符來表示。但是對于Unicode字符，escape的編碼方式是%uxxxx，其中的xxxx是用來表示unicode字符的4位十六進制字符。這種方式已經(jīng)被W3C廢棄了。但是在ECMA-262標準中仍然保留著escape的這種編碼語法。encodeURI和encodeURIComponent則使用UTF-8對非ASCII字符進行編碼，然后再進行百分號編碼。這是RFC推薦的。因此建議盡可能的使用這兩個函數(shù)替代escape進行編碼。

適用場合不同

encodeURI被用作對一個完整的URI進行編碼，而encodeURIComponent被用作對URI的一個組件進行編碼。

從上面提到的安全字符范圍表格來看，我們會發(fā)現(xiàn)，encodeURIComponent編碼的字符范圍要比encodeURI的大。我們上面提到 過，保留字符一般是用來分隔URI組件（一個URI可以被切割成多個組件，參考預(yù)備知識一節(jié)）或者子組件（如URI中查詢參數(shù)的分隔符），如:號用于分隔 scheme和主機，?號用于分隔主機和路徑。由于encodeURI操縱的對象是一個完整的的URI，這些字符在URI中本來就有特殊用途，因此這些保 留字符不會被encodeURI編碼，否則意義就變了。

組件內(nèi)部有自己的數(shù)據(jù)表示格式，但是這些數(shù)據(jù)內(nèi)部不能包含有分隔組件的保留字符，否則就會導(dǎo)致整個URI中組件的分隔混亂。因此對于單個組件使用encodeURIComponent，需要編碼的字符就更多了。

表單提交

當Html的表單被提交時，每個表單域都會被Url編碼之后才在被發(fā)送。由于歷史的原因，表單使用的Url編碼實現(xiàn)并不符合最新的標準。例如對于空 格使用的編碼并不是%20，而是+號，如果表單使用的是Post方法提交的，我們可以在HTTP頭中看到有一個Content-Type的header， 值為application/x-www-form-urlencoded。大部分應(yīng)用程序均能處理這種非標準實現(xiàn)的Url編碼，但是在客戶端 Javascript中，并沒有一個函數(shù)能夠?qū)?號解碼成空格，只能自己寫轉(zhuǎn)換函數(shù)。還有，對于非ASCII字符，使用的編碼字符集取決于當前文檔使用的 字符集。例如我們在Html頭部加上

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

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

文檔字符集會影響encodeURI嗎？

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

<!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> 

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

所以我當時就很質(zhì)疑，難道encodeURI還跟頁面編碼有關(guān)，但是我發(fā)現(xiàn)，正常情況下，如果你使用gb2312進行Url編碼也不會得到這個結(jié)果的才是。后來終于被我發(fā)現(xiàn)，原來是頁面文件存儲使用的字符集和Meta標簽中指定的字符集不一致導(dǎo)致的問題。 Aptana的編輯器默認情況下使用UTF-8字符集。也就是說這個文件實際存儲的時候使用的是UTF-8字符集。但是由于Meta標簽中指定了 gb2312，這個時候，瀏覽器就會按照gb2312去解析這個文檔，那么自然在“中文”這個字符串這里就會出錯，因為“中文”字符串用UTF-8編碼過 后得到的字節(jié)是0xE4 0xB8 0xAD 0xE6 0x96 0x87，這6個字節(jié)又被瀏覽器拿gb2312去解碼，那么就會得到另外三個漢字“涓枃”（GBK中一個漢字占兩個字節(jié)），這三個漢字在傳入 encodeURI函數(shù)之后得到的結(jié)果就是%E6%B6%93%EE%85%9F%E6%9E%83。因此，encodeURI使用的還是UTF-8，并 不會受到頁面字符集的影響。

其他和Url編碼相關(guān)的問題

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

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

以上為個人經(jīng)驗，希望能給大家一個參考，也希望大家多多支持腳本之家。