我們通過(guò)HTTP協(xié)議傳輸參數(shù)時(shí)，參數(shù)是以"key=value"這種鍵值對(duì)形式存在的竞思，如果要傳多個(gè)參數(shù)就需要用"&"符號(hào)對(duì)鍵值對(duì)進(jìn)行分割脐嫂。

如"?name1=value1&name2=value2"，這樣在服務(wù)端在收到這種字符串的時(shí)候嵌言，會(huì)用"&"分割出每一個(gè)參數(shù)魏烫，然后再用"="來(lái)分割出參數(shù)值辣苏。

針對(duì)"name1=value1&name2=value2"我們來(lái)說(shuō)一下客戶(hù)端到服務(wù)端的概念上解析過(guò)程:

上述字符串在計(jì)算機(jī)中用ASCII嗎表示為：

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

服務(wù)端在接收到該數(shù)據(jù)后就可以遍歷該字節(jié)流哄褒，首先一個(gè)字節(jié)一個(gè)字節(jié)的吃稀蟋，當(dāng)吃到3D這字節(jié)后，服務(wù)端就知道前面吃得字節(jié)表示一個(gè)key呐赡，再想后吃退客，如果遇到26，說(shuō)明從剛才吃的3D到26子節(jié)之間的是上一個(gè)key的value链嘀，以此類(lèi)推就可以解析出客戶(hù)端傳過(guò)來(lái)的參數(shù)萌狂。

現(xiàn)在有這樣一個(gè)問(wèn)題，如果我的參數(shù)值中就包含=或&這種特殊字符的時(shí)候該怎么辦怀泊？

比如說(shuō)"name1=value1",其中value1的值是"va&lu=e1"字符串茫藏，那么實(shí)際在傳輸過(guò)程中就會(huì)變成這樣"name1=va&lu=e1"。我們的本意是就只有一個(gè)鍵值對(duì)霹琼，但是服務(wù)端會(huì)解析成兩個(gè)鍵值對(duì)务傲，這樣就產(chǎn)生了奇異凉当。

如何解決上述問(wèn)題帶來(lái)的歧義呢？解決的辦法就是對(duì)參數(shù)進(jìn)行URL編碼

URL編碼只是簡(jiǎn)單的在特殊字符的各個(gè)字節(jié)前加上%售葡，例如看杭，我們對(duì)上述會(huì)產(chǎn)生奇異的字符進(jìn)行URL編碼后結(jié)果："name1=va%26lu%3D"，這樣服務(wù)端會(huì)把緊跟在"%"后的字節(jié)當(dāng)成普通的字節(jié)挟伙，就是不會(huì)把它當(dāng)成各個(gè)參數(shù)或鍵值對(duì)的分隔符楼雹。

另外一個(gè)問(wèn)題，就是為什么我們要用ASCII傳輸尖阔，可不可以用別的編碼烘豹？

當(dāng)然可以用別的編碼，你自己可以開(kāi)發(fā)一套編碼诺祸，然后自己解析。就像大部分國(guó)家都有自己的語(yǔ)言一樣祭芦。那國(guó)家之間要交流筷笨，怎么辦？ 用英語(yǔ)把龟劲，英語(yǔ)的使用范圍最廣胃夏。

通常如果一樣?xùn)|西需要編碼，說(shuō)明這樣?xùn)|西并不適合傳輸昌跌。原因多種多樣仰禀，如Size過(guò)大，包含隱私數(shù)據(jù)蚕愤，對(duì)于Url來(lái)說(shuō)答恶，之所以要進(jìn)行編碼，是因?yàn)閁rl中有些字符會(huì)引起歧義萍诱。

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

又如饵蒂，Url的編碼格式采用的是ASCII碼声诸，而不是Unicode，這也就是說(shuō)你不能在Url中包含任何非ASCII字符苹享，例如中文双絮。否則如果客戶(hù)端瀏覽器和服務(wù)端瀏覽器支持的字符集不同的情況下浴麻，中文可能會(huì)造成問(wèn)題。

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

預(yù)備知識(shí)：URI是統(tǒng)一資源標(biāo)識(shí)的意思软免，通常我們所說(shuō)的URL只是URI的一種。典型URL的格式如下所示焚挠。下面提到的URL編碼膏萧，實(shí)際上應(yīng)該指的是URI編碼。

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

