一提到 Tomcat 乱码谁没被折腾过几回。页面上突然冒出“锟斤拷”控制台上满屏中文变成“????”GET 参数传过去打开一看是“浣犲ソ”下载文件名更是直接变成一串下划线……我最早遇到这些时也以为是业务代码写错了后来排查的次数多了才明白Tomcat 乱码几乎从来不是某一个参数的错而是文件编码、JVM 编码、HTTP 报文编码和终端代码页这四层没有对齐。这篇文章是我这几年处理 Tomcat 中文乱码的一次完整总结从原理到实操都有适合刚接触 Tomcat、被中文乱码折磨到头痛的开发者也适合已经调了半天乱码但始终没找到根因的老手直接对照排查。乱码问题最让人头疼的地方在于它不是每次必现环境和部署方式一变就换花样。在 IDEA 里跑得好好的丢到 Linux 服务器就乱Windows 下用 cmd 启动乱切到 PowerShell 又是另一种乱。如果你没理清这里面的转换链路就只能瞎试——改一个参数重启一次碰运气。这篇文章我把常见场景、版本差异和可复制的配置都列出来你看完应该能少走很多弯路。1. 乱码的真正成因四个“编码开关”必须对齐1.1 从字节流到字符串只要翻译错一次就乱Java 字符串本身是 Unicode 字符集这没问题。但网络传输、文件保存、终端显示都不是直接把 Unicode 字符丢出去的而是要先把它转成字节序列。问题就出在这个“转”字上同一个中文字符用 UTF-8 编码出来是 3 个字节用 GBK 编码出来是 2 个字节用 ISO-8859-1 编码出来直接变成问号。接收方拿到字节后还需要按某个字符集把字节再解析回字符串。发送时用一种编码接收时用另一种解码必然乱。你可以把字符集想象成快递箱的规格UTF-8 是国际通用大箱GBK 是国内局部使用的中箱ISO-8859-1 是只允许放英文字母的小箱。发货的人用中箱装好东西收货的人却按国际大箱的规则去拆盖子对不上里面的中文就散架了。Tomcat 项目里至少存在四层箱规源码和页面文件的保存编码也就是 IDEA、VSCode、记事本写入磁盘时用的字符集JVM 启动后的默认编码file.encodingTomcat 处理 HTTP 请求和响应时用到的URIEncoding、request.setCharacterEncoding、response.setContentType里的 charset控制台、日志文件、操作系统代码页的显示编码。这四层只要有一层不一致就可能在某个环节出现乱码。更麻烦的是很多乱码不是当场出现而是经过一次错误的字节转字符串后把错误结果又用另一个编码写回文件或者送往浏览器层层套娃最后显示出来就是“锟斤拷”“”这种完全不可逆的鬼东西。1.2 Tomcat 8 为什么也会乱码默认值不是万能的不少人以为 Tomcat 8 开始默认URIEncodingUTF-8就不会乱码了然后搜“tomcat8中文乱码”搜出一堆文章。这个认知需要修正。Tomcat 8 的 HTTP 连接器确实默认把 URI 中的字节按 UTF-8 解码但请求体不一定。Tomcat 8 的useBodyEncodingForURI默认是falsePOST 表单里的中文到底按什么解码取决于应用代码里有没有在读取参数之前调用request.setCharacterEncoding(UTF-8)。如果没有这一句容器可能退回请求头里的 Content-Type charset或者用 ISO-8859-1 兜底。还有一层经常被忽略JVM 的默认编码。在 JDK 17 及更早版本里file.encoding是根据操作系统区域设置的。中文 Windows 下通常是 GBKLinux 下可能是 UTF-8这就解释了为什么同一个 WAR 包在本地 Windows 上正常、部署到 Linux 上就乱或者反过来。所以光调 Tomcat 的server.xml还不够JVM 的-Dfile.encoding必须一起管。1.3 乱码不是“环境问题”是字节序列被错误字符集解读的结果我经常在技术群里看到有人把乱码总结为“环境问题”然后重装系统、换电脑、换 IDE其实没必要。乱码本质上是一道确定性题目只要你知道源字符串是用什么字符集编码成字节的又知道目标环境按什么字符集解析这些字节你就能推导出该怎样修复。举个例子你在浏览器地址栏输入?name张三浏览器按 UTF-8 编码后发到 Tomcat。如果 Tomcat 连接器的URIEncodingISO-8859-1它就会把 UTF-8 的 6 个字节每字节解析成 6 个拉丁字符。你再把这些字符存进数据库数据库连接又用 UTF-8 转回去出来的就是“寮犱笁”这种乱码。反过来如果你在页面上看到了“寮犱笁”多半就是 UTF-8 字节被 GBK 或 ISO-8859-1 解码后的结果。记住了这些对应关系后面排查会快很多。2. 我的实战排查思路先问乱码出现在哪一层2.1 页面显示乱码先抓响应头里的 charset页面中文乱码是最常见、也最好处理的一类。第一件事不是看代码而是看服务器到底返回了什么 Content-Type。你可以用浏览器开发者工具看响应头也可以直接在命令行敲curl -I http://localhost:8080/your-app/index.html重点看这一行Content-Type: text/html;charsetUTF-8如果charset是ISO-8859-1那就算页面meta charsetUTF-8写得再对也可能乱因为 HTTP 响应头里的优先级更高。如果完全没有charset浏览器就会自己去猜猜错就乱。对应到代码上几个关键点静态 HTML 页面必须保证文件本身保存为 UTF-8并且head里有meta charsetUTF-8。Servlet 或 Filter 里调用response.setContentType(text/html; charsetUTF-8)这要在写响应体之前执行。Spring MVC 接口方法RequestMapping(value /xxx, produces text/html; charsetUTF-8)。JSP 页面保证% page contentTypetext/html; charsetUTF-8 pageEncodingUTF-8 %。排查时有个技巧先在浏览器里直接访问一张包含中文的静态页面如果静态页面正常、动态接口乱问题就在后端响应编码如果静态页面本身就乱那优先检查文件保存编码和响应头。这样能快速缩小范围不用每次都从头拆。2.2 控制台输出乱码System.out 和日志要分开看很多人在 IDEA 里跑 Tomcat控制台中文输出变成“????”第一反应是去改server.xml结果没用。控制台乱码和 HTTP 响应乱码根本是两条链路前者是 JVM 把字符串转成字节输出到控制台控制台再按自己的代码页显示后者是 HTTP 响应体里的字节被浏览器解码。IDEA 的 Run 窗口通常默认使用 UTF-8如果你用中文 WindowsIDEA 自动检测可能会把file.encoding设成 GBKTomcat 启动时又把系统默认编码带进去输出到 IDEA 控制台就乱了。解决办法分三步在catalina.bat或setenv.bat里给 JVM 加参数-Dfile.encodingUTF-8。在 IDEA 的Help - Edit Custom VM Options里加上-Dfile.encodingUTF-8重启 IDEA。在 IDEA 设置Editor - File Encodings里把 Global Encoding、Project Encoding、Default encoding for properties files 都设为 UTF-8。Windows 命令行cmd和 PowerShell 的情况类似。Tomcat 在中文 Windows 下用 cmd 启动时cmd 默认代码页是 936GBK如果 JVM 输出 UTF-8 字节cmd 就会显示成乱码。你可以先执行chcp 65001切到 UTF-8 代码页再启动 Tomcat。PowerShell 还多一重乱最好在启动前设置[Console]::OutputEncoding [System.Text.Encoding]::UTF8另外要注意System.out.print和printf系列方法输出的中文乱码本质和 C 语言里的printf输出乱码一样都是因为输出字节流与终端字符集不一致不是 Java 本身的 bug。你可以把printf的输出先写成System.out.println(中文)然后分别用 GBK 和 UTF-8 终端跑一遍很快就能确认。2.3 GET 和 POST 参数乱码一个改连接器一个改应用代码请求参数乱码分两种GET 和 POST 的处理位置不一样。GET 请求的中文主要放在 URL 里。Tomcat 拿到 URL 后会按连接器的URIEncoding解码。Tomcat 8 之前默认是ISO-8859-1所以老项目几乎都要在server.xml里专门加URIEncodingUTF-8。Tomcat 8 虽默认 UTF-8但如果你用了反向代理、特殊客户端或者项目里混用了旧配置依然建议显式写清楚Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8 useBodyEncodingForURItrue /useBodyEncodingForURItrue的意思是如果请求体里有表单参数它们的编码方式也按 URI 的编码来。这个配置适合“GET、POST 混合传参且统一用 UTF-8”的场景。要注意它并不是所有情况都推荐如果你的项目历史包袱重、表单用到特殊编码修改前最好先确认前后端约定。POST 请求的参数放在请求体里连接器的URIEncoding管不到它。正确做法是在读取第一个参数之前调用request.setCharacterEncoding(UTF-8);最省事的方案是写一个字符编码 Filter统一对所有请求设置编码。这个 Filter 也必须放在其他业务 Filter 之前否则一旦别的 Filter 先读了参数setCharacterEncoding 就不再生效了。后面我会给出可以直接复制的 Filter 代码。2.4 上传下载文件名乱码不要只依赖 Content-Disposition文件上传下载属于 Tomcat Web 应用里最隐蔽的乱码场景因为它跨了浏览器、HTTP 头和操作系统文件系统三层。我遇到过很多次上传中文文件名到服务器后目录里看到的是乱码下载时浏览器保存的文件名又变成%E5%BC%A0%E4%B8%89.pdf这种编码串。上传文件名乱码先检查 Tomcat 对 request 的编码是否已经设置成 UTF-8再检查 Servlet 里拿文件名的方式。如果用的是new String(fileName.getBytes(ISO-8859-1), UTF-8)那是几十年前解决乱码的土办法现代 Tomcat 下反而可能二次搞乱建议直接统一 UTF-8 编码。下载文件名乱码核心是Content-Disposition响应头。老标准只支持 ASCII 文件名所以中文会被替换成?或乱码。现在推荐用 RFC 5987 格式String fileName URLEncoder.encode(项目说明.pdf, UTF-8).replaceAll(\\, %20); response.setHeader(Content-Disposition, attachment; filename*UTF-8 fileName);浏览器看到filename*后会按 UTF-8 解码大多数现代浏览器都能正确保存中文文件名。如果还不行就加一个filenamedownload.pdf做兜底但注意把filename放在后面因为浏览器对前面的字段优先级更高。另外如果你在 Linux 服务器上看到上传后的目录里文件名乱码先检查是不是 Linux 文件系统把 UTF-8 文件名显示成???这跟 Tomcat 没关系而是系统 locale 不是 UTF-8。临时可以使用ls --show-control-chars看或者用convmv批量转换文件名。我处理过“linux 解压文件乱码”的问题原理一样zip 包里的文件名如果是 GBK 编码普通unzip会按 UTF-8 解码必须用unar或者指定编码解压unzip -O CP936 yourfile.zip如果你的 Tomcat 后台管理页上传 WAR 包时受到来源 IP 限制那是另一码事属于安全控制和文件本身编码无关但 WAR 包在服务器上解压后的文件名乱码也可以用上面的思路排查。3. Tomcat 版本与 JDK 版本差异为什么换环境就乱3.1 Tomcat 8、9、10、11 的编码默认值变化Tomcat 8 把URIEncoding从ISO-8859-1改成了UTF-8这是它比 Tomcat 7 对中文用户友好得多的主要原因。如果你还在维护 Tomcat 7 以下的老项目一定要在连接器上显式加上URIEncodingUTF-8。Tomcat 9 和 Tomcat 8 在这个问题上的行为基本一致。Tomcat 10 之后Servlet API 的包名从javax.servlet变成了jakarta.servlet所以从旧版本升级项目时如果 Filter 里还写着javax.servlet的包启动时会直接报ClassNotFoundException而不是慢慢变成乱码。也就是说迁移 Tomcat 10 时“编码 Filter 代码要同步换包名”这件事必须记得做。另外Tomcat 内置的日志组件默认使用 UTF-8但logging.properties里可能被改了。我曾经见过有人为了给日志文件控制大小把 console handler 的编码改成 GBK结果运维平台怎么都显示乱码。建议直接保持默认或者显式设置java.util.logging.ConsoleHandler.encoding UTF-8 java.util.logging.FileHandler.encoding UTF-83.2 JDK 默认 file.encoding 的演进JDK 18 是个分水岭热搜里能看到“jdk 25 tomcat 安装配置”这样的词可见现在大家用的 JDK 版本越来越新。JDK 18 通过 JEP 400 把file.encoding默认值改成了 UTF-8之前版本是按操作系统本地化决定的。这意味着JDK 17 及更早中文 Windows 下file.encoding基本是GBKLinux 下如果是zh_CN.UTF-8locale 则是UTF-8。JDK 18无论 Windows 还是 Linux默认都是UTF-8乱码概率大幅下降。但这不是说新 JDK 下面不会乱。如果你从 JDK 8 升级到 JDK 17旧代码里可能到处是new String(bytes, GBK)、FileReader.reader按系统编码读文件之类的隐式假设。升级后系统编码从 GBK 变成 UTF-8这些地方就会出问题。所以新旧版本切换时我建议在同一套配置里显式指定-Dfile.encodingUTF-8让所有环境行为一致而不是依赖 JDK 默认值。3.3 安装配置 Tomcat 时顺手做对的四件事热搜里“tomcat安装及配置教程”“idea配置tomcat”“vscode配置tomcat”这类词常年热门说明很多人起步阶段就被乱码绊倒。以我经验在第一次把 Tomcat 跑起来之前先顺手做四件事后面能省一大半乱码排查时间在 Tomcat 的conf目录下创建setenv.batWindows或setenv.shLinux把 JVM 编码参数写进去。打开conf/server.xml检查 HTTP 连接器的URIEncoding是否显式设为 UTF-8。打开conf/logging.properties确认 ConsoleHandler 和 FileHandler 的编码是 UTF-8。确保你的源码文件、pom.xml、web.xml都按 UTF-8 保存IDEA 或 VSCode 里不要出现“自动转成 GBK 保存”的情况。这四步做完Tomcat 本身就是一个“UTF-8 一致”的运行环境剩下的问题多半出在应用代码和外部系统交互上。4. 一份可直接复制的乱码解决工具箱4.1 server.xml 的最小必备配置修改conf/server.xml里的 HTTP Connector下面这份配置是我在项目里反复使用的模板Connector port8080 protocolHTTP/1.1 connectionTimeout20000 redirectPort8443 URIEncodingUTF-8 useBodyEncodingForURItrue /如果你同时配置了 AJP 连接器也要检查 AJP 那一行的 URIEncoding。有些项目通过 nginx 转发到 Tomcat 的 AJP 端口如果只改了 HTTP Connector参数一样乱。4.2 setenv 脚本里的 JVM 编码参数Windows 下新建bin/setenv.bat内容可以这样set CATALINA_OPTS%CATALINA_OPTS% -Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8Linux/macOS 下新建bin/setenv.shexport CATALINA_OPTS$CATALINA_OPTS -Dfile.encodingUTF-8 -Dsun.jnu.encodingUTF-8file.encoding控制 Java 读取、写出字符流时的默认字符集sun.jnu.encoding对 Java 文件系统操作中的文件名编解码影响较大尤其是在旧 JDK 上。如果你用的 JDK 18file.encoding默认已经是 UTF-8但显式写出来能让生产环境更明确。改完记得重启 Tomcat而且要让catalina.bat或catalina.sh加载这个脚本Tomcat 默认会自动加载setenv只要文件存在。4.3 应用层的字符编码 Filter下面是一个兼容 Tomcat 10 的编码 Filter注意包名是jakarta.servlet。如果你还在用 Tomcat 9把jakarta全部换成javax就行。package com.example.filter; import jakarta.servlet.Filter; import jakarta.servlet.FilterChain; import jakarta.servlet.FilterConfig; import jakarta.servlet.ServletException; import jakarta.servlet.ServletRequest; import jakarta.servlet.ServletResponse; import jakarta.servlet.http.HttpServletRequest; import jakarta.servlet.http.HttpServletResponse; import java.io.IOException; public class EncodingFilter implements Filter { private String encoding UTF-8; Override public void init(FilterConfig filterConfig) { String param filterConfig.getInitParameter(encoding); if (param ! null !param.trim().isEmpty()) { encoding param; } } Override public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException { HttpServletRequest req (HttpServletRequest) request; HttpServletResponse resp (HttpServletResponse) response; req.setCharacterEncoding(encoding); resp.setCharacterEncoding(encoding); resp.setContentType(text/html; charset encoding); chain.doFilter(req, resp); } Override public void destroy() { } }然后在web.xml里注册并把它放在过滤器链最前方filter filter-nameencodingFilter/filter-name filter-classcom.example.filter.EncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mappingSpring Boot 项目可以用配置类替代import org.springframework.context.annotation.Configuration; import org.springframework.http.converter.StringHttpMessageConverter; import org.springframework.http.converter.HttpMessageConverter; import org.springframework.web.servlet.config.annotation.WebMvcConfigurer; import java.nio.charset.StandardCharsets; import java.util.List; Configuration public class WebConfig implements WebMvcConfigurer { Override public void configureMessageConverters(ListHttpMessageConverter? converters) { converters.add(0, new StringHttpMessageConverter(StandardCharsets.UTF_8)); } }这里把StringHttpMessageConverter放到转换器列表第一位是为了保证返回 String 类型时优先使用 UTF-8避免ResponseBody输出中文时被默认编码搞乱。4.4 IDE 和操作系统终端编码修复热搜里和“vscode中文显示乱码”“idea里使用codex乱码”“powershell乱码”相关的词都是这个问题的变体。处理原则只有一个让“编辑器的文件保存编码”“IDE 编译读取编码”“Tomcat 运行时 JVM 编码”“终端显示编码”一致地使用 UTF-8。IDEA打开File - Settings - Editor - File Encodings把 Global Encoding 和 Project Encoding 设为 UTF-8属性文件也选 UTF-8。VSCode打开设置搜索files.encoding设为utf8同时把files.autoGuessEncoding关闭避免按系统猜成 GBK。Windows Terminal / PowerShell执行[Console]::OutputEncoding [System.Text.Encoding]::UTF8。Linux 终端检查locale输出确保LC_CTYPE是UTF-8。用export LANGen_US.UTF-8可临时切换。这里有个老坑有时候 IDE 里看代码中文没问题但编译后的 class 文件里已经乱码了。这是 IDE 读取源码时用了正确编码但编译时又按系统编码读了一遍。所以修改 IDE 文件编码后一定要执行Build - Rebuild Project让 class 重新生成否则 Tomcat 运行起来还是读旧字节。4.5 日志与控制台输出的统一解法Tomcat 启动日志、应用日志、System.out 是三个不同出口但它们最终都落在控制台或日志文件上。日志文件乱码先看 handler 的 encoding控制台乱码先看终端编码。我曾经在 Windows 服务方式启动 Tomcat 时遇到过stdout重定向到文件乱码那个场景需要检查服务运行账户的系统区域设置单纯加 JVM 参数不一定生效。如果实在难调就统一改用日志框架输出比如 Logback让它显式指定 UTF-8 编码appender nameSTDOUT classch.qos.logback.core.ConsoleAppender encoder charsetUTF-8 pattern%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level %logger{36} - %msg%n/pattern /encoder /appender这样能把乱码风险钉死在应用层不再受运维脚本和系统代码页摆布。5. 常见问题速查表与几个记了就不会忘的排查技巧5.1 一张表排查 90% 的 Tomcat 乱码我把这些年遇过的乱码现象、可能原因、处理位置整理成了一张表照着查基本能找到方向。乱码现象可能原因优先检查和处理位置页面动态输出中文变“????”响应头无 charset 或为 ISO-8859-1response.setContentType、Filter、Springproduces静态页面中文乱码文件保存编码不是 UTF-8编辑器文件编码、meta charsetUTF-8控制台 System.out 打印中文乱码JVMfile.encoding与控制台代码页不一致setenv脚本、IDEA/VSCode 终端、chcp 65001GET 参数中文乱码ConnectorURIEncoding配置错误server.xmlHTTP/AJP 连接器POST 表单中文乱码缺少request.setCharacterEncoding编码 Filter、拦截器下载文件名变成%E4%B8%AD%E6%96%87未使用 RFC 5987 格式Content-Disposition: filename*上传中文文件名在服务器乱码容器解码与文件系统编码不一致request 编码、Linux locale、convmvTomcat 启动日志乱码logging.properties里 handler 编码被改ConsoleHandler/FileHandler 编码设为 UTF-8Linux 下解压 WAR 内文件名乱码zip 包内文件名为 GBK 或非 UTF-8unar、unzip -O CP936数据库读出来中文正常接口返回乱数据读写字符集不一致JDBC URLcharacterEncodingUTF-8、表字段字符集PowerShell/cmd 中printf输出中文乱终端输出编码与 JVM 输出编码不一致[Console]::OutputEncoding、chcp 65001周边工具wine、minicom、Keil、WPS乱码工具默认字符集与应用不匹配这些和 Tomcat 同理先确认输入/输出字符集再对症处理5.2 三种乱码特征一眼定位编码方向乱码不是纯随机每种错误解码都有典型特征看几眼就能反推源头“锟斤拷”这是最常见的 UTF-8 解码 GBK 字节流后产生的“胡集团队”。当一串 GBK 字节被按 UTF-8 解析遇到无法解码的字节序列时会生成替换符 UFFFD这个替换符再被用 GBK 编码就会变成“锟斤拷”。看到这三个字几乎可以直接断定源字节是 GBK当前解码环境是 UTF-8。“”单独的黑块问号说明某个字符在目标字符集中压根不存在。比如 Unicode 的汉字写进只能表达 ASCII 的 ISO-8859-1就会变成?这种乱码通常是不可逆的。“浣犲ソ”“寮犱笁”看着像拼音又不全是其实是 UTF-8 中文被按 GBK 或 ISO-8859-1 解码后再组合出来的字形。遇到这种试着用这些字符按 UTF-8 重新编码再按 GBK 解码往往能还原。这些经验不只在 Tomcat 里有价值搜索“wine乱码”“minicom乱码”“keil5打开代码乱码”“wps数学ppt乱码”时底层原理完全一致只要文件里存的是 UTF-8而软件按本地系统编码读取就会在同一个位置显示乱码。修法都是把软件的文件读取编码切到和文件本身一致。5.3 排查乱码最容易被带偏的四个地方第一改了配置没重启。server.xml、setenv.sh都不是热加载的必须完全停止 Tomcat 进程再启动。有时候bin/catalina.bat stop之后 Java 进程还在端口还没释放导致你改完配置重启实际跑的还是旧进程。可以用jps或任务管理器确认。第二IDEA 启动 Tomcat 时不一定读你改的setenv。IDEA 的 Tomcat Server 配置里也有 VM options 一栏。如果你在setenv.bat里配了编码参数但 IDEA 里覆盖了 Tomcat 的启动脚本那setenv可能不生效。我一般会在 IDEA 的 VM options 里也加一行-Dfile.encodingUTF-8。第三Filter 顺序不对。字符编码 Filter 必须放在所有读参数的 Filter 之前。如果权限校验、登录拦截等 Filter 先执行并读取了参数你再设置编码就晚了。所以注册编码 Filter 时filter-mapping要放在最前面。第四浏览器缓存。响应头里Content-Type: text/html;charsetUTF-8已经正确页面还是乱多半是浏览器缓存旧响应。按 CtrlF5 强刷或者开无痕窗口再试。否则你改了半天在旧缓存里看到的还是错误结果。6. 更推荐的长期方案把 UTF-8 当成唯一标准6.1 为什么统一 UTF-8 最省事回到最核心的问题Tomcat 乱码的最终解法不是“某个参数调对了”而是让项目里所有存储、传输、展示环节都统一成一种字符集。UTF-8 是目前互联网生态最通用的选择浏览器、现代 JDK、Linux 和 Windows 的终端都能原生支持。统一之后你不再需要关心“这个文件是 GBK 还是 UTF-8”“这台机器 locale 是什么”排查时只需要检查有没有例外。但统一也不是一蹴而就。老项目里可能混着 GBK 源码、GBK 数据库、甚至手工改过的server.xml。我处理过最复杂的一个老项目前端页面是 UTF-8JSP 文件是 GBK响应头又写了ISO-8859-1三层全不一致页面能正常反而是运气。后来我分三步完成迁移先固定 Tomcat 编码URIEncodingUTF-8、setenv加 JVM 参数、日志 handler 设 UTF-8。再固定应用编码所有.java、.jsp、.html、.xml、.properties保存为 UTF-8重写编码 FilterSpring 接口统一produces或消息转换器。最后处理数据库和周边脚本JDBC URL 加characterEncodingUTF-8Linux 服务器的 locale 设置为 UTF-8脚本文件也按 UTF-8 保存。这三步做完后乱码基本绝迹。即使后续有人新加了外部接口或第三方回调也能很快用第二节的排查思路定位到是哪个环节又出现了非 UTF-8 编码。6.2 给新老项目各留一条应急后路新项目从创建起就统一 UTF-8这是最理想的。但总有老项目一时半会迁不动比如数据库字段里已经存了一堆 GBK 数据或者客户指定必须用 GBK 系统。这种时候不要硬顶可以采取“边界转码”策略在最外层入站和出站时刻做一次性转换内部仍保持统一的字符集。入站时Tomcat 收到的可能是 GBK 字节就在 Filter 里先按 GBK 读到字符串再转成 UTF-8 交给业务层。出站时如果下游协议要求 GBK就在 Response 写出前把 UTF-8 转成 GBK。这种做法可能影响性能但胜在改动小适合兼容过渡。不过要注意这种“边界转码”只能解决编码不一致如果数据本身已经在某次错误解码中被转换过那就需要回到原始字节重新来。这就是为什么我一直强调宁可一开始多花半小时把编码统一也不要让各处都“智能识别”。6.3 最后说句实在话我自己过去踩过几次坑之后现在无论做什么项目落地到 Tomcat 前都会先问三个问题源码文件是不是 UTF-8JVM 启动参数里file.encoding是什么浏览器和终端允许什么编码这三个问题答完乱码基本就没了。你如果在排查过程中看到“锟斤拷”别慌那是字节在告诉你它原来的身份只要你愿意用正确字符集去还原大多数乱码都能在五分钟内定位。真正值得花时间的不是满屏找补丁而是从第一次启动 Tomcat 时就建立一个统一编码的环境让后面的人不再踩进同一个坑。