最近在工作里遇到了两个关于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