_/ ______________/ ________/_________/ __/

|         |              |         |        |

scheme authority path query fragment

哪些字符需要編碼蝌衔？

RFC3986文檔規(guī)定榛泛，Url中只允許包含英文字母（a-zA-Z）、數(shù)字（0-9）噩斟、-_.~4個(gè)特殊字符以及所有保留字符曹锨。RFC3986文檔對(duì)Url的編解碼問(wèn)題做出了詳細(xì)的建議，指出了哪些字符需要被編碼才不會(huì)引起Url語(yǔ)義的轉(zhuǎn)變剃允，以及對(duì)為什么這些字符需要編碼做出了相應(yīng)的解釋沛简。

US-ASCII字符集中沒(méi)有對(duì)應(yīng)的可打印字符：Url中只允許使用可打印字符。US-ASCII碼中的10-7F字節(jié)全都表示控制字符斥废，這些字符都不能直接出現(xiàn)在Url中椒楣。同時(shí)，對(duì)于80-FF字節(jié)（ISO-8859-1）牡肉，由于已經(jīng)超出了US-ACII定義的字節(jié)范圍捧灰，因此也不可以放在Url中。

保留字符：Url可以劃分成若干個(gè)組件统锤，協(xié)議毛俏、主機(jī)、路徑等跪另。有一些字符（:/?#[]@）是用作分隔不同組件的拧抖。例如：冒號(hào)用于分隔協(xié)議和主機(jī)，/用于分隔主機(jī)和路徑免绿，?用于分隔路徑和查詢(xún)參數(shù)唧席，等等。

還有一些字符（!$&'()*+,;=）用于在每個(gè)組件中起到分隔作用的嘲驾，如=用于表示查詢(xún)參數(shù)中的鍵值對(duì)淌哟，&符號(hào)用于分隔查詢(xún)多個(gè)鍵值對(duì)。當(dāng)組件中的普通數(shù)據(jù)包含這些特殊字符時(shí)辽故，需要對(duì)其進(jìn)行編碼徒仓。

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

不安全字符：還有一些字符，當(dāng)他們直接放在Url中的時(shí)候誊垢，可能會(huì)引起解析程序的歧義掉弛。這些字符被視為不安全字符症见，原因有很多。

• 空格：Url在傳輸?shù)倪^(guò)程殃饿，或者用戶(hù)在排版的過(guò)程谋作，或者文本處理程序在處理Url的過(guò)程，都有可能引入無(wú)關(guān)緊要的空格乎芳，或者將那些有意義的空格給去掉遵蚜。

• 引號(hào)以及<>：引號(hào)和尖括號(hào)通常用于在普通文本中起到分隔Url的作用

• ：通常用于表示書(shū)簽或者錨點(diǎn)

• %：百分號(hào)本身用作對(duì)不安全字符進(jìn)行編碼時(shí)使用的特殊字符，因此本身需要編碼

