基于公司的业务需求，在SpringCloud Gateway组件的基础上，写了一个转发服务，测试开发阶段运行正常，并实现初步使用。但三个月后，PostMan请求接口，返回异常，经排查，从日志中获取到转发响应的结果为乱码：
跟踪日志：
转发到目标接口，响应结果已乱码。一般排查的思路是，查看请求方和响应方的编码格式是否一致，打印请求方的编码格式为UTF-8,响应服务的编码格式也是UTF-8。
以上说明编码格式没有问题。上网去找“gateway响应结果乱码”的相关文章，大多数会提供解决方案：
DataBufferFactory dataBufferFactory = new DefaultDataBufferFactory();
DataBuffer join = dataBufferFactory.join(dataBuffers);
byte[] content = new byte[join.readableByteCount()];
join.read(content);
// 释放掉内存
DataBufferUtils.release(join);
String str = new String(content, Charset.forName("UTF-8"));
originalResponse.getHeaders().setContentLength(str.getBytes().length);
System.out.println(str);
return bufferFactory.wrap(str.getBytes());
这段关键代码，在我的响应结果包装过滤器是有的，如下：
/**
* 获取到解码方的response,验签--->重新封装--->加签
* 通过 DataBufferFactory 解决响应体分段传输问题。
*/
private ServerHttpResponseDecorator verifyRePackageSignatureResponse(ServerWebExchange exchange, String jmf_decode_url, String route_privateKey, String jmf_publicKey) {
ServerHttpResponse response = exchange.getResponse();
log.debug("R:给响应结果response设置编码格式----START----");
response.getHeaders().add("Content-Type","application/json;charset=UTF-8");
log.debug("R:给响应结果response设置编码格式-----END-----");
DataBufferFactory bufferFactory = response.bufferFactory();
return new ServerHttpResponseDecorator(response) {
@Override
public Mono<Void> writeWith(Publisher<? extends DataBuffer> body) {
if (body instanceof Flux) {
// 获取响应类型，如果是 json 就打印
String originalResponseContentType = exchange.getAttribute(ServerWebExchangeUtils.ORIGINAL_RESPONSE_CONTENT_TYPE_ATTR);
log.debug("响应类型为originalResponseContentType:{}",originalResponseContentType);
if (RequestResponseUtil.isJson(originalResponseContentType)) {
Flux<? extends DataBuffer> fluxBody = Flux.from(body);
return super.writeWith(fluxBody.buffer().map(dataBuffers -> {
// 合并多个流集合，解决返回体分段传输
DataBufferFactory dataBufferFactory = new DefaultDataBufferFactory();
DataBuffer join = dataBufferFactory.join(dataBuffers);
byte[] content = new byte[join.readableByteCount()];
join.read(content);
// 释放掉内存
DataBufferUtils.release(join);
// 正常返回的数据
String rootData = new String(content, StandardCharsets.UTF_8);
log.debug("R:正常返回的数据rootData为:{}", rootData);
//使用枚举 + 工厂 + 策略模式（第二版）
String newQqtBodyJson = null;
try {
newQqtBodyJson = DecoderSignStrategyContext.zwmVerifySignResponse(rootData, jmf_decode_url, route_privateKey, jmf_publicKey);
log.debug("R:【码路由服务】经具体策略处理，得到结果newQqtBodyJson为:{}", newQqtBodyJson);
} catch (Exception e) {
log.error("R:【码路由服务】解码方返回结果验签异常:{}", e);
throw new VerifySignException(StaticVar.FAIL_10020015, "R:【码路由服务】解码方返回结果验签异常");
}
byte[] respData = newQqtBodyJson.getBytes();
//byte[] respData = newQqtBodyJson.getBytes(StandardCharsets.UTF_8);
byte[] uppedContent = new String(respData, Charset.forName("UTF-8")).getBytes();
return bufferFactory.wrap(uppedContent);
}));
} else {
log.error("响应结果异常");
throw new ProcessHandleException(StaticVar.FAIL_10020015, "R:【码路由服务】解码方返回结果异常,非法JSON");
}
}
// if body is not a flux. never got there.
return super.writeWith(body);
}
};
}因此不是代码的问题。又找到了一篇文章，解决了PostMan请求的问题。
https://bbs.csdn.net/topics/399102026/close
如上所述，在PostMan请求的headers中去掉Accept-Encoding,请求成功：
至此，PostMan请求乱码的问题已解决。但事情似乎没有那么简单，接下来，使用手机模拟扫码，请求码路由服务，又出现了乱码，扫码结果页面，返回结果:
查看日志，乱码如下：
排查问题进入瓶颈期，有些烦躁了，必须冷静下来，重新捋一下代码，同时也在想，既然和PostMan请求存在同样的问题，是不是在请求头中默认会有一个Accept-Encoding属性，从而导致了乱码，根据这个思路，在自定义的请求转发过滤器中，发现了以下代码：
由于在请求转发的逻辑中，重新构建了一个request请求的同时，重新创建了一个请求头headers,它在重新构建的时候默认会有一个accept-encoding属性，看到这一行代码时，正印证了以上我的猜想，问题已经找到了，将其置为空字符串即可（注意：不能使其为null,也不能remove这个属性，会报错）。
将headers的accept-encoding属性置为空字符串，并添加注释如下：
// 定义新的消息头
HttpHeaders headers = new HttpHeaders();
//System.out.println("headers = " + headers); //查看重新定义消息头的内容
headers.putAll(exchange.getRequest().getHeaders());
// 由于修改了传递参数，需要重新设置CONTENT_LENGTH，长度是字节长度，不是字符串长度
int length = bodyStr.getBytes().length;
log.debug("bodyStr长度为:{}",length);
headers.remove(HttpHeaders.CONTENT_LENGTH);
// 设置CONTENT_TYPE
if (StringUtils.isNotBlank(contentType)) {
headers.set(HttpHeaders.CONTENT_TYPE, contentType);
}
String jmf_decode_url = request.getURI().toString();
String qqtBodyJsonStr = JSONUtils.toString(bizPackage);
//request.mutate().header(HttpHeaders.CONTENT_LENGTH, Integer.toString(bodyStr.length())); //报错JSON parse error JsonEOFException，长度必须为字节的长度
request.mutate().header(HttpHeaders.CONTENT_LENGTH, Integer.toString(length));//成功，解决JSON parse error JsonEOFException
/**
* 乱码现象：请求响应结果乱码
* 解决过程分为PostMan请求和手机端App扫码请求：
* （1）、PostMan请求响应乱码解决：
* PostMan请求的headers中默认会有"Accept-Encoding"属性，值为"gzip, deflate, br",导致响应结果乱码
* 去掉Accept-Encoding后请求正常。
*
* （2）、手机端App扫码请求乱码解决：
* 在HttpRequestSignForwardGatewayFilter中定义新的消息头，headers中默认会有"accept-encoding"属性，
* 值为"gzip, deflate, br", 添加代码"request.mutate().header("accept-encoding",""); "解决乱码
*
* 注意: 创建headers对象默认会生成“accept-encoding=‘gzip, deflate, br‘ ”属性，此处必须将accept-encoding
* 置为空字符串（置为null会报错），否则使用默认值会导致响应结果乱码。
* 说明: 测试开发阶段未发生此问题，第三方检测时演示出现此问题，这个可能是gateway内部的问题，尚未可知。
*
* 经测试，这种方式已解决了：手机端APP扫码和PostMan响应结果乱码的问题（PostMan请求时可以不用刻意去掉Accept-Encoding，
* 也可请求成功）
*
*/
request.mutate().header("accept-encoding","");重启后，部署后问题得到解决。这个问题在测试开发阶段没有暴露出来，按理说应该早暴露了，但现实情况就是这么诡异，这可能是Gateway内部的bug，尚未可知。
希望此文对遇到同样问题的小伙伴有所帮助和启发，望了解gateway内部原理机制的大神，参与讨论。
乱码问题已排查并处理结束，完结，撒花！
参考文章：
RestTemplate请求头accept-encoding导致乱码_resttemplate 乱码_AE86Jag的博客-CSDN博客
https://bbs.csdn.net/topics/399102026/close
在此感谢文章作者！
710
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
