上上周,看到一位老哥找我们组同事联调接口,不知道是什么问题,两人坐一起搞了快1个小时,看起来好像有点复杂。
突然,老哥发出一声卧槽,"我传参里的+号,到你这怎么变成了空格!",这个声音很大,我明显的听到了,很快,我就大概Get到了他们的问题点。
我猜测他们遇到的问题大概如下:
+
,如{"notes":"代码"}
base64编码为eyJub3RlcyI6IuS7o+eggSJ9Cg==
。data=eyJub3RlcyI6IuS7o+eggSJ9Cg==
,组织成http请求发出。如果写成等价的curl,就是这样:
$ curl http://localhost:8080/send -d 'data=eyJub3RlcyI6IuS7o+eggSJ9Cg=='
写个测试接口调试下看看,如下:
这就是他们遇到的问题,+
会变成空格,这个坑其实蛮容易踩到,我自己刚工作时就踩到过这个坑,也多次看到或听到别人同踩此坑
这个问题和urlencode编码有关,urlencode编码,一般来说,除字母、数字和*
,.
,-
和_
这些字节原样输出外,其它字节都会编码为%XX
(16进制)的形式。
但有一个特例,如下:
String enc = URLEncoder.encode(" ", "UTF-8");
System.out.println(enc); // 输出+号
String dec = URLDecoder.decode("+", "UTF-8");
System.out.println(dec); // 输出空格
特例就是空格会被编码为+
号,反之,+
号会被解码为空格!
注:在新的RFC 2396规范中,空格其实也可以编码成%20,而解码时,
+
号与%20都会被解码为空格。
回想上面的场景,如果将带有+
号的base64字符串,原封不动的封装到data=中,再发送给Tomcat等Web服务器,若Tomcat侧做一次urldecode解码,+
是不是就变成空格了
而Tomcat确实会做urldecode解码这样的操作,当调用方的Content-Type为application/x-www-form-urlencoded
时,这里知道有这种操作即可,想了解细节可看看我写的这篇文章
解决这种问题,主要有两种方法,如下:
按规范来看,当Content-Type为application/x-www-form-urlencoded
时,调用方是必须对参数名与参数值做urlencode的,java实现如下:
String base64Str = Base64.getEncoder().encodeToString(data);
String requestStr = "data=" + URLEncoder.encode(base64Str, "UTF-8");
这里做了urlencode后,+
会被编码为%2B
,再由服务端解码,就会变成原样的+
号。
注:如果是使用apache的HttpClient,可考虑使用
UrlEncodedFormEntity
,它会自动做这个事情。
普通的base64不能直接作为参数值,因为它可能包含+
、/
这两个url不安全的字符,所以base64有个变种叫urlBase64,它将+
、/
替换成了url安全的-
、_
,java实现如下:
String urlBase64Str = Base64.getUrlEncoder().encodeToString(data);
String requestStr = "data=" + urlBase64Str;