最近在工作里遇到了兩個(gè)關(guān)于HTTP傳輸?shù)男】樱涗浺幌隆?/p>
- 使用get方法參數(shù)傳遞AES密文，偶發(fā)解密失敗。發(fā)現(xiàn)是HTTP GET請(qǐng)求會(huì)將+號(hào)轉(zhuǎn)為空格，導(dǎo)致解密失敗。
- 支付寶支付通過(guò)post方式來(lái)進(jìn)行表單跳轉(zhuǎn)時(shí)，商品名稱（subject）出現(xiàn)中文亂碼問(wèn)題。
經(jīng)過(guò)一番google后得到結(jié)果如下。
HTTP GET + 轉(zhuǎn)為空格
問(wèn)題描述
使用get方法參數(shù)傳遞AES密文，偶發(fā)解密失敗。發(fā)現(xiàn)是HTTP GET請(qǐng)求會(huì)將+號(hào)轉(zhuǎn)為空格，導(dǎo)致解密失敗。
問(wèn)題原因
GET請(qǐng)求會(huì)把+號(hào)轉(zhuǎn)為空格，為什么呢？
在RFC2396中，列明了";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," 這些字符為保留字符，需要轉(zhuǎn)譯后才能出現(xiàn)在uri中。
另外又由于RFC1866中，列出
The default encoding for all forms is 'application/x-www-form-urlencoded'. A form data set is represented in this media type as follows:
- The form field names and values are escaped: space characters are replaced by `+'.
- ...
所有表單的默認(rèn)編碼為application/x-www-form-urlencoded。表單的數(shù)據(jù)按如下規(guī)則來(lái)表示：
- 表單中的鍵名或鍵值中，空格會(huì)被+號(hào)代替
- ...
那么在一些web框架處理的時(shí)候，不嚴(yán)格區(qū)分GET和POST方法的參數(shù)時(shí)，則會(huì)發(fā)生，如果原始值內(nèi)有+號(hào)，會(huì)被認(rèn)為是空格。
解決方案
- 在值明確有可能有+號(hào)并且不可能有空格的時(shí)候，直接replaceAll(' ', '+')
- 在傳遞值前預(yù)先進(jìn)行urlencode，把+轉(zhuǎn)為%2B就沒(méi)問(wèn)題了。
POST 表單中文亂碼，GET表格卻不會(huì)
問(wèn)題描述
支付寶支付通過(guò)post方式來(lái)進(jìn)行表單跳轉(zhuǎn)時(shí)，商品名稱（subject）出現(xiàn)中文亂碼問(wèn)題。
問(wèn)題原因
多次調(diào)試后，覺(jué)得對(duì)方應(yīng)該在展示頁(yè)面的時(shí)候使用了ISO-8859-1嘗試解碼，但很奇怪的是通知的時(shí)候商品的中文確實(shí)正常的，可是說(shuō)是非常奇妙了?；叵肫鸱答仜](méi)有異步通知的事情需要多方確認(rèn)，沒(méi)有人知道怎么辦，可以說(shuō)是非常baoxiao了。
PS：demo似乎是使用post的，我看下后面能不能跑起來(lái)。
解決方案
使用get來(lái)進(jìn)行表單跳轉(zhuǎn)。
Reference
?
