先说个真实感受IDEA控制台中文乱码十有八九不是代码写错了而是IDEA、Windows和JDK这三方对“字符编码”的理解压根儿没对齐。前前后后帮同事调过不下二十次这个问题有的改两个设置就好有的改完启动参数依旧满屏“锟斤拷”最后发现是logback配置文件里的编码没跟上。这篇就把我自己常用的排查路径和最终可落地的方案完整写出来尽量让不同基础的人都能直接对着操作。这个问题的本质是数据在“写入—传递—显示”三个环节里用了两套不同的字符集规则。只要把规则统一到UTF-8上99%的乱码都能消掉剩下1%跟Windows命令行窗口的历史包袱有关得单独处理。1. 乱码是怎么来的三个环节为什么必须统一先理清乱码产生的过程。Java程序里System.out.println(中文)这句代码干了两件事第一把中文字符串按JVM默认字符集转成字节第二把字节流送到控制台。IDEA控制台接住字节流之后又要按自己认为的字符集去解码最后把解码结果画在屏幕上。问题就出在“转成字节”和“解码字节”这两步用的字符集不一致。比如代码是新建项目时IDEA默认用的UTF-8那么字符串转出来的字节是UTF-8编码。可Windows中文版的控制台通常默认用GBK去解码UTF-8的字节流原本该是“中文”三个字被GBK硬生生拆成了几个字符显示出来就成了乱码。这个过程用生活里的事打个比方你把一句话用拼音写下来交给别人结果对方手里的是拼音转汉字表却拿着它去查英文字典最后得到的当然不是原来的句子。常见的乱码套路有两种?????字符集里根本没有对应的字形解码失败拿“?”占位。锟斤拷UTF-8字节流被GBK解码后又经过了一次转码产物变成了一堆无意义的汉字组合。此外还有一类不太容易发现的问题是“能显示但是部分字不显示”比如控制台里英文正常、中文消失。这种情况通常跟控制台字体缺失或代码页设置有关不是编码不编码的问题是字形渲染层面的问题。那为什么要强调“统一”因为乱码的本质就是规则冲突。只要数据从源头到显示每一步都用同一套字符集规则哪怕这套规则是冷门的GB18030都不至于乱码。现代项目的主流是UTF-8因为它能同时覆盖中英文、Emoji、生僻字而且IDEA、Maven、Git、Linux服务器、Docker这些工具链全部默认对UTF-8友好。所以我的方案全都围绕“把一切收敛到UTF-8”来做。有些老博客推荐把IDEA全局编码改成GBK那是因为当年Windows中文版系统整个环境都是GBK可现在这套思路会引发新的问题比如和Git仓库里的UTF-8文件冲突所以不推荐。2. 先改这三处全局编码设置搞定八成乱码2.1 统一File Encodings三项设置打开IDEA进入File - Settings - Editor - File Encodings。这个页面里有三项关键配置我把每一项的推荐值列在下面配置项推荐值作用范围Global EncodingUTF-8IDEA全局默认编码Project EncodingUTF-8当前项目源码文件编码Properties FilesUTF-8.properties配置文件的编码必须同时勾选下方的“Transparent native-to-ascii conversion”这三项是整棵树的根。如果Project Encoding不是UTF-8而文件本身是UTF-8保存的IDEA读文件时就会乱码控制台里看到的中文自然也不对。顺带一提我遇到过同事的项目.java文件是GBK但Project Encoding是UTF-8编辑器里看正常git diff里全乱最后发现是IDEA的自动转换悄悄把文件编码改了。所以这种问题都得从根上查清楚再决定要不要动全局设置。Transparent native-to-ascii conversion这个选项值得多说一句。它的作用是读取Properties文件时自动把\uXXXX转成中文显示。保存时把中文自动转回\uXXXX避免Properties文件出现非ASCII字符。Properties文件用UTF-8裸编码保存在Java 8及以下环境下ResourceBundle加载会出问题因为老版本按ISO-8859-1读取Properties文件。所以Properties文件用\uXXXX转义是安全做法而勾选透明转换能让开发者在IDEA里看到可读中文且落盘仍是ASCII安全格式两头兼顾。2.2 确认控制台自带的Console编码选项同一页面往下滚底部还有一个Console下拉框。这是很多人容易遗漏的地方。它独立于上面三项专门控制IDEA内嵌控制台读取输出流时使用的解码字符集。一定要把它设为UTF-8和全局保持一致。我见过一个案例上面三处都改了控制台还是乱码后来发现就是Console下拉框留了空白IDEA按系统默认走了Windows下就变成GBK和UTF-8输出对不上。改完这三处加Console点Apply重启IDEA再看控制台。实测大约六成乱码问题在这一步就解决了。剩下的四成通常是启动JVM时的编码参数不对需要往下看。3. 改了编码还不生效直接对IDEA的启动参数下手3.1 用Help菜单的自定义VM参数一劳永逸如果File Encodings全改完仍然乱码问题多半出在IDEA启动JVM时没有指定file.encoding。这个参数决定了Java运行时默认用什么字符集去解码和编码。IDEA比较贴心提供了一个改启动参数的可视化入口Help - Edit Custom VM Options。第一次点它IDEA会自动在%USERPROFILE%\.IntelliJIdea版本号\config目录下创建idea64.exe.vmoptions文件可以用编辑器打开。这个文件里追加一行-Dfile.encodingUTF-8保存后重启IDEA。这一招的实际效果是IDEA主进程本身以UTF-8运行它继承给控制台子进程的环境变量也跟着一致。很多“改完File Encodings没用”的疑难杂症根子就在这里。还有进阶配置可以一起加比如-Dconsole.encodingUTF-8 -Dsun.jnu.encodingUTF-8sun.jnu.encoding是Java访问文件名时的编码在Windows上如果不显式指定默认跟着系统区域走曾遇到过打包或读写中文文件名时出现乱码加上这个参数后会稳定很多。不过要说明一下-Dconsole.encodingUTF-8在部分IDEA版本里不生效因为IDEA控制台不完全走原生System.console所以真正常用的还是file.encoding。如果改了vmoptions还是乱可以检查Help - Edit Custom Properties新建一个idea.properties文件内容加同样的编码参数。这个文件是IDEA自身属性优先级比vmoptions里的系统属性更高不过一般用不到这一步属于兜底手段。3.2 Windows系统区域设置是隐形变量Windows中文版控制台默认代码页是936GBK终端里跑Java程序时输出编码直接受代码页影响。即使程序内部指定了-Dfile.encodingUTF-8Windows控制台本身的解码还是按GBK来照样乱。对于只跑在IDEA里的场景上面IDEA的VM参数就足够覆盖需求了因为这些参数只影响IDEA进程内部的I/O和子进程环境和Windows系统区域设置无关。但如果你的程序需要直接在cmd里跑光调IDEA就不够了还需要在cmd窗口执行chcp 65001临时把控制台代码页切换成UTF-8。这个方法执行一次只对当前窗口有效新开的cmd窗口又回到936。想永久生效可以在系统环境变量里加一行JAVA_TOOL_OPTIONS-Dfile.encodingUTF-8这样所有Java进程运行时都会自动带上这个参数。不过这个方案范围太大容易影响到别的程序按需使用。还有个细节是PowerShell和IDEA控制台的差别。PowerShell 5.1默认还是GBKWindows Terminal则统一用UTF-8。所以同一个Java程序在IDEA的控制台里输出正常粘贴到PowerShell里跑却乱了并不是程序写错了而是两边所用的解码规则不同。知道了问题所在就不会来回改代码做无用功。3.3 单个项目级别的运行配置可以单独指定在Run/Debug Configurations里选中你的启动类比如Spring Boot的Application启动器右侧VM options一栏填入-Dfile.encodingUTF-8这个优先级最高只对当前这个运行配置生效。适合那种全局改不了、但某个项目必须输出UTF-8的场景比如客户现场要求必须GBK历史项目里单独把某个模块切到UTF-8。顺带提醒VM options里如果同时有-Dfile.encodingUTF-8和代码里手动设置字符集以代码里设置为准。比如Logback配置里显式把charset写成了GBK那JVM参数就完全不起作用。所以排查乱码不能只看全局得顺着输出链路一路查。4. 代码和日志配置里的编码也得跟着收敛4.1 Maven/Scala/Spring Boot的编译编码参数很多项目不是直接点Run启动的而是经Maven先编译再运行。Maven编译过程默认按项目pom.xml里project.build.sourceEncoding决定源码读取编码。如果这里写的是GBK而文件实际是UTF-8编译过程本身就会产生乱码最终字节码里的字符串常量就已经不对控制台怎么调都是白费。在pom.xml里加入这段配置properties project.build.sourceEncodingUTF-8/project.build.sourceEncoding project.reporting.outputEncodingUTF-8/project.reporting.outputEncoding /propertiesSpring Boot项目一般还会配合spring.messages.encodingUTF-8让国际化的ResourceBundle读取正确。其实只要你项目里所有源码文件都是UTF-8把上面两个properties补上Maven编译出来的class内部字符串就是UTF-8不会在编译这关被破坏。4.2 代码里读写文件别依赖默认编码很多乱码问题不是控制台显示而是程序生成的日志文件打开是乱码。这类问题常见是因为代码里用了FileWriter writer new FileWriter(out.txt);FileWriter没有指定字符集走的是JVM默认编码。如果JVM默认是GBK写出来的文件就是GBK而文本编辑器按UTF-8打开自然乱码。这种写法在国内好多老项目里还大量存在属于看着没问题、换个环境就爆雷的经典代码。改法是显式指定编码比如BufferedWriter writer Files.newBufferedWriter( Paths.get(out.txt), StandardCharsets.UTF_8 );Java 7以上都支持Files.newBufferedWriter它允许直接传入字符集简洁又能避免默认编码坑。如果是读取文件BufferedReader reader Files.newBufferedReader( Paths.get(in.txt), StandardCharsets.UTF_8 );显式指定UTF-8读入不再依赖环境变量或系统区域。这个习惯养成之后你的程序放到任何操作系统、任何字符集环境下行为都是一致的。在团队里别人拷走代码换个环境就跑乱码的问题也会少很多。4.3 日志框架的Charset设置容易被忽略项目里普遍用Logback或Log4j2输出日志。控制台乱码的时候很多人盯着IDEA设置反复改实际上日志框架有独立的编码配置。Logback的logback.xml里ConsoleAppender的encoder里有一个charset标签例如appender nameSTDOUT classch.qos.logback.core.ConsoleAppender encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appenderFileAppender同理也要加appender nameFILE classch.qos.logback.core.rolling.RollingFileAppender filelogs/app.log/file rollingPolicy classch.qos.logback.core.rolling.TimeBasedRollingPolicy fileNamePatternlogs/app.%d{yyyy-MM-dd}.log/fileNamePattern maxHistory7/maxHistory /rollingPolicy encoder pattern%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n/pattern charsetUTF-8/charset /encoder /appenderLog4j2则在log4j2.xml里用PatternLayout charsetUTF-8指定。加了charsetUTF-8/charset之后Logback在写日志时会显式按UTF-8编码不再问JVM要默认值。这能避免一种怪象IDEA控制台显示正常因为File Encodings改对了但日志文件在Windows下打开时用记事本看是乱码因为FileAppender写出的字节是GBK而记事本默认尝试按ANSI读取两边就对上了。但这非常误导人因为你在IDEA里看日志文件又正常因为你用的打开工具不一样解码方式不一样。只有代码和配置同时显式指定UTF-8才能保证文件字节本身就是UTF-8所有编辑器打开都一致。5. 常见乱码场景的排查顺序以及我踩过的几个坑5.1 按现象分类的速查表我把实际遇到过的乱码场景整理成下面的表排查时直接按行对照。现象可能原因首选的排查动作控制台整体乱码英文正常输出流编码与控制台解码不一致将File Encodings和Console编码都设为UTF-8重启IDEA控制台里中文变成???JVM启动时未指定file.encoding或字体不支持修改vmoptions加-Dfile.encodingUTF-8日志文件里中文乱码控制台正常Logback/Log4j2未指定charset在encoder里加charsetUTF-8/charset某些项目乱某些项目不乱项目的Project Encoding不一致按项目逐一检查File Encodings源码文件打开就乱码文件实际编码与Project Encoding不同用File - File Properties查看实际文件编码cmd里运行Java程序乱码IDEA正常cmd代码页与程序编码不一致cmd里执行chcp 65001或加启动参数只用Gradle构建后运行乱码Gradle JVM编码未设置在gradle.properties中设置org.gradle.jvmargs-Dfile.encodingUTF-85.2 网上流传的“改locale”办法谨慎使用有些帖子为了根治Windows问题建议把系统区域设置里的“Beta: 使用Unicode UTF-8提供全球语言支持”勾上。这个做法确实能让整个Windows系统走UTF-8控制台、文件、路径里全部统一但是副作用很大部分老软件在简体中文区域下按GBK读取配置勾选后直接无法显示文字甚至打不开。如果不是公司内部统一要求全用UTF-8的现代化环境不建议在生产工作机上动这个开关。我的态度很明确尽量只改自己项目、自己IDEA范围内的变量不要去动系统级的区域设置那样影响面太大出了问题很难回溯。5.3 Tomcat、Jetty等容器内的乱码跑Java Web项目时乱码还可能发生在Web层面比如response输出到浏览器乱码、控制台却正常。这和IDEA控制台是两码事。典型的排查对象是server.servlet.encoding.charsetUTF-8server.servlet.encoding.enabledtrueserver.servlet.encoding.forcetrue加了forcetrue后强制请求和响应都按UTF-8处理能覆盖大多数自作主张的旧的编码头。这种情况建议用浏览器开发者工具看响应头的Content-Type字段如果显示charsetISO-8859-1说明服务器没把你的配置顶上去需要排查是不是有过滤器或拦截器在返回前修改了编码。5.4 一个容易被忽略的坑IDEA缓存和重启有次改完vmoptions控制台还是乱码查来查去发现IDEA确实加载了新参数但项目里有个模块是老同事手动new OutputStreamWriter(System.out)且没有指定编码导致输出永远按系统默认GBK来IDEA全局怎么改都拦不住代码里的强制指定。这不是配置问题是代码片段的问题。后面我把那段改成new OutputStreamWriter(System.out, StandardCharsets.UTF_8)控制台才干净。这个案例提醒我排查乱码时先全局搜一下代码里有没有手动指定编码的地方尤其是new String(...)、getBytes()和OutputStreamWriter这些是绕过全局设置的常见出口。5.5 关于“乱码文件修复”的实用办法如果已经产生了乱码日志文件直接改编码设置不会把已损坏的文件恢复。优先用VS Code或Notepad这类能识别编码的编辑器打开按正确编码重新保存。整理一下识别思路文件被GBK正确解读显示正常而用UTF-8打开出现乱码说明文件实际是GBK字节。文件被UTF-8正确解读显示正常而用GBK打开出现乱码说明文件实际是UTF-8字节。确定实际编码后在VS Code里执行“通过编码重新打开”选对编码再“通过编码保存”另存为UTF-8即可修复。如果修复的是一堆文件可以写一个小Python脚本逐文件转码批处理速度更快注意保留原文件备份。6. 我觉得值得单独说的几个心得做开发这些年乱码问题从来没断过但大部分不是高深的技术问题而是“环境规矩不一致”。IDEA默认UTF-8、Windows中文版默认GBK、JDK默认跟随系统这三者任何一个环节不打通控制台就会闹脾气。所以碰到乱码大可不必紧张先理顺是哪一环的问题。我个人最终的固定套路是新项目一律UTF-8从IDEA的File Encodings到pom.xml再到日志框架的charset全部显式写明。老项目如果捆绑GBK太深就不强行全改UTF-8但会在IDEA里针对旧项目单独设置Project Encoding为GBK控制台Console也配套改成GBK保持内部编码一致。控制台偶发乱码优先改vmoptions而不是改代码或系统设置因为改配置的代价和风险都最低。最后分享一个小技巧如果你改完所有配置后控制台仍然乱码试试点IDEA控制台右上角的“Scroll to the End”旁边那个“Spinner”按钮——也就是清空控制台重新输出一次。有时候IDEA控制台缓冲区里的旧日志已经被错误编码解码并缓存在界面里了清空后重新打印往往就正常了。这个算不上技术但急救时很管用。