filter中setcharacterencoding对get无效，仅影响post等请求体解码，且须在getparameter()前设置；requestbody需用httpservletrequestwrapper缓存字节以支持多次读取；content-disposition中文文件名应采用filename*+fallback双头方案。
Filter 中 setCharacterEncoding 不生效的常见原因
直接调用 request.setCharacterEncoding("UTF-8") 无效，是因为它只影响后续对 getParameter() 等方法的调用，而请求体（如 POST 表单、JSON）的解码时机更早，且某些容器（如 Tomcat 8.5+）默认不自动解析 body 编码。更关键的是：GET 请求的参数编码由容器在解析 URL 时决定，setCharacterEncoding 对它完全没用。
- GET 参数乱码必须靠容器层面配置（如 Tomcat 的
URIEncoding="UTF-8"）或前端 URL 编码（encodeURIComponent） - POST 表单乱码才适合用 Filter 处理，但必须在调用
getParameter()前完成编码设置 - 如果 Filter 链里有其他 Filter 先读了 request body（比如 Spring 的
ContentCachingRequestWrapper），再设编码就晚了
HttpServletRequestWrapper 如何正确包装 request 以支持多次读取 body
原生 HttpServletRequest 的 input stream 只能读一次，但很多场景（如日志、签名、鉴权）需要反复读 body。这时候得自己继承 HttpServletRequestWrapper，缓存 body 字节，并重写 getInputStream() 和 getReader()。
- 缓存必须在构造函数里一次性读完原始
getInputStream()，并用ByteArrayInputStream包装 - 重写
getContentType()，确保后续逻辑能识别 JSON / form-data 类型 - 不要在包装类里做字符解码（比如 new String(bytes, "UTF-8")），否则会丢失原始字节，导致二进制上传失败
- Spring Boot 用户注意：
ContentCachingRequestWrapper已内置类似逻辑，但默认不启用，需配server.tomcat.relaxed-query-chars或自定义 Filter
public class BodyCachingRequestWrapper extends HttpServletRequestWrapper {
private final byte[] cachedBody;
public BodyCachingRequestWrapper(HttpServletRequest request) throws IOException {
super(request);
InputStream is = request.getInputStream();
this.cachedBody = is.readAllBytes(); // Java 9+
}
@Override
public ServletInputStream getInputStream() {
return new CachedServletInputStream(cachedBody);
}
}
Filter 执行顺序和 Spring MVC 的兼容性问题
Filter 在 Spring MVC 的 DispatcherServlet 之前执行，所以它能拦截所有请求；但如果你用 @WebFilter 注解声明 Filter，又同时用了 Spring 的 WebMvcConfigurer，容易因加载顺序错乱导致编码设置被覆盖。
- 推荐用 Java Config 方式注册 Filter：在配置类中返回
@Bean类型为FilterRegistrationBean，并设setOrder(Ordered.HIGHEST_PRECEDENCE) - 避免在同一个 Filter 里既处理编码又做鉴权或日志——职责混杂会导致调试困难，尤其当 body 被提前读取后，Controller 层拿不到原始数据
- Tomcat 9 默认启用
parseBodyMethods=POST,PUT,PATCH，如果你的接口用 PUT 提交 JSON，记得确认该配置未被禁用 - Spring Boot 2.3+ 默认禁用
HiddenHttpMethodFilter，如果依赖 _method 参数模拟 PUT/DELETE，要手动开启，否则 Filter 可能收不到预期 method
中文路径、文件名下载时的 Content-Disposition 编码陷阱
用 response.setHeader("Content-Disposition", "attachment; filename=中文.pdf") 会在 Chrome/Firefox 下变成乱码或下划线，这不是 Filter 能解决的问题，而是 HTTP 协议本身对 header 字符编码无强制规范。
立即学习“Java免费学习笔记（深入）”；
- 老办法是用
filename*=UTF-8''%E4%B8%AD%E6%96%87.pdf（RFC 5987 格式），但 IE 不支持 - 稳妥做法是 fallback：同时写两个 header：
filename（ASCII 文件名） +filename*（带编码的） - Spring 的
ResponseEntity会自动处理这个双 header，但原生 Servlet 需手动拼接，且filename*的空格必须 URL 编码成%20 - 别在 Filter 里统一改
Content-Disposition—— 下载逻辑应由业务 Controller 明确控制，Filter 做全局编码已经够重了
