最近遇到的两个HTTP传输的小坑

最近在工作里遇到了两个关于HTTP传输的小坑，记录一下。

1. 使用get方法参数传递AES密文，偶发解密失败。发现是HTTP GET请求会将+号转为空格，导致解密失败。
2. 支付宝支付通过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:

1. The form field names and values are escaped: space characters are replaced by `+'.
2. ...

所有表单的默认编码为application/x-www-form-urlencoded。表单的数据按如下规则来表示：

1. 表单中的键名或键值中，空格会被+号代替
2. ...

那么在一些web框架处理的时候，不严格区分GET和POST方法的参数时，则会发生，如果原始值内有+号，会被认为是空格。

解决方案

1. 在值明确有可能有+号并且不可能有空格的时候，直接replaceAll(' ', '+')
2. 在传递值前预先进行urlencode，把+转为%2B就没问题了。

POST 表单中文乱码，GET表格却不会

问题描述

支付宝支付通过post方式来进行表单跳转时，商品名称（subject）出现中文乱码问题。

问题原因

多次调试后，觉得对方应该在展示页面的时候使用了ISO-8859-1尝试解码，但很奇怪的是通知的时候商品的中文确实正常的，可是说是非常奇妙了。回想起反馈没有异步通知的事情需要多方确认，没有人知道怎么办，可以说是非常baoxiao了。

PS：demo似乎是使用post的，我看下后面能不能跑起来。

解决方案

使用get来进行表单跳转。

Reference

1. Get + 号的问答

2. RFC 2396

3. RFC1866

4. escape/encodeURI/encodeURIComponent的不同

5. 知乎版HTTP GET与POST的不同

​