開發(fā)過程中遇到一個(gè)問題围小，就是在用GET方法請求接口的時(shí)候宪迟，傳入的參數(shù)值中酣衷，+號會(huì)被轉(zhuǎn)化為空格，傳給后臺(tái)次泽。
傳入的參數(shù)是:"aaa++++bbb--@%&"穿仪，被url編碼和解碼后，傳入后臺(tái)就變成了截圖所示意荤。加號全部被轉(zhuǎn)為空格啊片。截圖的請求方式之所以展示為post，是因?yàn)榍岸俗隽私涌跀r截設(shè)置玖像，把所有的GET請求轉(zhuǎn)為了POST請求紫谷。
后來把請求方式改為post，content-type設(shè)置為xxx-form-urlencoded捐寥，+號依然被轉(zhuǎn)化為空格傳給了后臺(tái)笤昨，如下方截圖所示
剛開始以為只是content-type:xxx-form-urlencoded導(dǎo)致的。
后來在chrome的url搜索欄輸入www.baidu.com/aa+bb?cc=e+f然后按enter鍵看了下接口請求握恳，如下圖
最終的解決方案是:后臺(tái)修改了傳參類型瞒窒，前臺(tái)用POST，改為JSON傳參乡洼。
后面查了一些資料崇裁。以下是查詢所得:
對于Url來說，之所以要進(jìn)行編碼束昵，是因?yàn)閁rl中有些字符會(huì)引起歧義拔稳。
例如，Url參數(shù)字符串中使用key=value鍵值對這樣的形式來傳參妻怎，鍵值對之間以&符號分隔，如/s?q=abc&ie=utf-8泞歉。如果你的value字符串中包含了=或者&逼侦，那么勢必會(huì)造成接收Url的服務(wù)器解析錯(cuò)誤，因此必須將引起歧義的&和=符號進(jìn)行轉(zhuǎn)義腰耙，也就是對其進(jìn)行編碼榛丢。
又如，Url的編碼格式采用的是ASCII碼挺庞，而不是Unicode晰赞，這也就是說你不能在Url中包含任何非ASCII字符，例如中文。否則如果客戶端瀏覽器和服務(wù)端瀏覽器支持的字符集不同的情況下掖鱼，中文可能會(huì)造成問題然走。
Url編碼的原則就是使用安全的字符（沒有特殊用途或者特殊意義的可打印字符）去表示那些不安全的字符。
哪些字符需要編碼?
RFC3986文檔規(guī)定戏挡，Url中只允許包含英文字母（a-zA-Z）芍瑞、數(shù)字（0-9）、-_.~4個(gè)特殊字符以及所有保留字符褐墅。RFC3986文檔對Url的編解碼問題做出了詳細(xì)的建議拆檬，指出了哪些字符需要被編碼才不會(huì)引起Url語義的轉(zhuǎn)變，以及對為什么這些字符需要編碼做出了相應(yīng)的解釋妥凳。
US-ASCII字符集中沒有對應(yīng)的可打印字符：Url中只允許使用可打印字符竟贯。US-ASCII碼中的10-7F字節(jié)全都表示控制字符，這些字符都不能直接出現(xiàn)在Url中逝钥。同時(shí)屑那，對于80-FF字節(jié)（ISO-8859-1），由于已經(jīng)超出了US-ACII定義的字節(jié)范圍晌缘，因此也不可以放在Url中齐莲。
保留字符：Url可以劃分成若干個(gè)組件，協(xié)議磷箕、主機(jī)选酗、路徑等。有一些字符（:/?#[]@）是用作分隔不同組件的岳枷。例如：冒號用于分隔協(xié)議和主機(jī)芒填，/用于分隔主機(jī)和路徑，?用于分隔路徑和查詢參數(shù)空繁，等等殿衰。還有一些字符（!$&'()*+,;=）用于在每個(gè)組件中起到分隔作用的，如=用于表示查詢參數(shù)中的鍵值對盛泡，&符號用于分隔查詢多個(gè)鍵值對闷祥。當(dāng)組件中的普通數(shù)據(jù)包含這些特殊字符時(shí)，需要對其進(jìn)行編碼傲诵。
RFC3986中指定了以下字符為保留字符：! * ' ( ) ; : @ & = + $ , / ? # [ ]
注意：大多數(shù)人不知道"+"在路徑部分是被允許的并且特指正號而不是空格凯砍。其他類似的有：
"?"在查詢部分允許不被轉(zhuǎn)義，
"/"在查詢部分允許不被轉(zhuǎn)義拴竹，
"="在作為路徑參數(shù)或者查詢參數(shù)值以及在路徑部分允許不被轉(zhuǎn)義悟衩，
":@-._~!$&'()*+,;="等字符在路徑部分允許不被轉(zhuǎn)義，
"/?:@-._~!$&'()*+,;="等字符在任何段中允許不被轉(zhuǎn)義栓拜。(驗(yàn)證過'作為查詢參數(shù)還是會(huì)被編碼)
不安全字符：還有一些字符座泳，當(dāng)他們直接放在Url中的時(shí)候惠昔，可能會(huì)引起解析程序的歧義。這些字符被視為不安全字符挑势，原因有很多镇防。
空格：Url在傳輸?shù)倪^程，或者用戶在排版的過程薛耻，或者文本處理程序在處理Url的過程营罢，都有可能引入無關(guān)緊要的空格，或者將那些有意義的空格給去掉饼齿。
引號以及<>：引號和尖括號通常用于在普通文本中起到分隔Url的作用
#：通常用于表示書簽或者錨點(diǎn)
%：百分號本身用作對不安全字符進(jìn)行編碼時(shí)使用的特殊字符饲漾，因此本身需要編碼
{}|\^[]`~：某一些網(wǎng)關(guān)或者傳輸代理會(huì)篡改這些字符
需要注意的是，對于Url中的合法字符缕溉，編碼和不編碼是等價(jià)的考传，但是對于上面提到的這些字符，如果不經(jīng)過編碼证鸥，那么它們有可能會(huì)造成Url語義的不同僚楞。
因此對于Url而言，只有普通英文字符和數(shù)字枉层，特殊字符$-_.+!*'()還有保留字符泉褐，才能出現(xiàn)在未經(jīng)編碼的Url之中。其他字符均需要經(jīng)過編碼之后才能出現(xiàn)在Url中鸟蜡。
但是由于歷史原因膜赃，目前尚存在一些不標(biāo)準(zhǔn)的編碼實(shí)現(xiàn)。例如對于~符號揉忘，雖然RFC3986文檔規(guī)定跳座，對于波浪符號~，不需要進(jìn)行Url編碼泣矛，但是還是有很多老的網(wǎng)關(guān)或者傳輸代理會(huì)進(jìn)行編碼疲眷。
如何對Url中的非法字符進(jìn)行編碼?
Url編碼通常也被稱為百分號編碼（Url Encoding，also known as percent-encoding）您朽，是因?yàn)樗木幋a方式非常簡單狂丝，使用%百分號加上兩位的字符——0123456789ABCDEF——代表一個(gè)字節(jié)的十六進(jìn)制形式。Url編碼默認(rèn)使用的字符集是US-ASCII哗总。例如a在US-ASCII碼中對應(yīng)的字節(jié)是0x61几颜，那么Url編碼之后得到的就是%61，我們在地址欄上輸入http://g.cn/search?q=%61%62%63魂奥，實(shí)際上就等同于在google上搜索abc了菠剩。又如@符號在ASCII字符集中對應(yīng)的字節(jié)為0x40易猫，經(jīng)過Url編碼之后得到的是%40耻煤。
對于非ASCII字符，需要使用ASCII字符集的超集進(jìn)行編碼得到相應(yīng)的字節(jié)，然后對每個(gè)字節(jié)執(zhí)行百分號編碼哈蝇。對于Unicode字符棺妓，RFC文檔建議使用utf-8對其進(jìn)行編碼得到相應(yīng)的字節(jié)，然后對每個(gè)字節(jié)執(zhí)行百分號編碼炮赦。如"中文"使用UTF-8字符集得到的字節(jié)為0xE4 0xB8 0xAD 0xE6 0x96 0x87怜跑，經(jīng)過Url編碼之后得到"%E4%B8%AD%E6%96%87"。
如果某個(gè)字節(jié)對應(yīng)著ASCII字符集中的某個(gè)非保留字符吠勘，則此字節(jié)無需使用百分號表示性芬。例如"Url編碼"，使用UTF-8編碼得到的字節(jié)是0x55 0x72 0x6C 0xE7 0xBC 0x96 0xE7 0xA0 0x81剧防，由于前三個(gè)字節(jié)對應(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對函數(shù)用來對Url編碼以得到合法的Url主守，它們分別是escape / unescape, encodeURI / decodeURI和encodeURIComponent / decodeURIComponent勾笆。由于解碼和編碼的過程是可逆的曹铃，因此這里只解釋編碼的過程卵渴。
這三個(gè)編碼的函數(shù)——escape券腔，encodeURI钱豁，encodeURIComponent——都是用于將不安全不合法的Url字符轉(zhuǎn)換為合法的Url字符表示棉钧，它們有以下幾個(gè)不同點(diǎn)瓜喇。
安全字符不同：
下面列出了這三個(gè)函數(shù)的安全字符（即函數(shù)不會(huì)對這些字符進(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ì)有什么兼容性問題望众。
對Unicode字符的編碼方式不同：這三個(gè)函數(shù)對于ASCII字符的編碼方式相同，均是使用百分號+兩位十六進(jìn)制字符來表示伞辛。但是對于Unicode字符烂翰，escape的編碼方式是%uxxxx，其中的xxxx是用來表示unicode字符的4位十六進(jìn)制字符蚤氏。這種方式已經(jīng)被W3C廢棄了甘耿。但是在ECMA-262標(biāo)準(zhǔn)中仍然保留著escape的這種編碼語法。encodeURI和encodeURIComponent則使用UTF-8對非ASCII字符進(jìn)行編碼竿滨，然后再進(jìn)行百分號編碼佳恬。這是RFC推薦的捏境。因此建議盡可能的使用這兩個(gè)函數(shù)替代escape進(jìn)行編碼。
適用場合不同：encodeURI被用作對一個(gè)完整的URI進(jìn)行編碼毁葱，而encodeURIComponent被用作對URI的一個(gè)組件進(jìn)行編碼垫言。從上面提到的安全字符范圍表格來看，我們會(huì)發(fā)現(xiàn)倾剿，encodeURIComponent編碼的字符范圍要比encodeURI的大筷频。我們上面提到過，保留字符一般是用來分隔URI組件（一個(gè)URI可以被切割成多個(gè)組件）或者子組件（如URI中查詢參數(shù)的分隔符）前痘，如：號用于分隔scheme和主機(jī)凛捏，?號用于分隔主機(jī)和路徑。由于encodeURI操縱的對象是一個(gè)完整的的URI芹缔，這些字符在URI中本來就有特殊用途葵袭，因此這些保留字符不會(huì)被encodeURI編碼，否則意義就變了乖菱。
組件內(nèi)部有自己的數(shù)據(jù)表示格式坡锡，但是這些數(shù)據(jù)內(nèi)部不能包含有分隔組件的保留字符，否則就會(huì)導(dǎo)致整個(gè)URI中組件的分隔混亂窒所。因此對于單個(gè)組件使用encodeURIComponent鹉勒，需要編碼的字符就更多了。
表單提交
當(dāng)Html的表單被提交時(shí)吵取，每個(gè)表單域都會(huì)被Url編碼之后才在被發(fā)送禽额。由于歷史的原因，表單使用的Url編碼實(shí)現(xiàn)并不符合最新的標(biāo)準(zhǔn)皮官。例如對于空格使用的編碼并不是%20脯倒，而是+號，如果表單使用的是Post方法提交的捺氢，我們可以在HTTP頭中看到有一個(gè)Content-Type的header藻丢，值為application/x-www-form-urlencoded。
還有摄乒，對于非ASCII字符悠反，使用的編碼字符集取決于當(dāng)前文檔使用的字符集。例如我們在Html頭部加上
<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。
對于包含中文的Url的處理問題舅世，不同瀏覽器有不同的表現(xiàn)旦委。例如對于IE踊沸，如果你勾選了高級設(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í)候千萬別被這些假象給迷惑了日杈。
