标签:使用 3.4 转义 日志 encode encodeuri decode 编码转换 com
在一个项目中,app请求tcpdump日志与记录的日志内容不一致
请求%2B
识别成 +
请求 +
识别成 空格
这个在base64解密的时候会出现异常,base64需要的是加号,而不是空格
在js中,对url的加密分别由三种方式:
escape("aa+aa aa")
"aa+aa%20aa"
encodeURI("aa+aa aa")
"aa+aa%20aa"
encodeURIComponent("aa+aa aa")
"aa%2Baa%20aa"
第三种方式,+
变成%2B
java代码:
System.out.println(URLEncoder.encode("aa+aa aa","UTF-8"));
aa%2Baa+aa
特么加号变成%2B,空格变成加号
如果是没经过加密,但是解密了
System.out.println(URLDecoder.decode("aa+aa aa","UTF-8"));
aa aa aa
好吧,从这里就可以看出,为什么base64解密报错了
app端进行base64加密,内部含有+
,然后并没有进行url加密,直接传给后端,后端对其先进行Url解密,+
变成了空格,再进行base64解密,所以报错。
造成这种混乱局面的原因在于:
W3C标准规定,当Content-Type为application/x-www-form-urlencoded时,URL中查询参数名和参数值中空格要用加号+替代,所以几乎所有使用该规范的浏览器在表单提交后,URL查询参数中空格都会被编成加号+。
而在另一份规范(RFC 2396,定义URI)里, URI里的保留字符都需转义成%HH格式(Section 3.4 Query Component),因此空格会被编码成%20,加号+本身也作为保留字而被编成%2B,对于某些遵循RFC 2396标准的应用来说,它可能不接受查询字符串中出现加号+,认为它是非法字符。所以一个安全的举措是URL中统一使用%20来编码空格字符。
Java中的URLEncoder本意是用来把字符串编码成application/x-www-form-urlencoded MIME格式字符串,也就是说仅仅适用于URL中的查询字符串部分,但是URLEncoder经常被用来对URL的其他部分编码,它的encode方法会把空格编成加号+,与之对应的是,URLDecoder的decode方法会把加号+和%20都解码为空格,这种违反直觉的做法造成了当初我对空格URL编码问题的困扰。
因此后来我的做法都是,在调用URLEncoder.encode对URL进行编码后(所有加号+已被编码成%2B),再调用replaceAll(“+”, “%20″),将所有加号+替换为%20。
标签:使用 3.4 转义 日志 encode encodeuri decode 编码转换 com
原文地址:https://www.cnblogs.com/hongdada/p/10338015.html