Tomcat乱码配置的核心答案是：同时处理请求编码和响应编码，重点改对server.xml、web.xml和catalina.sh这三个文件，并确保JSP页面与代码编码保持一致。
Tomcat为什么一到中文就“方言跑调”
很多朋友遇到乱码第一反应是改编码格式,结果改完重启还是乱，因为Tomcat不是单一编码环境，它涉及连接器接收、请求体解析、响应输出、日志打印四条链路，每一环都可能“说方言”。
URI编码：连接器不认识中文地址
浏览器请求http://localhost:8080/测试?name=张三这类带中文的URL时，Tomcat默认用ISO-8859-1解码，ISO只支持英文字符，中文直接变成一堆问号。
这是Tomcat乱码配置server.xml里最核心的痛点，打开conf/server.xml，找到<Connector>标签，添加或修改属性：
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443"
URIEncoding="UTF-8" />
这里有两个细节容易踩坑：
URIEncoding="UTF-8"只影响URL地址栏参数，不影响POST请求体。- 如果你的Tomcat版本是8.0.36以上，系统检测到文件或环境变量指定了
LANG，可能忽略这个属性，此时建议增加useBodyEncodingForURI="true"，让URI解码跟请求体编码保持一致。
请求体编码：POST参数和表单的“各说各话”
处理POST表单时,Tomcat按request.getCharacterEncoding()判断编码方式，如果代码没显式设置，Tomcat会退回ISO-8859-1，多数乱码发生在这个环节，因为页面的charset=UTF-8只声明了输出，没有告诉Tomcat“用户提交的内容也是UTF-8”。
最简单粗暴的办法是写一个编码过滤器,统一接管所有请求和响应。
响应编码：输出的字在客户端“拼错字”
响应乱码有三个常见原因：
- JSP页面补全了
pageEncoding和contentType，但两者冲突。 - Servlet没有设置
response.setContentType("text/html;charset=UTF-8")。 - 静态HTML文件本身是GBK,却宣告UTF-8，或者反过来。
排查顺序建议是：先确认文件磁盘存储编码，再检查页面声明，最后看服务端过滤器和响应头。
Tomcat乱码配置实操：三份文件一处过滤器
第一步：server.xml强制URI解码
前面已经给了代码,这里再补一个避坑点，如果你的Tomcat前面有Nginx或Apache反代，反向代理转发的URL可能已经被解码成ISO，Tomcat层再做URIEncoding="UTF-8"救不回来，这种情况需要检查反代配置，比如Nginx的proxy_pass后面不要带多余参数。
第二步：web.xml声明全局编码过滤器
在Web应用
WEB-INF/web.xml中，注册一个字符编码过滤器，你不必自己写类，Tomcat自带CharacterEncodingFilter是Spring框架的类，原生Tomcat没有内置，务实做法是自定义一个简单过滤器：
package com.demo.filter;
import javax.servlet.;
import javax.servlet.annotation.WebFilter;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.io.IOException;
@WebFilter("/")
public class CharacterSetFilter implements Filter {
@Override
public void init(FilterConfig filterConfig) throws ServletException {
}
@Override
public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
throws IOException, ServletException {
request.setCharacterEncoding("UTF-8");
response.setCharacterEncoding("UTF-8");
chain.doFilter(request, response);
}
@Override
public void destroy() {
}
}
然后在web.xml中注册，或用@WebFilter注解自动扫描，这样做的好处是：不管前端页面是GET还是POST，进入Servlet前编码已经统一为UTF-8。
如果你的项目用的是Spring Boot内嵌Tomcat，则可以在启动类加一个CharacterEncodingFilter的Bean，效果等价。
第三步：catalina.sh设置文件系统编码
控制台或日志里的乱码,根源往往不是Tomcat业务代码，而是JVM读取文件时用的平台默认编码，Windows环境下默认是GBK，而Linux是UTF-8。
编辑bin/catalina.sh（Windows对应catalina.bat），找到JAVA_OPTS所在位置，加上：
JAVA_OPTS="$JAVA_OPTS -Dfile.encoding=UTF-8 -Dsun.jnu.encoding=UTF-8"
file.encoding控制JVM读写文件时的编码，sun.jnu.encoding控制命令行参数和URL的编码，两个一起设，能避免Tomcat日志出现“口”形字符。
第四步：JSP页面声明统一
每个JSP顶部的<%@ page %>指令要写完整，不要只写pageEncoding而不写contentType，也不要让两者互相矛盾，标准写法：
<%@ page contentType="text/html;charset=UTF-8" language="java" pageEncoding="UTF-8" %>
同时检查JSP文件本身的保存编码,Eclipse和IDEA默认可能不同，IDEA通常在右下角能看到文件编码状态，统一改成UTF-8后重新保存。
Tomcat控制台乱码配置：区分三类日志
Windows下控制台和IDEA输出乱码
Windows控制台默认代码页是GBK,而Tomcat日志如果输出UTF-8字符，直接打印到控制台就会变乱码。
解决办法之一是改conf/logging.properties中的编码设置：
java.util.logging.ConsoleHandler.encoding = GBK
这样控制台读取日志时自动按GBK解码,乱码问题迎刃而解，但要注意，Linux环境下这个值应保持为UTF-8，不能一刀切。
如果你在IDEA或Eclipse里运行Tomcat,控制台编码跟随IDE设置，IDEA中依次打开Help -> Edit Custom VM Options，追加：
-Dfile.encoding=UTF-8重启IDE后生效,多数情况下，IDEA控制台乱码配置tomcat时，改IDE的全局编码比改Tomcat配置更有效。
日志文件里的乱码
logs/.log文件如果打开乱码，本质是文件编码和查看工具编码不匹配，例如catalina.out在Windows下写中文时，受file.encoding影响，如果之前没设UTF-8，文件就是GBK，你可以用记事本或Notepad++查看，将查看编码切到GBK，确认文件实际编码后再决定是否统一。
命令行启动时中文参数乱码
这个场景常见于执行startup.sh时脚本路径或参数带中文，除了前面提到的sun.jnu.encoding，还需要检查Windows环境变量JAVA_TOOL_OPTIONS是否有残留，有则清理。
不同场景下的Tomcat乱码配置清单
GET请求参数乱码：优先查server.xml
地址栏直接传中文,或Ajax GET方式传中文，乱码根源几乎都在URIEncoding，配置为UTF-8后重启Tomcat即可。
POST表单乱码：过滤器兜底
POST乱码最稳定,用过滤器统一设置request和response的编码即可，注意一个常见坑：Ajax POST的Content-Type如果是application/x-www-form-urlencoded; charset=UTF-8，Tomcat会尊重这个编码，但若你手动设置了错误编码，反而会覆盖正确值。
响应JSON乱码：检查Spring与Jackson
使用Spring MVC返回JSON时，除了过滤器，还要确认消息转换器使用UTF-8：
<mvc:annotation-driven>
<mvc:message-converters>
<bean class="org.springframework.http.converter.StringHttpMessageConverter">
<property name="defaultCharset" value="UTF-8"/>
</bean>
</mvc:message-converters>
</mvc:annotation-driven>
数据库存入的数据乱码
Tomcat侧编码全改对了,查询数据库出来的中文还是乱，就需要检查数据库连接池参数，JDBC连接串中务必追加：
?characterEncoding=UTF-8&useUnicode=true同时保证数据库表本身字符集为UTF-8或utf8mb4，行业共识认为，MySQL中utf8只支持部分字符，建议直接上utf8mb4。
下载文件名乱码
响应头设置Content-Disposition时，中文文件名需要用URLEncoder编码，或用RFC 5987的filename标准，简单做法：
response.setHeader("Content-Disposition",
"attachment;filename=" + java.net.URLEncoder.encode("中文文件.txt", "UTF-8"));
验证配置是否生效，用两个命令
第一,查看响应头，确认Content-Type包含charset=UTF-8。
第二,在Linux下用curl测试：
curl -I -H "Accept-Charset: UTF-8" http://localhost:8080/你的应用
观察返回头,如果仍显示ISO-8859-1，说明过滤器没生效或Servlet手动设置了别的编码，检查代码里是否有resp.setContentType覆盖了过滤器设置。
一个真实案例：改完所有配置还乱
我曾经迁移一个老旧项目,Tomcat从7升到9，所有配置都按上面改了，页面中文依然乱，最后发现是web.xml版本声明太老，<web-app>版本是2.3，导致Tomcat以旧规范解析，@WebFilter注解没有生效，升级web.xml到3.1版本并对齐Servlet版本后，乱码消失。
这类问题提示我们：Tomcat乱码配置不是单点修改，而是编码链路的全程对齐，从浏览器请求头、到Tomcat连接器、到Servlet过滤器、再到JSP或JSON输出，每一处都是UTF-8，才能真正不出乱码。
配置完成后,记得重启Tomcat，并清空浏览器缓存，有时浏览器会在旧缓存中复用之前的编码声明，导致页面显示乱码但源码是正常的，彻底验证的方法是请求一次URL，查看响应头，不依赖浏览器本地缓存。
Q&A：Tomcat乱码配置常见疑问
Tomcat乱码配置server.xml后，为什么地址栏中文正常了但表单还是乱？
因为URIEncoding只影响URI部分，表单POST请求体走的是另一个编码路径，必须用过滤器或request.setCharacterEncoding("UTF-8")来处理，在doPost方法开头手动设置编码，也能解决单点问题。
Tomcat控制台乱码配置了catalina.sh和logging.properties仍然乱，怎么办？
检查启动Tomcat的终端工具,Windows下如果双击startup.bat启动，控制台窗口代码页可能仍是GBK，运行chcp 65001切换到UTF-8后再启动，如果用的是SecureCRT或XShell连接远程Linux，会话编码改为UTF-8，问题通常随之消失。
调用第三方接口返回中文乱码，算是Tomcat配置问题吗？
不算,这是HTTP客户端读取响应时使用了错误解码，Java代码中请求第三方接口时，需要根据响应头Content-Type的charset解析字节流，如果对方返回GBK而你用UTF-8读，就会乱码，解决办法是使用byte[]解码时手动指定编码，或使用HttpClient时设置正确的ContentType解析规则。
Tomcat乱码配置的核心原则是编码链路全程统一，先改好server.xml和catalina.sh，再补上过滤器，最后检查页面声明与数据库连接，做到这几步，绝大多数中文乱码都能在十分钟内定位并修复。