• {}|^[]`~：某一些網(wǎng)關(guān)或者傳輸代理會(huì)篡改這些字符

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

但是由于歷史原因姆坚，目前尚存在一些不標(biāo)準(zhǔn)的編碼實(shí)現(xiàn)澳泵。例如對(duì)于_{符號(hào)，雖然RFC3986文檔規(guī)定兼呵，對(duì)于波浪符號(hào)}兔辅，不需要進(jìn)行Url編碼，但是還是有很多老的網(wǎng)關(guān)或者傳輸代理會(huì)進(jìn)行編碼击喂。

如何對(duì)Url中的非法字符進(jìn)行編碼

Url編碼通常也被稱(chēng)為百分號(hào)編碼（Url Encoding维苔，also known as percent-encoding），是因?yàn)樗木幋a方式非常簡(jiǎn)單懂昂，使用%百分號(hào)加上兩位的字符——0123456789ABCDEF——代表一個(gè)字節(jié)的十六進(jìn)制形式介时。

Url編碼默認(rèn)使用的字符集是US-ASCII。例如a在US-ASCII碼中對(duì)應(yīng)的字節(jié)是0x61凌彬，那么Url編碼之后得到的就是%61沸柔，我們?cè)诘刂窓谏陷斎?strong>http://g.cn/search?q=%61%62%63，實(shí)際上就等同于在google上搜索abc了铲敛。又如@符號(hào)在ASCII字符集中對(duì)應(yīng)的字節(jié)為0x40褐澎，經(jīng)過(guò)Url編碼之后得到的是%40。

對(duì)于非ASCII字符伐蒋，需要使用ASCII字符集的超集進(jìn)行編碼得到相應(yīng)的字節(jié)工三，然后對(duì)每個(gè)字節(jié)執(zhí)行百分號(hào)編碼迁酸。對(duì)于Unicode字符，RFC文檔建議使用utf-8對(duì)其進(jìn)行編碼得到相應(yīng)的字節(jié)俭正，然后對(duì)每個(gè)字節(jié)執(zhí)行百分號(hào)編碼奸鬓。如"中文"使用UTF-8字符集得到的字節(jié)為0xE4 0xB8 0xAD 0xE6 0x96 0x87，經(jīng)過(guò)Url編碼之后得到"%E4%B8%AD%E6%96%87"段审。

如果某個(gè)字節(jié)對(duì)應(yīng)著ASCII字符集中的某個(gè)非保留字符全蝶，則此字節(jié)無(wú)需使用百分號(hào)表示。例如"Url編碼"寺枉，使用UTF-8編碼得到的字節(jié)是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81抑淫，由于前三個(gè)字節(jié)對(duì)應(yīng)著ASCII中的非保留字符"Url"，因此這三個(gè)字節(jié)可以用非保留字符"Url"表示姥闪。最終的Url編碼可以簡(jiǎn)化成"Url%E7%BC%96%E7%A0%81"始苇，當(dāng)然，如果你用"%55%72%6C%E7%BC%96%E7%A0%81"也是可以的筐喳。

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

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

JavaScript中提供了3對(duì)函數(shù)用來(lái)對(duì)Url編碼以得到合法的Url荣月，它們分別是escape / unescape, encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由于解碼和編碼的過(guò)程是可逆的梳毙，因此這里只解釋編碼的過(guò)程哺窄。

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

安全字符不同：

下面列出了這三個(gè)函數(shù)的安全字符（即函數(shù)不會(huì)對(duì)這些字符進(jìn)行編碼）

• escape（69個(gè)）：*/@+-._0-9a-zA-Z

• encodeURI（82個(gè)）：!#$&'()*+,/:;=?@-._~0-9a-zA-Z

• encodeURIComponent（71個(gè)）：!'()*-._~0-9a-zA-Z

兼容性不同：

escape函數(shù)是從Javascript 1.0的時(shí)候就存在了奸柬，其他兩個(gè)函數(shù)是在Javascript 1.5才引入的生年。但是由于Javascript 1.5已經(jīng)非常普及了，所以實(shí)際上使用encodeURI和encodeURIComponent并不會(huì)有什么兼容性問(wèn)題廓奕。

對(duì)Unicode字符的編碼方式不同：

這三個(gè)函數(shù)對(duì)于ASCII字符的編碼方式相同抱婉，均是使用百分號(hào)+兩位十六進(jìn)制字符來(lái)表示。但是對(duì)于Unicode字符桌粉，escape的編碼方式是%uxxxx授段，其中的xxxx是用來(lái)表示unicode字符的4位十六進(jìn)制字符。

這種方式已經(jīng)被W3C廢棄了番甩。但是在ECMA-262標(biāo)準(zhǔn)中仍然保留著escape的這種編碼語(yǔ)法侵贵。encodeURI和encodeURIComponent則使用UTF-8對(duì)非ASCII字符進(jìn)行編碼，然后再進(jìn)行百分號(hào)編碼缘薛。這是RFC推薦的窍育。因此建議盡可能的使用這兩個(gè)函數(shù)替代escape進(jìn)行編碼卡睦。

適用場(chǎng)合不同：encodeURI被用作對(duì)一個(gè)完整的URI進(jìn)行編碼，而encodeURIComponent被用作對(duì)URI的一個(gè)組件進(jìn)行編碼漱抓。從上面提到的安全字符范圍表格來(lái)看表锻，我們會(huì)發(fā)現(xiàn)，encodeURIComponent編碼的字符范圍要比encodeURI的大乞娄。

我們上面提到過(guò)瞬逊，保留字符一般是用來(lái)分隔URI組件（一個(gè)URI可以被切割成多個(gè)組件，參考預(yù)備知識(shí)一節(jié)）或者子組件（如URI中查詢(xún)參數(shù)的分隔符）仪或，如：號(hào)用于分隔scheme和主機(jī)确镊，?號(hào)用于分隔主機(jī)和路徑。由于encodeURI操縱的對(duì)象是一個(gè)完整的的URI范删，這些字符在URI中本來(lái)就有特殊用途蕾域，因此這些保留字符不會(huì)被encodeURI編碼，否則意義就變了到旦。

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

表單提交

當(dāng)Html的表單被提交時(shí)搁骑，每個(gè)表單域都會(huì)被Url編碼之后才在被發(fā)送懈万。由于歷史的原因，表單使用的Url編碼實(shí)現(xiàn)并不符合最新的標(biāo)準(zhǔn)靶病。

例如對(duì)于空格使用的編碼并不是%20，而是+號(hào)口予，如果表單使用的是Post方法提交的娄周，我們可以在HTTP頭中看到有一個(gè)Content-Type的header，值為application/x-www-form-urlencoded沪停。

大部分應(yīng)用程序均能處理這種非標(biāo)準(zhǔn)實(shí)現(xiàn)的Url編碼煤辨，但是在客戶(hù)端Javascript中，并沒(méi)有一個(gè)函數(shù)能夠?qū)?號(hào)解碼成空格木张，只能自己寫(xiě)轉(zhuǎn)換函數(shù)众辨。還有，對(duì)于非ASCII字符舷礼，使用的編碼字符集取決于當(dāng)前文檔使用的字符集鹃彻。例如我們?cè)贖tml頭部加上
<meta http-equiv="Content-Type" content="text/html; charset=gb2312" />
這樣瀏覽器就會(huì)使用gb2312去渲染此文檔（注意，當(dāng)HTML文檔中沒(méi)有設(shè)置此meta標(biāo)簽妻献，則瀏覽器會(huì)根據(jù)當(dāng)前用戶(hù)喜好去自動(dòng)選擇字符集蛛株，用戶(hù)也可以強(qiáng)制當(dāng)前網(wǎng)站使用某個(gè)指定的字符集）团赁。當(dāng)提交表單時(shí)，Url編碼使用的字符集就是gb2312谨履。

之前在使用Aptana（為什么專(zhuān)指aptana下面會(huì)提到）遇到一個(gè)很迷惑的問(wèn)題欢摄，就是在使用encodeURI的時(shí)候，發(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>

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

所以我當(dāng)時(shí)就很質(zhì)疑绿淋，難道encodeURI還跟頁(yè)面編碼有關(guān)，但是我發(fā)現(xiàn)吨艇，正常情況下躬它，如果你使用gb2312進(jìn)行Url編碼也不會(huì)得到這個(gè)結(jié)果的才是。后來(lái)終于被我發(fā)現(xiàn)东涡，原來(lái)是頁(yè)面文件存儲(chǔ)使用的字符集和Meta標(biāo)簽中指定的字符集不一致導(dǎo)致的問(wèn)題冯吓。

Aptana的編輯器默認(rèn)情況下使用UTF-8字符集。也就是說(shuō)這個(gè)文件實(shí)際存儲(chǔ)的時(shí)候使用的是UTF-8字符集疮跑。但是由于Meta標(biāo)簽中指定了gb2312组贺，這個(gè)時(shí)候，瀏覽器就會(huì)按照gb2312去解析這個(gè)文檔祖娘，那么自然在"中文"這個(gè)字符串這里就會(huì)出錯(cuò)失尖，因?yàn)?中文"字符串用UTF-8編碼過(guò)后得到的字節(jié)是0xE4 0xB8 0xAD 0xE6 0x96 0x87，這6個(gè)字節(jié)又被瀏覽器拿gb2312去解碼渐苏，那么就會(huì)得到另外三個(gè)漢字"涓枃"（GBK中一個(gè)漢字占兩個(gè)字節(jié)）掀潮，這三個(gè)漢字在傳入encodeURI函數(shù)之后得到的結(jié)果就是%E6%B6%93%EE%85%9F%E6%9E%83。因此琼富，encodeURI使用的還是UTF-8仪吧，并不會(huì)受到頁(yè)面字符集的影響。

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

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