1. 先别慌Tomcat控制台乱码到底是怎么一回事很多刚接触Java Web开发的朋友第一次启动Tomcat的时候估计都被cmd窗口里那一大片“锟斤拷”、“浣犲ソ”之类的乱码吓了一跳。我第一次遇到这个问题的时候还以为是下载的Tomcat安装包损坏了甚至重装了好几次后来才发现根本不是那么回事。这个问题的出现范围非常广不管是Windows 10还是Windows 11不管是Tomcat 8、Tomcat 9还是Tomcat 10只要你用的是Windows系统在cmd窗口控制台里启动Tomcat几乎都有概率碰到中文乱码。乱码的内容主要集中在启动日志、初始化信息、部署报错信息这几块英文日志显示完全正常偏偏就是中文部分变成了“天书”。这个问题的本质用一句话说就是Tomcat的日志输出使用的编码格式和Windows控制台默认使用的编码格式对不上。说得再直白一点就是Tomcat在“说话”的时候用了一种语言而cmd窗口在“听”的时候用了另一种语言去解读两边没对齐听到的自然就是乱码了。这篇内容适合谁看我觉得只要满足下面任一条件你都值得花十分钟把它读完刚下载好Tomcat启动后发现控制台乱码不知道怎么处理用IntelliJ IDEA、Eclipse等IDE集成了Tomcat运行项目时控制台同样乱码已经尝试过一些网上的办法但要么操作不完整要么改完之后出现了新的问题想彻底搞清楚乱码的底层逻辑下次遇到类似问题可以直接举一反三。这篇文章我会从乱码的产生原理讲起再给出三级递进的解决方案最后附上常见的排查方法。保证你看完不仅能解决当前问题还能明白为什么这么改就能好以后给别人解释的时候也底气十足。2. 为什么Tomcat在cmd窗口里会变成乱码2.1 编码不一致才是罪魁祸首乱码这件事追根溯源永远只有一个原因编码和解码的方式不一致。我给你打个比方。假设有个人用汉语拼音写了一封信信上写的是“ni hao”结果收信的人不懂拼音非要拿英语的读音规则去读读出来的就成了“你嚎”意思全变了。Tomcat和cmd窗口之间就是这种关系。Tomcat的日志输出默认使用的是UTF-8编码这是Tomcat 8.5版本之后的一个默认调整。而在中文版的Windows操作系统上cmd窗口和控制台默认使用的却是GBK编码也叫做CP936是简体中文字符集的标准编码。UTF-8的“锟斤拷”和GBK的“浣犲ソ”互不认账于是你看到的就是一堆莫名其妙的字符。在Windows的cmd窗口里你可以输入下面这个命令来查看当前窗口使用的编码chcp如果输出结果是936那就代表当前活动代码页是936也就是GBK编码。如果你在cmd里看到的是65001则是UTF-8编码。绝大多数情况下中文Windows系统的cmd都默认是936。2.2 编码转换的具体流程Tomcat的日志体系是基于Java的java.util.logging组件实现的它的配置文件是conf/logging.properties。Tomcat在启动的时候会按照这个配置文件中的设置把日志内容以指定的字符编码写入到控制台输出流中。关键配置项是下面这行java.util.logging.ConsoleHandler.encoding UTF-8这行配置的作用是告诉Tomcat的ConsoleHandler控制台处理器往控制台写日志的时候用UTF-8编码。问题就出在这里Tomcat用UTF-8往cmd窗口里扔字符而cmd窗口却固执地用GBK去理解和渲染于是UTF-8编码的中文字符每个汉字3个字节被GBK按两个字节一组去解析结果自然就全乱了。还有一个跟编码相关的经典梗“锟斤拷”。这三个字实际上是UTF-8字节序列被错误地用GBK解码后产出的典型乱码字符很多老程序员一看到这三个字就能立刻判断出“哦这是UTF-8被GBK解码了”。你这次看到的乱码大概率就是这个“锟斤拷”家族的一员。2.3 为什么英文不乱码偏偏中文乱码这个问题的答案其实很朴素因为ASCII编码、UTF-8编码和GBK编码对英文字母和数字的表示方式是完全一致的。英文字母和数字在所有这些编码里都是单字节存储并且值完全一样所以不管用哪种规则去解读结果都是正确的。而中文字符在UTF-8里占3个字节在GBK里占2个字节底层存储的字节序列完全不同。甲用UTF-8写出来的字节流乙用GBK去读读出来的字符数量不对、内容也不对自然就乱套了。明白了这个原理你其实就知道解决方案的大方向了要么让Tomcat输出GBK编码要么让cmd窗口用UTF-8编码来接收。接下来我给的几个方案本质上都是围绕这两条路展开的。3. 最快最省事的解法修改Tomcat的logging.properties3.1 操作步骤这个方法可以说是全网公认的入门级解法也是我每一次帮别人处理Tomcat乱码问题时最先推荐的方法。它不需要修改系统的任何设置只动Tomcat自己的配置文件风险最小。找到Tomcat安装目录下的conf文件夹里面有一个名为logging.properties的文件。用记事本、Notepad或者VS Code打开它定位到下面这一行java.util.logging.ConsoleHandler.encoding UTF-8把它改成java.util.logging.ConsoleHandler.encoding GBK保存文件然后重新启动Tomcat。到这一步绝大多数情况下的乱码问题就已经解决了。这里我要啰嗦一句修改配置文件前建议先备份一下原文件。你别小看这个习惯我在实际工作中见过太多次改完配置出了问题想回退、结果原文件内容已经被改得面目全非的局面。3.2 为什么改编码就行把这个值从UTF-8改成GBK本质上是让Tomcat“说”cmd窗口能听懂的语言。前面说了中文Windows的cmd窗口默认按GBK解码Tomcat也改用GBK输出两边就对齐了中文自然就恢复正常了。这个方案不仅适用于Tomcat 9Tomcat 8.5和Tomcat 10同样适用。因为这三个大版本的日志配置文件结构基本一致ConsoleHandler.encoding这个配置项都还存在。3.3 修改后依然乱码怎么办如果你改完GBK之后重启Tomcat发现乱码反而变得更离谱了比如出现了“锟斤拷”的变体或者原本还能看懂一部分的英文提示也出了问题那说明你的情况可能不在这个方案覆盖范围内。有两种可能第一种你的Windows系统或者cmd窗口已经被手动改成了UTF-8代码页也就是chcp显示的是65001这时候你应该把logging.properties改成UTF-8或者干脆把cmd窗口的编码改回GBK第二种你使用的Tomcat发行版在启动脚本catalina.bat里额外指定了JAVA_OPTS强制覆盖了日志编码设置。这种情况比较少见但我也确实碰到过后面第4节会详细讲。所以在动手之前我建议你先花10秒钟执行一下chcp命令确认当前cmd窗口的代码页再决定把配置文件改成GBK还是保持UTF-8。这一步看似多余实际上能帮你少绕很多弯路。4. 备选方案从cmd窗口侧下手改用UTF-8编码4.1 临时修改cmd窗口的代码页如果你不想动Tomcat的任何配置文件或者因为某些原因不能修改生产环境的Tomcat配置那么从cmd窗口这一侧解决就是更好的选择。在启动Tomcat之前先在cmd窗口里执行下面的命令chcp 65001这条命令的作用是把当前cmd窗口的活动代码页临时切换成UTF-8。切换之后你再执行startup.bat启动Tomcat原本乱码的中文日志就会恢复正常显示。不过要提醒一句这种修改是临时的只对当前这个cmd窗口有效。窗口一关下次重新打开一个新的cmd窗口代码页又会还原成默认的936。所以如果你每次启动Tomcat都想要正常显示就需要每次先执行一次chcp 65001比较繁琐。4.2 永久修改cmd窗口的默认代码页如果你觉得每次手动输入命令太麻烦也可以通过修改注册表的方式让cmd窗口永久默认使用UTF-8代码页。按下Win R组合键输入regedit并回车打开注册表编辑器。定位到下面这个路径HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Command Processor在右侧窗口中找到或新建一个名为Autorun的字符串值双击它把数值数据设置为chcp 65001 nul点击确定关闭注册表编辑器。此后每当你打开一个新的cmd窗口系统都会自动执行chcp 65001把代码页切换成UTF-8。但我要特别提醒一下修改注册表的方式我其实不太推荐给新手用户也不推荐在重要的开发机上随便改。原因有两点第一Autorun这个配置项对所有cmd窗口都会生效如果你的其他脚本、批处理文件对GBK有依赖改了之后可能引发连带问题第二有些第三方软件在调用cmd执行命令时并不会读取这个注册表的Autorun所以这个方案的实际生效范围是有限的并不像网上某些教程说的那么“万能”。4.3 两个方案之间的本质区别简单总结一下改logging.properties的方案是“Tomcat迁就cmd窗口”改cmd代码页的方案是“cmd窗口迁就Tomcat”。两条路都能抵达终点但适用场景不同。如果你只在本机开发Tomcat是你自己启动的我建议优先采用改logging.properties的方案一劳永逸如果你在管理服务器或者Tomcat是作为Windows服务安装的不方便频繁改配置那么用chcp 65001临时切换的方式往往更合适。在下面的表格里我把两个方案的关键差异整理了出来方便你做选择方案修改对象是否需重启影响范围推荐指数修改logging.propertiesTomcat配置是仅Tomcat自身五星chcp 65001临时切换cmd窗口仅当前窗口本窗口三星注册表Autorun系统级新窗口生效全部cmd窗口两星表格里的推荐指数是我个人的看法不代表绝对标准。但如果你问我我会坚定地站在“修改Tomcat配置文件”这一边。5. 深入源码与实践从启动脚本层面根治乱码5.1 catalina.bat里藏着的猫腻讲完最基础的两种解法我们再深入一层看看Tomcat的启动脚本里还有没有影响编码的“隐藏开关”。Tomcat的启动脚本bin/catalina.bat是整个Tomcat生命周期里最重要的一段批处理脚本。它负责设置环境变量、拼装JAVA_OPTS、调用org.apache.catalina.startup.Bootstrap类来真正拉起Tomcat进程。在这个脚本里有一项配置值得你特别注意set JAVA_OPTS%JAVA_OPTS% -Dfile.encodingUTF-8如果你在catalina.bat里看到类似这样的一行说明启动脚本在JVM层面强行指定了file.encoding为UTF-8。这个参数会作用于JVM进程中所有涉及文件读写和流输出的编码行为包括System.out的输出、日志文件的写入等。问题来了如果file.encodingUTF-8被写死在了启动脚本里那么即使你把logging.properties里的ConsoleHandler.encoding改成了GBK也有可能因为JVM级别的编码设置与ConsoleHandler的配置产生冲突最终输出还是一团乱麻。5.2 如何在catalina.bat层面做调整我给你的建议是打开bin/catalina.bat用文本编辑器的搜索功能查找file.encoding相关的字符串。如果真的找到了你可以尝试把UTF-8改成GBK然后重启Tomcat看效果。如果你在脚本里没有找到任何file.encoding相关的配置那就说明这个“隐藏开关”并不存在你不需要额外添加。很多网上教程会让用户手动往catalina.bat里添加-Dfile.encodingUTF-8这其实是一个典型的“画蛇添足”行为。原因很简单Tomcat在启动时JVM会默认读取操作系统的字符集设置来确定file.encoding。在中文Windows上这个默认值通常就是GBK。如果你手动再强制指定为UTF-8反而人为制造了编码冲突。这不是在解决问题而是在制造问题。5.3 代码层面的System.out.println乱码问题还有一种情况需要单独拎出来讲有时候Tomcat本身的启动日志已经完全正常了但你自己写的Web应用在控制台输出的System.out.println语句依然显示乱码。这是因为Java应用默认的file.encoding编码可能是平台的默认编码也可能被容器环境覆盖了。如果你的Web应用是在IDEA里通过Tomcat启动的那么你还需要去检查IDEA的编码设置。在IntelliJ IDEA里打开Settings - Editor - File Encodings你可以看到三个下拉框Global Encoding、Project Encoding和Properties Files。建议都统一设置成UTF-8。同时在Help - Edit Custom VM Options里可以打开IDEA自己的配置文件加上一行-Dfile.encodingUTF-8然后重启IDEA让这个配置生效。这一步做完IDEA传递给Tomcat的JVM参数里就会包含UTF-8编码设置System.out.println的中文输出基本上就能恢复正常了。我在实际项目里遇到过一种很典型的情况Tomcat的启动日志已经正常了但项目里一个System.out.println(登录成功)的语句在IDEA的控制台里就是显示乱码。我检查了上面说的所有配置最后发现问题出在IDEA的Run/Debug Configurations里Tomcat Server的VM options一栏被手动填了一个-Dfile.encodingGBK。删掉之后一切都正常了。所以我要在这里给你一个非常实用的经验排查乱码问题时不要只看Tomcat自身还要检查你的开发工具和运行环境给JVM塞了什么额外的参数。# 在cmd里启动Tomcat前先查看当前JVM默认编码适用于已经配置好JAVA_HOME的环境 java -XshowSettings:properties -version 21 | findstr file.encoding这条命令输出的结果会明确告诉你当前JVM默认的file.encoding是什么。如果你发现这里显示GBK而Tomcat日志输出UTF-8冲突的根源就找到了。6. 高频问题排查手册五分钟定位乱码根源6.1 常见问题与解决对照表我把这些年遇到的Tomcat控制台乱码问题按表现特征归了一下类整理成下面这张速查表。你对号入座找到自己属于哪一类然后照着对应的方法处理即可。故障现象可能原因解决动作启动日志全是“锟斤拷”Tomcat输出UTF-8cmd按GBK解码改logging.properties为GBK修改GBK后乱码更严重cmd代码页本身就是65001先确认chcp结果再调整日志中英文正常只有中文乱编码冲突只波及多字节字符统一ConsoleHandler编码即可中文前半段正常后半段乱启动脚本或IDE覆盖了file.encoding检查catalina.bat和IDEA VM options在cmd里正常在IDE里乱IDEA自带控制台编码设置不一致检查IDEA的File Encodings设置修改配置后重启又还原Tomcat被安装为Windows服务走了服务配置检查服务安装时的JVM参数这张表覆盖了我能想到的绝大多数场景。如果你遇到的问题正好被列在表里那就照着对应的方法去改如果不在表里别急下一节我再讲一个更系统的排查思路。6.2 事无巨细的排查四步法我平时在帮别人排查乱码问题时不是东试一个方法西试一个方法而是按照固定的顺序一层层往深处挖。这套方法我称之为“排查四步法”分享给你。第一步确认当前cmd窗口的代码页。打开一个新的cmd窗口输入chcp回车看输出是936还是65001还是其他数值。这个结果直接决定你改Tomcat配置时该用GBK还是UTF-8。这一步是整个排查过程的地基地基不稳后面全白搭。第二步确认Tomcat的ConsoleHandler编码。打开conf/logging.properties找到java.util.logging.ConsoleHandler.encoding这一行看它的值是多少。如果这一步的编码和第一步的代码页对不上那这就是乱码的直接原因改对齐即可。第三步确认JVM级file.encoding是否被覆盖。在启动Tomcat的同一环境下执行java -XshowSettings:properties -version 21 | findstr file.encoding看输出的值。如果这里显示的编码与前面两步的值都不一致就说明有第三方配置强插了一脚你需要检查catalina.bat和IDE的VM options。第四步排除应用自身的输出乱码。如果以上三步全部检查完毕Tomcat启动日志完全正常但只有某个特定Web应用的信息输出乱码那问题就出在应用层面。你需要检查项目的编码设置、web.xml里字符编码过滤器的配置以及数据库连接URL是否指定了正确的编码。这个流程走下来90%以上的乱码问题都能找到根源并解决。剩下的10%则可能是极端情况比如操作系统区域语言设置被改成了非中文但代码页没正确更新或者杀毒软件拦截了配置文件写入导致修改未生效。遇到这类特殊环境就需要具体问题具体分析了。6.3 一个容易被忽视的细节Windows服务模式启动最后再讲一个特别容易踩坑的细节。如果你是通过如下命令把Tomcat注册成Windows服务的service install Tomcat9那么Tomcat就会以Windows服务的形式在后台运行它的标准输出会重定向到系统日志而不是显示在cmd窗口里。有些人在排查乱码时对着logging.properties改了半天结果打开服务管理器一看发现Tomcat压根不是从cmd启动的日志输出走的完全是另一条通道。这种情况下你需要在“服务管理器”里找到Tomcat服务右键选择“属性”查看“登录”选项卡下的设置。如果服务的登录身份是Local System Account那么它执行时使用的代码页会和当前登录用户的默认设置不同UTF-8与GBK的冲突也可能因此被放大。解决办法是在catalina.bat里通过JAVA_OPTS显式指定编码或者直接把服务删除回到用startup.bat启动的方式。如果你对Windows服务没刚需我更建议直接用startup.bat开发调试操作简单、日志直观排查问题也方便。7. 一些个人经验与彩蛋技巧写到这里关于乱码的原理、解法、排查方法都已经讲得比较完整了。最后再分享几点我自己在实际操作中的心得这些经验不是从文档里抄来的都是踩坑踩出来的。第一个心得是遇到乱码别忙着搜“最有效的解决办法”先花一分钟搞明白你的环境到底是什么情况。“锟斤拷”和“浣犲ソ”虽然都是乱码但它们的产生机制不同盲目套用网上教程反而可能把问题搞得更复杂。先执行chcp再打开logging.properties看一眼两分钟就能定位到问题。第二个心得是改配置文件一定要养成备份的习惯。不只是Tomcat任何项目的配置文件都一样。我见过太多人改完配置发现问题想回退结果发现原文件早被覆盖了只能重新安装。备份一个文件用不了一秒钟却能省下几个小时的重装时间。第三个心得是尽量保持编码体系的统一。如果你的整个开发链路——从代码文件、到IDE、到Tomcat、到数据库——全部统一使用UTF-8那么理论上你根本不会遇到编码问题。乱码的根源永远是“不一致”从这个角度看最根本的解法不是某个配置项的调整而是建立一套统一的编码规范。当然Windows的cmd默认GBK是系统级行为你改变不了它那就学会让Tomcat去适配它。最后再送大家一个小技巧。修改完logging.properties之后不用每次重启电脑才能生效——只需要关掉当前cmd窗口重新打开一个新的窗口再启动Tomcat就可以了。这个操作虽然简单但真的有人不知道以为改了配置就得重启系统白白浪费时间。好了关于Tomcat启动时cmd窗口中文乱码的问题核心的内容就到这里。希望这篇文章能帮你一次性解决问题而不是像当年的我一样被这个看似小的问题折腾了一整天才弄清楚。如果你按照上面的方案操作后问题依然存在欢迎把具体的乱码截图和Tomcat版本信息发出来一起讨论。技术问题不怕复杂怕的是没有清晰的排查思路。
