共计 10146 个字符，预计需要花费 26 分钟才能阅读完成。
对接外部的一个接口时，发现一个鬼畜的问题，一直提示缺少某个参数，同样的 url，通过 curl 命令访问 ok，但是改成 RestTemplate 请求就不行；因为提供接口的是外部的，所以也无法从服务端着手定位问题，特此记录下这个问题的定位以及解决过程
<!– more –>
I. 问题复现
首先我们是通过 get 请求访问服务端，参数直接拼接在 url 中；与我们常规的 get 请求有点不一样的是其中一个参数要求 url 编码之后传过去。
因为不知道服务端的实现，所以再事后定位到这个问题之后，反推了一个服务端可能实现方式
1. web 服务模拟
模拟一个接口，要求必须传入 accessKey，且这个参数必须和我们定义的一样（模拟身份标志，用户请求必须带上自己的 accessKey, 且必须合法）
@RestController
public class HelloRest {
public final String ALLOW_KEY = “ASHJRK3LJFD+R32SADFLK+FASDJ=”;
@GetMapping(path = “access”)
public String access(String accessKey, String name) {
System.out.println(accessKey + “|” + name) ;
if (ALLOW_KEY.equals(accessKey)) {
return “true”;
} else {
return “false”;
}
}
}
这个接口只支持 get 请求，把参数放在 url 中的时候，很明显这个 accessKey 需要编码
2. 访问验证
在拼接访问 url 时，首先对 accessKey 进行编码，得到一个访问的连接 http://localhost:39531/access?accessKey=ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D&name=yihuihui
下面看下浏览器 + curl + restTemplate 三种访问姿势的返回结果
浏览器访问结果：
curl 访问结果：
restTemplate 访问结果：
@Test
public void testUrlEncode() {
String url = “http://localhost:39531/access?accessKey=ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D&name=yihuihui”;
RestTemplate restTemplate = new RestTemplate();
String ans = restTemplate.getForObject(url, String.class);
System.out.println(ans);
}
看到上面的输出，结果就很有意思了，同样的 url 为啥前面的访问没啥问题，换到 RestTemplate 就不对了？？？
II. 问题定位分析
如果服务端的代码也在我们的掌控中，可以通过 debug 服务端，查看请求参数来定位问题；但是这个问题出现时，服务端不在掌握中，这个时候就只能从客户端出发，来推测可能出现问题的原因了；
接下来记录下我们定位这个问题的 ” 盲人摸象 ” 过程
1. 问题猜测
很容易怀疑问题出在 url 编码后的参数上，直接传这种编码后的 url 参数会不会解析有问题，既然编码之后不行，那就改成不编码试一试
@Test
public void testUrlEncode() {
String url = “http://localhost:39531/access?accessKey=ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D&name=yihuihui”;
RestTemplate restTemplate = new RestTemplate();
String ans = restTemplate.getForObject(url, String.class);
System.out.println(ans);
url = “http://localhost:39531/access?accessKey=ASHJRK3LJFD+R32SADFLK+FASDJ=&name=yihuihui”;
ans = restTemplate.getForObject(url, String.class);
System.out.println(ans);
}
毫无疑问，访问依然失败，模拟 case 如下
传编码后的不行，传编码之前的也不行，这就蛋疼了；接下来怎么办？换个 http 包试一试
接下来改用 HttpClient 访问，看下能不能正常访问
@Test
public void testUrlEncode() throws IOException {
String url = “http://localhost:39531/access?accessKey=ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D&name=yihuihui”;
RestTemplate restTemplate = new RestTemplate();
String ans = restTemplate.getForObject(url, String.class);
System.out.println(ans);
// 创建 httpclient 对象
CloseableHttpClient httpClient = HttpClients.createDefault();
// 创建请求方法的实例，并指定请求 url
HttpGet httpget = new HttpGet(url);
// 获取 http 响应状态码
CloseableHttpResponse response = httpClient.execute(httpget);
HttpEntity entity = response.getEntity();
// 接收响应头
String content = EntityUtils.toString(entity, “utf-8”);
System.out.println(httpget.getURI());
System.out.println(content);
httpClient.close();
}
输出结果如下，神器的一幕出现了，返回结果正常了
到了这一步，基本上可以知道是 RestTemplate 的使用问题了，要么就是操作姿势不对，要么就是 RestTemplate 有什么潜规则是我们不知道的
2. 问题定位
同样的 url，两种不同的包返回结果不一样，自然而然的就会想到对比下两个的实现方式了，看看哪里不同；如果对两个包的源码不太熟悉的话，想一下子定位都问题，并不容易，对这两个源码，我也是不熟的，不过因为巧和，没有深入到底层的实现就发现了疑是问题的关键点所在
首先看的 RestTemplate 的发起请求的逻辑，如下（下图中有关键点，单独看不太容易抓到）
接下来再去 debug HttpClient 的请求链路中，在创建 HttpGet 对象时，看到下面这一行代码
单独看上面两个，好像发现不了什么问题；但是两个对比着看，就发现一个有意思的地方了，在 HttpTemplate 的 execute 方法中，创建 URI 居然不是我们熟知的 URI.create()，接下来就来验证下是不是这里的问题了；
测试方法也比较简单，直接传入 URI 对象参数，看能否访问成功
@Test
public void testUrlEncode() throws IOException {
String url = “http://localhost:39531/access?accessKey=ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D&name=yihuihui”;
RestTemplate restTemplate = new RestTemplate();
String ans = restTemplate.getForObject(url, String.class);
System.out.println(ans);
ans = restTemplate.getForObject(URI.create(url), String.class);
System.out.println(ans);
}
从截图也可以看出，返回 true 表示成功了，因此我们可以圈定问题的范围，就在 RestTemplate 中 url 参数的构建上了
3. 原因分析
前面定位到了出问题的环节，在 RestTemplate 创建 URI 对象的地方，接下来我们深入源码，看一下这段逻辑的神奇之处
通过单步执行，下面截取关键链路的代码，下面圈出的就是定位最终实现 uri 创建的具体对象 org.springframework.web.util.DefaultUriBuilderFactory.DefaultUriBuilder
接下来重点放在具体实现方法中
// org.springframework.web.util.DefaultUriBuilderFactory.DefaultUriBuilder#build(java.lang.Object…)
@Override
public URI build(Map<String, ?> uriVars) {
if (!defaultUriVariables.isEmpty()) {
Map<String, Object> map = new HashMap<>();
map.putAll(defaultUriVariables);
map.putAll(uriVars);
uriVars = map;
}
if (encodingMode.equals(EncodingMode.VALUES_ONLY)) {
uriVars = UriUtils.encodeUriVariables(uriVars);
}
UriComponents uriComponents = this.uriComponentsBuilder.build().expand(uriVars);
if (encodingMode.equals(EncodingMode.URI_COMPONENT)) {
uriComponents = uriComponents.encode();
}
return URI.create(uriComponents.toString());
}
@Override
public URI build(Object… uriVars) {
if (ObjectUtils.isEmpty(uriVars) && !defaultUriVariables.isEmpty()) {
return build(Collections.emptyMap());
}
if (encodingMode.equals(EncodingMode.VALUES_ONLY)) {
uriVars = UriUtils.encodeUriVariables(uriVars);
}
UriComponents uriComponents = this.uriComponentsBuilder.build().expand(uriVars);
if (encodingMode.equals(EncodingMode.URI_COMPONENT)) {
uriComponents = uriComponents.encode();
}
return URI.create(uriComponents.toString());
}
两个 builder 方法提供关键 URI 生成逻辑，根据最后的返回可以知道，生成 URI 依然是使用 URI.create，所以出问题的地方就应该是 uriComponents.encode() 实现 url 编码的地方了，对应的代码如下
// org.springframework.web.util.HierarchicalUriComponents#encode
@Override
public HierarchicalUriComponents encode(Charset charset) {
if (this.encoded) {
return this;
}
String scheme = getScheme();
String fragment = getFragment();
String schemeTo = (scheme != null ? encodeUriComponent(scheme, charset, Type.SCHEME) : null);
String fragmentTo = (fragment != null ? encodeUriComponent(fragment, charset, Type.FRAGMENT) : null);
String userInfoTo = (this.userInfo != null ? encodeUriComponent(this.userInfo, charset, Type.USER_INFO) : null);
String hostTo = (this.host != null ? encodeUriComponent(this.host, charset, getHostType()) : null);
PathComponent pathTo = this.path.encode(charset);
MultiValueMap<String, String> paramsTo = encodeQueryParams(charset);
return new HierarchicalUriComponents(
schemeTo, fragmentTo, userInfoTo, hostTo, this.port, pathTo, paramsTo, true, false);
}
// org.springframework.web.util.HierarchicalUriComponents#encodeQueryParams
private MultiValueMap<String, String> encodeQueryParams(Charset charset) {
int size = this.queryParams.size();
MultiValueMap<String, String> result = new LinkedMultiValueMap<>(size);
this.queryParams.forEach((key, values) -> {
String name = encodeUriComponent(key, charset, Type.QUERY_PARAM);
List<String> encodedValues = new ArrayList<>(values.size());
for (String value : values) {
encodedValues.add(encodeUriComponent(value, charset, Type.QUERY_PARAM));
}
result.put(name, encodedValues);
});
return result;
}
记录下参数编码的前后对比，编码前参数为 ASHJRK3LJFD%2BR32SADFLK%2BFASDJ%3D
编码之后，参数变为 ASHJRK3LJFD%252BR32SADFLK%252BFASDJ%253D
对比下上面的区别，发现这个参数编码，会将请求参数中的 % 编码为 %25, 所以问题就清楚了，我传进来本来就已经是编码之后的了，结果再编码一次，相当于修改了请求参数了
看到这里，自然而然就有一个想法，既然你会给我的参数进行编码，那么为啥我传入的非编码的参数也不行呢？
接下来我们改一下请求的 url 参数，再执行一下上面的过程，看下编码之后的参数长啥样
从上图很明显可以看出，现编码之后的和我们 URLEncode 的结果不一样，加号没有被编码, 我们调用 jdk 的 url 解码，发现将上面编码后的内容解码出来，+ 号没了
所以问题的原因也找到了，RestTemplate 中首先 url 编码解码的逻辑和 URLEncode/URLDecode 不一致导致的
4. 关键代码分析
最后一步，就是看下具体的 url 参数编码的实现方法了，下面贴出源码，并在关键地方给出说明
// org.springframework.web.util.HierarchicalUriComponents#encodeUriComponent(java.lang.String, java.nio.charset.Charset, org.springframework.web.util.HierarchicalUriComponents.Type)
static String encodeUriComponent(String source, Charset charset, Type type) {
if (!StringUtils.hasLength(source)) {
return source;
}
Assert.notNull(charset, “Charset must not be null”);
Assert.notNull(type, “Type must not be null”);
byte[] bytes = source.getBytes(charset);
ByteArrayOutputStream bos = new ByteArrayOutputStream(bytes.length);
boolean changed = false;
for (byte b : bytes) {
if (b < 0) {
b += 256;
}
// 注意这一行，我们的 type 实际上为 org.springframework.web.util.HierarchicalUriComponents.Type#QUERY_PARAM
if (type.isAllowed(b)) {
bos.write(b);
}
else {
bos.write(‘%’);
char hex1 = Character.toUpperCase(Character.forDigit((b >> 4) & 0xF, 16));
char hex2 = Character.toUpperCase(Character.forDigit(b & 0xF, 16));
bos.write(hex1);
bos.write(hex2);
changed = true;
}
}
return (changed ? new String(bos.toByteArray(), charset) : source);
}
if/else 这一段逻辑需要捞出来好好看一下，这里决定了什么字符会进行编码；其中 type.isAllowed 对应的代码为
// org.springframework.web.util.HierarchicalUriComponents.Type#QUERY_PARAM
QUERY_PARAM {
@Override
public boolean isAllowed(int c) {
if (‘=’ == c || ‘&’ == c) {
return false;
}
else {
return isPchar(c) || ‘/’ == c || ‘?’ == c;
}
}
},
// isPchar 对应的相关代码为
/**
* Indicates whether the given character is in the {@code pchar} set.
* @see <a href=”http://www.ietf.org/rfc/rfc3986.txt”>RFC 3986, appendix A</a>
*/
protected boolean isPchar(int c) {
return (isUnreserved(c) || isSubDelimiter(c) || ‘:’ == c || ‘@’ == c);
}
/**
* Indicates whether the given character is in the {@code unreserved} set.
* @see <a href=”http://www.ietf.org/rfc/rfc3986.txt”>RFC 3986, appendix A</a>
*/
protected boolean isUnreserved(int c) {
return (isAlpha(c) || isDigit(c) || ‘-‘ == c || ‘.’ == c || ‘_’ == c || ‘~’ == c);
}
/**
* Indicates whether the given character is in the {@code sub-delims} set.
* @see <a href=”http://www.ietf.org/rfc/rfc3986.txt”>RFC 3986, appendix A</a>
*/
protected boolean isSubDelimiter(int c) {
return (‘!’ == c || ‘$’ == c || ‘&’ == c || ‘\” == c || ‘(‘ == c || ‘)’ == c || ‘*’ == c || ‘+’ == c ||
‘,’ == c || ‘;’ == c || ‘=’ == c);
}
/**
* Indicates whether the given character is in the {@code ALPHA} set.
* @see <a href=”http://www.ietf.org/rfc/rfc3986.txt”>RFC 3986, appendix A</a>
*/
protected boolean isAlpha(int c) {
return (c >= ‘a’ && c <= ‘z’ || c >= ‘A’ && c <= ‘Z’);
}
/**
* Indicates whether the given character is in the {@code DIGIT} set.
* @see <a href=”http://www.ietf.org/rfc/rfc3986.txt”>RFC 3986, appendix A</a>
*/
protected boolean isDigit(int c) {
return (c >= ‘0’ && c <= ‘9’);
}
上面涉及的方法挺多，小结一下需要转码的字符为: =, &
下图是维基百科中关于 url 参数编码的说明，比如上例中的 + 号，按照维基百科的需要转码；但是在 Spring 中却是不需要转码的
所以为啥 Spring 要这么干呢？网上搜索了一下，发现有人也遇到过这个问题，并提给了 Spring 的官方，对应链接为
HierarchicalUriComponents.encodeUriComponent() method can not encode Pchar
官方人员的解释如下
根据 RFC 3986 加号等符号的确实可以出现在参数中的，而且不需要编码，有问题的在于服务端的解析没有与时俱进
III. 小结
最后复盘一下这个问题，当使用 RestTemplate 发起请求时，如果请求参数中有需要 url 编码时，不希望出现问题的使用姿势应传入 URI 对象而不是字符串，如下面两种方式
@Override
@Nullable
public <T> T execute(URI url, @Nullable HttpMethod method, @Nullable RequestCallback requestCallback,
@Nullable ResponseExtractor<T> responseExtractor) throws RestClientException {
return doExecute(url, method, requestCallback, responseExtractor);
}
@Override
@Nullable
public <T> T getForObject(URI url, Class<T> responseType) throws RestClientException {
RequestCallback requestCallback = acceptHeaderRequestCallback(responseType);
HttpMessageConverterExtractor<T> responseExtractor =
new HttpMessageConverterExtractor<>(responseType, getMessageConverters(), logger);
return execute(url, HttpMethod.GET, requestCallback, responseExtractor);
}
注意 Spring 的 url 参数编码，默认只会针对 = 和 & 进行处理；为了兼容我们一般的后端的 url 编解码处理在需要编码参数时，目前尽量不要使用 Spring 默认的方式，不然接收到数据会和预期的不一致
IV. 其他
0. 项目
工程：spring-boot-demo
1. 一灰灰 Blog
一灰灰 Blog 个人博客 https://blog.hhui.top
一灰灰 Blog-Spring 专题博客 http://spring.hhui.top
一灰灰的个人博客，记录所有学习和工作中的博文，欢迎大家前去逛逛
2. 声明
尽信书则不如，以上内容，纯属一家之言，因个人能力有限，难免有疏漏和错误之处，如发现 bug 或者有更好的建议，欢迎批评指正，不吝感激
微博地址: 小灰灰 Blog
QQ：一灰灰 /3302797840
3. 扫描关注
一灰灰 blog
知识星球
