摘要

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

預(yù)備知識(shí)

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

為什么需要Url編碼

通常如果一樣?xùn)|西需要編碼，說明這樣?xùn)|西并不適合傳輸丙猬。原因多種多樣涨颜，如Size過大，包含隱私數(shù)據(jù)茧球，對(duì)于Url來說庭瑰，之所以要進(jìn)行編碼，是因?yàn)閁rl中有些字符會(huì)引起歧義抢埋。

例如Url參數(shù)字符串中使用key=value鍵值對(duì)這樣的形式來傳參弹灭，鍵值對(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驾诈，這也就是說你不能在Url中包含任何非ASCII字符辽社，例如中文。否則如果客戶端瀏覽器和服務(wù)端瀏覽器支持的字符集不同的情況下翘鸭，中文可能會(huì)造成問題滴铅。

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

哪些字符需要編碼

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

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

US-ASCII字符集中沒有對(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ī)和路徑，?用于分隔路徑和查詢參數(shù)转培，等等恶导。還有一些字符（!$&'()*+,;=）用于在每個(gè)組件中起到分隔作用的，如=用于表示查詢參數(shù)中的鍵值對(duì)堡距，&符號(hào)用于分隔查詢多個(gè)鍵值對(duì)甲锡。當(dāng)組件中的普通數(shù)據(jù)包含這些特殊字符時(shí)，需要對(duì)其進(jìn)行編碼羽戒。

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

| ! | * | ' | ( | ) | ; | : | @ | & | = | + | $ | , | / | ? | # | [ | ] |

不安全字符

還有一些字符缤沦，當(dāng)他們直接放在Url中的時(shí)候，可能會(huì)引起解析程序的歧義易稠。這些字符被視為不安全字符缸废，原因有很多。

| 空格 | Url在傳輸?shù)倪^程驶社，或者用戶在排版的過程企量，或者文本處理程序在處理Url的過程，都有可能引入無關(guān)緊要的空格亡电，或者將那些有意義的空格給去掉 |
| 引號(hào)以及<> | 引號(hào)和尖括號(hào)通常用于在普通文本中起到分隔Url的作用 |
| # | 通常用于表示書簽或者錨點(diǎn) |
| % | 百分號(hào)本身用作對(duì)不安全字符進(jìn)行編碼時(shí)使用的特殊字符届巩，因此本身需要編碼 |
| {}|^[]`~ | 某一些網(wǎng)關(guān)或者傳輸代理會(huì)篡改這些字符 |

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

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

Url編碼通常也被稱為百分號(hào)編碼（Url Encoding苫纤，also known as percent-encoding），是因?yàn)樗木幋a方式非常簡單纲缓，使用%百分號(hào)加上兩位的字符——0123456789ABCDEF——代表一個(gè)字節(jié)的十六進(jìn)制形式卷拘。Url編碼默認(rèn)使用的字符集是US-ASCII。例如a在US-ASCII碼中對(duì)應(yīng)的字節(jié)是0x61祝高，那么Url編碼之后得到的就是%61栗弟，我們?cè)诘刂窓谏陷斎?a target="_blank">http://g.cn/search?q=%61%62%63，實(shí)際上就等同于在google上搜索abc了工闺。又如@符號(hào)在ASCII字符集中對(duì)應(yīng)的字節(jié)為0x40乍赫，經(jīng)過Url編碼之后得到的是%40瓣蛀。

常見字符的Url編碼列表：

<caption style="margin: 0px; padding: 0px;">保留字符的Url編碼</caption>
| ! | * | " | ' | ( | ) | ; | : | @ | & |
| %21 | %2A | %22 | %27 | %28 | %29 | %3B | %3A | %40 | %26 |
| = | + | $ | , | / | ? | % | # | [ | ] |
| %3D | %2B | %24 | %2C | %2F | %3F | %25 | %23 | %5B | %5D |

對(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)過Url編碼之后得到“%E4%B8%AD%E6%96%87”像棘。

如果某個(gè)字節(jié)對(duì)應(yīng)著ASCII字符集中的某個(gè)非保留字符稽亏，則此字節(jié)無需使用百分號(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編碼可以簡化成“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ù)用來對(duì)Url編碼以得到合法的Url状飞，它們分別是escape / unescape,encodeURI / decodeURI和encodeURIComponent / decodeURIComponent。由于解碼和編碼的過程是可逆的书斜，因此這里只解釋編碼的過程诬辈。

這三個(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ù)是從Javascript1.0的時(shí)候就存在了样屠，其他兩個(gè)函數(shù)是在Javascript1.5才引入的穿撮。但是由于Javascript1.5已經(jīng)非常普及了，所以實(shí)際上使用encodeURI和encodeURIComponent并不會(huì)有什么兼容性問題痪欲。

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

這三個(gè)函數(shù)對(duì)于ASCII字符的編碼方式相同悦穿，均是使用百分號(hào)+兩位十六進(jìn)制字符來表示。但是對(duì)于Unicode字符业踢，escape的編碼方式是%uxxxx栗柒，其中的xxxx是用來表示unicode字符的4位十六進(jìn)制字符。這種方式已經(jīng)被W3C廢棄了知举。但是在ECMA-262標(biāo)準(zhǔn)中仍然保留著escape的這種編碼語法瞬沦。encodeURI和encodeURIComponent則使用UTF-8對(duì)非ASCII字符進(jìn)行編碼太伊，然后再進(jìn)行百分號(hào)編碼。這是RFC推薦的逛钻。因此建議盡可能的使用這兩個(gè)函數(shù)替代escape進(jìn)行編碼僚焦。

適用場合不同

encodeURI被用作對(duì)一個(gè)完整的URI進(jìn)行編碼，而encodeURIComponent被用作對(duì)URI的一個(gè)組件進(jìn)行編碼绣的。

從上面提到的安全字符范圍表格來看，我們會(huì)發(fā)現(xiàn)欲账，encodeURIComponent編碼的字符范圍要比encodeURI的大屡江。我們上面提到過，保留字符一般是用來分隔URI組件（一個(gè)URI可以被切割成多個(gè)組件赛不，參考預(yù)備知識(shí)一節(jié)）或者子組件（如URI中查詢參數(shù)的分隔符）惩嘉，如:號(hào)用于分隔scheme和主機(jī)，?號(hào)用于分隔主機(jī)和路徑踢故。由于encodeURI操縱的對(duì)象是一個(gè)完整的的URI文黎，這些字符在URI中本來就有特殊用途，因此這些保留字符不會(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編碼鹅髓，但是在客戶端Javascript中，并沒有一個(gè)函數(shù)能夠?qū)?號(hào)解碼成空格京景，只能自己寫轉(zhuǎn)換函數(shù)窿冯。還有，對(duì)于非ASCII字符确徙，使用的編碼字符集取決于當(dāng)前文檔使用的字符集醒串。例如我們?cè)贖tml頭部加上

|

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

|

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

文檔字符集會(huì)影響encodeURI嗎膘壶？

之前在使用Aptana（為什么專指aptana下面會(huì)提到）遇到一個(gè)很迷惑的問題，就是在使用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還跟頁面編碼有關(guān)肛宋，但是我發(fā)現(xiàn)州藕，正常情況下，如果你使用gb2312進(jìn)行Url編碼也不會(huì)得到這個(gè)結(jié)果的才是酝陈。后來終于被我發(fā)現(xiàn)床玻，原來是頁面文件存儲(chǔ)使用的字符集和Meta標(biāo)簽中指定的字符集不一致導(dǎo)致的問題。Aptana的編輯器默認(rèn)情況下使用UTF-8字符集沉帮。也就是說這個(gè)文件實(shí)際存儲(chǔ)的時(shí)候使用的是UTF-8字符集笨枯。但是由于Meta標(biāo)簽中指定了gb2312，這個(gè)時(shí)候遇西，瀏覽器就會(huì)按照gb2312去解析這個(gè)文檔馅精，那么自然在“中文”這個(gè)字符串這里就會(huì)出錯(cuò)，因?yàn)椤爸形摹弊址肬TF-8編碼過后得到的字節(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ì)受到頁面字符集的影響渗常。

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

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

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

——Kevin Yang
http://www.imkevinyang.com/2009/08/%E8%AF%A6%E8%A7%A3javascript%E4%B8%AD%E7%9A%84url%E7%BC%96%E8%A7%A3%E7%A0%81.html