编码加密过后，前端传输数据后台+变空格

业务场景：
1.Android端使用webview加载h5界面需要向后台传输数据
2.据Android开发人员所说是post请求
数据处理：
1.des3加密
2.base64编码
问题：
加密过后出现+后，后台通过request.getParamters("msg")获取加密过的数据，进行解密时出错
原因：
加密传输过来的数据含有特殊字符+，到后台拿到未解密数据时+变为空格
问题处理过程如下：
首先我们在后台自己模拟测试：
1.通过jsp建立form表达数据，使用post和get分别进行传输含有+的数据，经过测试发现无异常现象
也就是说通过form表单提交的方式不会出现+转空格的问题

2.后台通过httpclient 的post 和 get请求，拿到的数据也是+变为了空格

其实遇到这个问题是挺疑惑的不知道哪一步出错了，就瞎调调看，直接跟入request.getParamters("msg") 源码（要关联tomcat源码才能跟入最     底层否则无法看到效果），跟入最底层tomcat中有如下代码(Parameters 类中的processParameters的这个方法)：

从上可以看出，含有特殊字符的话，它会进行decode操作，+属于特殊字符，当进行decode之后就变成了空格，也就是说当我们调用request.getParamters("msg")的时候，如果含有特殊字符它会再进行decode一次，到此问题已经找到
解决方式，Android端加密之后的数据再进行一次编码，后台不需要做任何处理，就可以规避这个问题了


刚才from中为什么就没有问题呢 经查找如下原因：
表单提交的3种方式，http post的contentType
application/x-www-form-urlencoded：窗体数据被编码为名称/值对。这是标准的编码格式。这是默认的方式
multipart/form-data：窗体数据被编码为一条消息，页上的每个控件对应消息中的一个部分。二进制数据传输方式，主要用于上传文件
text/plain：窗体数据以纯文本形式进行编码，其中不含任何控件或格式字符。


application/x-www-form-urlencoded，为默认的编码方式，也就是会默认进行编码，请求到后台之后，tomcat又自己解了一次码，所以不会出现+号变空格的问题；
另外补充一下，以前一直不是很明白AJAX异步请求中文get方式为什么要两次编码（encodeURI(encodeURI())），而后台只需一次加密在,通过这个问题的排查也清楚了特做如下备注：
1.前端做一次编码后台不做解码，如果tomcat默认不是utf-8解码，就会出现乱码

2.前端做两次编码后台做一次解码，tomcat默认解码一次，不管是不是utf-8都不会出现乱码，开发人员根据自己的编码方式，再进行一次解码操作，所以避免乱码出现的问题

个人公众号欢迎共同成长交流