背景
业务方经过某些业务处理之后，带过来了一系列参数。其中，有个url参数供回调使用，但这个url经业务方处理后很特殊，带过来回调时频频出错，无法正常回调给业务方。于是，通过分析部分源码，剖析一下回调的流程。
编码 解码
说到url的回调，很容易联想到decode、encode，即编码解码操作。
通常来说，需要编码操作即意味着不适合直接传输，某些字符可能有歧义，如中文、特殊字符等等。
而通过编码之后(如 utf-8)，传输给服务端，服务端自行解码，便不会出现一系列乱码问题。
说明
按照如上所说，业务方带过来了处理后的url，另附上说明，url无需解码，直接回调即可，但事情往往没那么顺利。不管是使用spring5 webclient，还是restTemplate以get请求回调业务方，均会出错。由于最终使用了restTemplate解决了问题，对此本次剖析一下restTemplate。
注：WebClient同样可以解决问题，剖析restTemplate的因由在于综合分析了项目的引用和耦合度，不适合改动webclient模块，故而拓展了restTemplate。
剖析
-
先写个极其简单的单测入口，进行RestTemplate的源码分析。
- 紧接着集中分析RestTemplate类
-
请求头、请求体是由RequestCallback来处理的，请求结果是由ResponseExtractor来处理。
-
RestTemplate默认已经初始化添加了许多对象读写转换器。
-
进入execute这个重要的方法继续分析。
- 可以看出，先用UriTemplateHandler构建URI，再走关键逻辑。
-
UriTemplateHandler build URI
-
通过构造函数的初始化，可以看到使用的是默认builder工厂
-
从类继承图可以看出DefaultUriBuilderFactory实现了UriBuilderFactory，继承了UriTemplateHandler
-
expand(String var1, Object... var2)是UriTemplateHandler接口的方法
-
继续分析UriTemplateHandler接口expand方法源码
-
到这里我们可以发现DefaultUriBuilderFactory默认builder工厂存在一个内部类DefaultUriBuilder
-
接着进入分析一下UriComponentsBuilder类的源码，从类名可以猜想到这个UriComponentsBuilder构建器可能用于创建UriComponents实例
-
顾名思义，UriComponents包含了构成URI的组件，以及一系列的getter and setter方法
-
继续着刚才初始化UriComponentsBuilder的方法
-
符合了内置的url pattern之后继续构建UriComponentsBuilder，通过构造器可以看出默认字符集是utf-8
-
可以清晰看出初始化之后的构建器
-
接下来出来外层的包裹，分析build方法
-
分析DefaultUriBuilderFactory build的过程
划重点！！！
因为uriVariableValues为空，不关心这个expand方法，此时注意build方法。
-
可以看到，build UriComponents，有个encoded参数，默认为false
先不透露具体细节，只需先记住构建这次请求的UriComponents，encoded参数为false！！！
接着看encoded参数为false，会影响到哪些参数值
由encodedfalse可得到UriComponentsBuilder.EncodingHint为NONE
public UriComponents build(boolean encoded) {
return this.buildInternal(encoded ? UriComponentsBuilder.EncodingHint.FULLY_ENCODED : (this.encodeTemplate ? UriComponentsBuilder.EncodingHint.ENCODE_TEMPLATE : UriComponentsBuilder.EncodingHint.NONE));
}
-
再接着就是构造HierarchicalUriComponents
HierarchicalUriComponents uric = new HierarchicalUriComponents(this.scheme, this.fragment, this.userInfo, this.host, this.port, this.pathBuilder.build(), this.queryParams, hint == UriComponentsBuilder.EncodingHint.FULLY_ENCODED);
- 最后可以看到HierarchicalUriComponents.EncodeState为RAW
这里划重点！！！
-
继续看外层的包裹，构建完之后的UriComponents
-
继续分析createUri，由于匹配到是默认的URI_COMPONENT，则走encode方法
-
本次剖析很重要的一个方法，终于要接近问题的真相了！！！
-
从上个提示重要的剖析点得知，构建UriComponents，encoded参数默认为false，进而从源码可得知，HierarchicalUriComponents.EncodeState的值为RAW。那么就会走下面的encodeUriComponent的方法（至于怎么encode暂不在分析范围内，看源码貌似是用字节流操作来encode，有兴趣可以阅读）
-
接着对segment，queryParams等进行编码
-
参数编码的细节，勾出来的是Java8的Function，实现就不贴了，源码比较简单
-
最终，通过比对参数ext_info的值，便得知参数被主动encode了
解决方案
ok~~~
分析完后，知道问题的根源在不该被encode的URL却在restTemplate的深处被动encode了，因此导致了回调的失败。既然明确问题所在，也分析过源码，解决起来就很简单了。如下：
构建UriComponentsBuilder，builder构建时传入encoded值为true，并转URI形式入参，问题解决。
枚举状态总结
为了帮助大家记忆，简单理一下状态。
- UriComponentsBuilder.EncodingHint
UriComponentsBuilder构建器有个枚举EncodingHint，UriComponentsBuilder构建时encoded默认为false。
- 若encoded为false，则看有没有提供另外的encodeTemplate；
若有则值为ENCODE_TEMPLATE，否则为NONE - 若encoded为true时，值为FULLY_ENCODED
- HierarchicalUriComponents.EncodeState
HierarchicalUriComponents组件有个枚举EncodeState，其值的影响在于以上的EncodingHint。
源码的encode过滤也在于这个组件的EncodeState值！！！
- 若EncodingHint为FULLY_ENCODED，则EncodeState为FULLY_ENCODED
- 若EncodingHint不为FULLY_ENCODED（ENCODE_TEMPLATE或NONE），则EncodeState为RAW
总结
- 多多阅读源码，只会使用还远远不够。
- 带着问题阅读源码，是种不错的学习方式。
