第一次在Windows服务器上解压Tomcat 9，双击bin目录下的startup.bat，弹出的cmd窗口哗啦啦滚出一堆带方框和问号的字符时，我还以为下载到了损坏的压缩包。后来换了好几个版本，重新配了JDK，“锟斤拷”依旧准时出现，才意识到这根本不是安装包的问题，而是字符编码在Windows控制台这条链路里“对不上暗号”。
Tomcat启动过程中的cmd窗口中文乱码，是Windows环境下最常见的“入门劝退题”。它不姓“Tomcat”，而姓“编码”：Java进程输出日志时用什么编码，Windows的cmd窗口又按什么代码页去解码，两者只要不一致，任何中文都会变成无法阅读的乱码。这篇文章我会从乱码类型、根因到修复方案和排查实录，完整梳理一遍，不需要你具备太深的基础，但读完你能自己动手解决，顺便搞懂为什么。
1. 先诊断：你看到的“乱码”到底属于哪一种？
遇到乱码不要直接开改，第一步是判断乱码的类型和出现范围。很多人只看到“中文乱码”四个字，就到处找教程，结果方案试遍了也没用，问题大概率就出在没分场景。
1.1 三类常见现象的快速区分
我把实际遇到的乱码归纳成三种情况，你先对比一下：
| 现象 | 典型形态 | 出现位置 | 大概率根因 |
|---|---|---|---|
| 启动日志整段乱码 | 锟斤拷、��� | cmd窗口全部日志 | JVM/ConsoleHandler编码与控制台代码页不一致 |
| 中文变成问号 | 显示成?或??? | 只有中文部分 | 控制台字体或代码页无法映射对应字符 |
| 日志文件乱码，cmd正常 | 用编辑器打开log文件乱码 | catalina.yyyy-MM-dd.log | 文件编码与编辑器默认编码不一致 |
第一行的“锟斤拷”是典型的GBK和UTF-8互相转错产生的字符，其实是有规律的替换。第二行常见于字体不支持某个字形，或代码页里根本没有对应字符。第三行要特别注意：cmd里正常，不代表日志文件一定正常，很多人在控制台乱码修好后，用Notepad打开catalina.log看到还是乱，以为又复发，其实是编辑器按UTF-8打开了一个GBK文件，或者反过来。这三类问题的处理方式完全不同，先定位再动手。
1.2 先跑两条命令确认当前环境
打开cmd，先执行：
chcp如果输出是936，说明当前控制台代码页是GBK（简体中文Windows的默认值）；如果输出是65001，说明当前是UTF-8。记住这个结果，后面所有判断都围绕它展开。
再检查一下cmd窗口的字体：在标题栏右键 -> 属性 -> 字体，看有没有“新宋体”“点阵字体”“Consolas”。老式点阵字体对UTF-8环境下的中文兼容比较差，容易把中文显示成一片空白或方框。Windows Terminal或较新的控制台程序一般用Cascadia Mono，兼容性会好很多。
这两条信息加在一起，能帮你筛掉一半问题。
2. 编码链拆解：为什么Tomcat在cmd里“天生”容易乱码？
要彻底解决乱码，不能只背命令，得理解这条编码链。这个概念搞清楚了，Windows下几乎所有控制台中文乱码你都能举一反三。
2.1 一次字符输出要经过三次“转运”
Tomcat在JVM内部跑的时候，所有字符串在内存里都是Unicode。从字符串变成你在cmd里看到的汉字，中间至少经过三次转运：
- 字符串被Java进程按某种字符集编码成字节，写进标准输出或日志输出流；
- 字节到达Windows控制台，控制台按当前代码页把它们解码成字符；
- 控制台再按当前字体把字符渲染到屏幕上。
每一步都默认“对方会按我的方式处理”，但只要中间某一次选择不一致，接收方拿到的就是错乱的字节。举一个生活例子：你在A城写了一张卡片，交给快递时用中文写了收件人，结果中转站看不懂，把它重新贴成了匈牙利文标签，最后送到B城，收件人看着满纸匈牙利文，当然觉得“这包裹坏了”。乱码也是同样的道理，字节本身没坏，是“标签贴错”了。
2.2 JVM侧默认编码与JDK版本的“历史包袱”
Java在Windows中文版下的默认编码一直是历史包袱。JDK 8、JDK 11、JDK 17在不显式指定参数时，file.encoding通常会跟随系统区域设置，简体中文Windows上就是GBK。JDK 18开始有了JEP 400，把默认字符集改成了UTF-8，Windows下的乱码情况大幅改善，但生产环境大量还是JDK 8或11，所以这个问题远未消失。
这里有个很容易被忽略的细节：System.out往控制台输出时，实际使用的并不是file.encoding，而是sun.stdout.encoding（以及错误输出对应的sun.stderr.encoding）。JDK 18之前，只设置-Dfile.encoding=UTF-8，不一定能让System.out按UTF-8输出，必须把sun.stdout.encoding和sun.stderr.encoding也一起指定。JDK 18之后这两个参数被移除了，默认就是UTF-8。很多“我明明设了file.encoding怎么还乱”的人，其实是卡在这个细节上。
可以通过下面这条命令快速查看当前JVM的编码相关属性：
java -XshowSettings:properties -version 2>&1 | findstr encoding观察输出里的file.encoding、sun.stdout.encoding、sun.stderr.encoding。如果sun.stdout.encoding显示为GBK，而cmd代码页是65001，那么System.out打印的中文必乱无疑。
2.3 Tomcat日志框架的编码出口
Tomcat默认日志框架不是Log4j，而是基于java.util.logging扩展出的JULI。核心配置文件是conf/logging.properties，里面控制台Handler的配置一般长这样：
java.util.logging.ConsoleHandler.level = FINE java.util.logging.ConsoleHandler.formatter = org.apache.juli.OneLineFormatter注意，这里没有显式指定encoding。java.util.logging.ConsoleHandler不指定编码时，会用系统默认字符集编码输出，在简体中文Windows上就是GBK。理论上GBK输出配936代码页是能正常显示的，很多老机器碰巧不开乱码。但一旦你的JVM启动参数、环境变量或IDE强制了UTF-8，控制台还在按936解码，立刻就是一片“锟斤拷”。
所以，Tomcat控制台乱码的根源说白了是一句话：Java进程输出日志时用的字符集，和cmd当前代码页解码时用的字符集，没有配对。你能做的所有修复，都是把这两个值重新对齐。
3. 四种修复方案，从“一条命令”到“一劳永逸”
下面按改动量从小到大给出四种方案，你可以先试第一种验证判断，再按需组合后面的方案。
3.1 方案一：临时切换cmd代码页，立刻验证
最轻量的“验证型”修法，直接在当前cmd窗口里执行：
chcp 65001 catalina.bat run如果Tomcat输出的是UTF-8字节，代码页切成65001后中文马上正常。但这招有个前提：Tomcat/Java进程的日志输出本身得是UTF-8。如果Tomcat还是按系统默认GBK输出，你强行切到65001，本来正常的GBK字节会被当作UTF-8解码，反而乱得更厉害。
所以在改之前先做一个简单的底噪测试。在cmd里输入：
echo 中文测试正常显示，说明当前代码页和你键盘输入的中文是匹配的，不代表Tomcat输出也匹配。再写一个最小Java测试会更准：
public class EncodingCheck { public static void main(String[] args) { System.out.println("中文编码测试"); } }分别在chcp 936和chcp 65001下编译运行，看看中文在哪边正常。这个测试能把“Windows控制台和JVM输出编码”的组合问题单独测出来，不掺入Tomcat日志框架的干扰，非常值得花两分钟跑一下。
3.2 方案二：让JVM统一输出UTF-8
如果你的Tomcat启动日志确实是UTF-8方向，那就配置JVM启动参数。这里推荐使用官方预留的setenv.bat，而不是直接去改catalina.bat。在Tomcat的bin目录下新建setenv.bat（没有就新建），写入：
@echo off set "CATALINA_OPTS=%CATALINA_OPTS% -Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8"保存后重启Tomcat。注意，CATALINA_OPTS只影响Tomcat进程本身的启动，不会影响你之后部署的Web应用里通过System.out打印的内容（应用打印要不要管，见第4节）。JAVA_OPTS会影响所有通过脚本启动的Java进程，如果不想让重启脚本或别的工具跟着变，优先用CATALINA_OPTS。
为什么推荐setenv.bat？因为catalina.bat在Tomcat每次启动时都会先检查bin下有没有setenv.bat或setenv.sh，有就自动加载。你升级Tomcat版本时只需要保留或备份这个文件，不用每次去追着源码里的启动脚本改，也不会因为升级覆盖而丢失配置。
3.3 方案三：修改Tomcat日志控制台的输出编码
光有JVM参数还不够，因为Tomcat的日志框架也可能按自己的配置去写输出流。我习惯把conf/logging.properties里的控制台Handler编码也显式指定成UTF-8：
java.util.logging.ConsoleHandler.encoding = UTF-8加完后，Tomcat发给控制台的日志字节就明确是UTF-8，不再跟随系统默认。
这里必须提醒：如果只改这一行，而不做第3.1节的代码页切换，cmd窗口会从“原本的乱码”变成“另一种乱码”，因为控制台按936去解码UTF-8字节，结果就是经典的“锟斤拷”。所以方案三和方案一通常要配套使用。反过来，如果你希望在中文Windows下不切65001，也可以把这里显式设成GBK，同时JVM参数也设成GBK，控制台保持936，一样能显示中文。但这样做跨平台一致性很差，到了Linux服务器又得改回去，我一般不推荐，除非是“机器权限受限不能切代码页”的特殊环境。
3.4 方案四：用文件日志代替直盯控制台
如果只是想看日志，并不需要长时间盯着启动窗口，最简单的是绕开cmd的代码页问题，把输出重定向到文件：
catalina.bat run > ..\logs\console.log 2>&1然后用VS Code、Notepad++或IDE打开console.log，按实际编码（UTF-8或GBK，可以用编码切换功能试）查看。这样Tomcat本身的编码设置可以保持不动，也不影响控制台。需要说明的是，这样重定向得到的内容只是“标准输出”和“标准错误”，Tomcat的JULI文件日志（logs目录下那些catalina.*.log）本来就是独立写入的，两者互不干扰。
四种方案的定位我用一张表总结：
| 方案 | 适用场景 | 改动量 | 持久性 |
|---|---|---|---|
chcp 65001 | 快速验证、临时查看 | 最小 | 当前窗口有效 |
配置setenv.bat | JVM编码不对齐 | 中 | 持久 |
配置logging.properties | Tomcat日志出口编码不明确 | 中 | 持久 |
| 输出重定向到文件 | 不依赖cmd、只想看日志 | 小 | 按需执行 |
4. 修复路上的隐形坑：setenv.bat、IDEA控制台与Windows Terminal
很多人在网上搜到方案，照着改完发现还是乱，往往不是方案不对，而是掉进了几个“隐形坑”。
4.1 setenv.bat的位置和“看不见的后缀”
setenv.bat一定要放在Tomcat的bin目录下，放错位置不会被加载。另外Windows默认会隐藏已知文件类型的扩展名，你新建一个“文本文档”再改名为setenv.bat，很可能实际文件名是setenv.bat.txt，看起来名字一样，Tomcat却根本不会认。排查时可以把资源管理器的“查看 -> 文件扩展名”打开，确认文件是setenv.bat而不是setenv.bat.txt。这个低级错误我见过太多次，值得列为第一排查项。
4.2 IDEA控制台与系统cmd是两个世界
很多人的开发流程是：IDEA里配置Tomcat，点运行，然后看IDEA的Run窗口，乱码了。注意，IDEA内置控制台不是Windows cmd，它有自己独立的字符集设置。IDE控制台默认按UTF-8显示，而Tomcat进程如果还在按系统GBK输出，两边就对不上。
这种场景下，先去Run/Debug Configurations找到你的Tomcat配置，在VM options里加：
-Dfile.encoding=UTF-8 -Dsun.stdout.encoding=UTF-8 -Dsun.stderr.encoding=UTF-8同时把Settings -> Editor -> File Encodings里的Global Encoding、Project Encoding、Properties Files编码都统一成UTF-8。两边都改了，IDEA控制台中文才能正常。Eclipse也类似，在Run Configurations -> Arguments -> VM arguments里填同样参数。
这里要记住一个核心原则：让Tomcat进程输出的编码，和查看日志用的控制台/编辑器解码编码保持一致。谁输出谁定编码，谁显示谁定解码，两个角色都要对齐，不是只改一边就万事大吉。
4.3 Windows Terminal与老控制台的显示差异
如果你用的是Windows Terminal，它对UTF-8的兼容性比老版conhost好不少，但还是会受字体影响。推荐把配置文件里的字体设置成“Cascadia Mono”或“新宋体”，遇到中文字形显示成方框的概率会低很多。
如果是Windows Server 2016或更老的机器，cmd对65001代码页的支持并不完善，切换后可能出现光标错位、历史命令乱码等其他症状。老服务器上我一般不建议强切65001，更推荐用文件重定向方案，稳定省心。
4.4 全局UTF-8开关：不要为一个小问题开大手术
系统设置里有个“Beta版：使用Unicode UTF-8提供全球语言支持”选项，位于控制面板->更改系统区域设置。勾选后系统层面的代码页默认会变成UTF-8，很多控制台乱码确实能“无痛”消失。但这是全局改动，影响系统中所有程序的编码行为，可能让某些老软件、旧字体、特殊路径全部出现新的乱码。为了一个Tomcat启动窗口去改变整个系统的区域行为，性价比很低，强烈不建议在生产环境或常用办公机上开这个开关。
5. 一次完整排查实录：改完还是乱码该怎么办？
最后分享一个我帮朋友排查的真实案例，它的价值在于：配置看上去全对了，乱码依旧存在，最后的问题出在一个非常隐蔽的环境变量上。
5.1 现象：改了三处配置，中文反而变成问号
那台电脑是Windows 11中文版、JDK 17、Tomcat 10。最初启动Tomcat，cmd窗口里中文全部是“锟斤拷”。朋友按照网上的教程做了三件事：在setenv.bat里设置了file.encoding=UTF-8，在logging.properties里设置了ConsoleHandler编码UTF-8，启动前执行了chcp 65001。结果乱码变成了一大片???，看起来更诡异。
5.2 按编码链逐级排查的完整链路
我让他按下面这个顺序逐项排查，每一条都有对应命令：
第一步，确认当前控制台代码页：
chcp屏幕上显示65001，说明控制台侧已经是UTF-8。
第二步，确认JVM真正生效的编码参数：
java -XshowSettings:properties -version 2>&1 | findstr encoding这里发现了问题线索：file.encoding显示GBK，sun.stdout.encoding也显示GBK。也就是说，尽管setenv.bat写了-Dfile.encoding=UTF-8，JVM启动时实际生效的却还是GBK。
第三步，排查“隐形覆盖者”。Windows下有两个环境变量优先级很高：JAVA_TOOL_OPTIONS和_JAVA_OPTIONS。只要它们存在，JVM启动时就会强制注入对应参数，把脚本里传进来的参数覆盖掉，并且_JAVA_OPTIONS还会在启动日志最上方打印一行Picked up _JAVA_OPTIONS的提示。执行：
echo %JAVA_TOOL_OPTIONS% echo %_JAVA_OPTIONS% echo %CATALINA_OPTS%果然，JAVA_TOOL_OPTIONS里残留着一行-Dfile.encoding=GBK，是朋友之前试用某个Eclipse插件时配置的。它优先于Tomcat启动脚本里的所有参数，等于把三个修复方案里的“JVM侧”偷偷又改回了GBK。
5.3 最终修复与结果验证
处理办法很简单：删除或修正这个环境变量，再重启Tomcat。我把JAVA_TOOL_OPTIONS里的-Dfile.encoding=GBK删掉，保留空的变量（或直接删除变量），再配合已设置好的setenv.bat和logging.properties，用chcp 65001启动catalina.bat run，这次中文日志完整正常显示。
同时我还验证了文件日志：用VS Code打开logs/catalina.2025-xx-xx.log，右下角编码切换成UTF-8后无乱码。这说明文件日志和控制台都统一到了UTF-8，问题才算彻底结束。
这个案例想说明一点：当你已经按教程改了启动脚本和日志配置，乱码仍然存在时，不要再继续堆配置，停下来查一下JVM启动时的“既成事实”。最高效的办法就是在启动Tomcat时，看控制台最前面的几行输出里有没有Picked up JAVA_TOOL_OPTIONS或Picked up _JAVA_OPTIONS，有就说明环境变量在截胡。把这条加进你的排查习惯里，能省下大量无意义的试错。
5.4 我现在形成的最小复现检查习惯
分享一个我自己现在一直沿用的习惯。遇到任何Tomcat控制台中文乱码，我先不急着改文件，而是花三分钟做三件事：看一眼chcp的结果，写一个EncodingCheck.java分别在不同代码页下跑一次，再检查一遍三个环境变量是不是有残留。这三步做完，80%的乱码原因就已经浮出水面。剩下20%，再转向logging.properties和IDE控制台设置去逐个确认。
另外一个小技巧：不要把chcp 65001写进全局的catalina.bat。因为有人会用startup.bat，有人会用catalina.bat run，还有人在IDEA或服务方式下启动，全局改启动脚本只对命令行方式有效，还会影响其他渠道的启动行为。把它放在你自己的启动快捷方式或wrapper脚本里，控制面更干净。我现在本地开发用的就是一个简单的dev-tomcat.bat，内容大致是：
@echo off chcp 65001 >nul cd /d D:\apache-tomcat-10 call bin\catalina.bat run这样既不会污染Tomcat原始脚本，也方便在团队里分发，谁拿到都能直接复现出正常编码环境。
