最近在工作里遇到了兩個關于HTTP傳輸的小坑，記錄一下。
- 使用get方法參數傳遞AES密文，偶發解密失敗。發現是HTTP GET請求會將+號轉為空格，導致解密失敗。
- 支付寶支付通過post方式來進行表單跳轉時，商品名稱（subject）出現中文亂碼問題。
經過一番google后得到結果如下。
HTTP GET + 轉為空格
問題描述
使用get方法參數傳遞AES密文，偶發解密失敗。發現是HTTP GET請求會將+號轉為空格，導致解密失敗。
問題原因
GET請求會把+號轉為空格，為什么呢？
在RFC2396中，列明了";" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," 這些字符為保留字符，需要轉譯后才能出現在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 `+'.
- ...
所有表單的默認編碼為application/x-www-form-urlencoded。表單的數據按如下規則來表示：
- 表單中的鍵名或鍵值中，空格會被+號代替
- ...
那么在一些web框架處理的時候，不嚴格區分GET和POST方法的參數時，則會發生，如果原始值內有+號，會被認為是空格。
解決方案
- 在值明確有可能有+號并且不可能有空格的時候，直接replaceAll(' ', '+')
- 在傳遞值前預先進行urlencode，把+轉為%2B就沒問題了。
POST 表單中文亂碼，GET表格卻不會
問題描述
支付寶支付通過post方式來進行表單跳轉時，商品名稱（subject）出現中文亂碼問題。
問題原因
多次調試后，覺得對方應該在展示頁面的時候使用了ISO-8859-1嘗試解碼，但很奇怪的是通知的時候商品的中文確實正常的，可是說是非常奇妙了。回想起反饋沒有異步通知的事情需要多方確認，沒有人知道怎么辦，可以說是非常baoxiao了。
PS：demo似乎是使用post的，我看下后面能不能跑起來。
解決方案
使用get來進行表單跳轉。
Reference
?
