Windows运行Java乱码解决方法_chcp与GBK转换

chcp 65001 仅设置控制台代码页为 UTF-8，Java 编译需 -encoding UTF-8、运行需 -Dfile.encoding=UTF-8，且源文件须存为 UTF-8 无 BOM；三者缺一不可，否则必然乱码。

chcp 65001 后 Java 输出还是乱码？别急，这不是编码没切对

根本原因是 Windows 控制台（cmd/powershell）的 chcp 只改了终端的代码页，而 Java 默认用系统默认编码（通常是 GBK）读取源文件、输出字符串——两者不一致时，控制台按 UTF-8 解码，Java 却按 GBK 编码，结果就是字节错位、显示成方块或问号。

• chcp 65001 是必须的，但只是第一步；它让控制台能“接收” UTF-8 字节流
• Java 编译和运行时仍可能用 GBK 处理字符串，尤其当你没指定源文件编码、也没显式设置输出编码时
• IDE（如 IntelliJ）里跑正常，命令行乱码？大概率是 IDE 自动加了 -encoding UTF-8 和 -Dfile.encoding=UTF-8，而你手动运行时漏了

javac 编译时报 “非法字符：’\ufffd’”？源文件编码没对齐

这个错误说明 javac 读源码时解码失败，把 UTF-8 字节当 GBK 解了。比如中文“你好”在 UTF-8 下是 0xe4 0xbd 0xa0 0xe5 0xa5 0xbd，若用 GBK 解，前两个字节 0xe4 0xbd 在 GBK 中不是合法字符，就变成 \ufffd（替换符）。

• 保存 Java 源文件时，必须用 UTF-8 无 BOM 格式（Notepad++ / VS Code 都可设；记事本默认带 BOM，会额外多出 0xef 0xbb 0xbf，javac 不认）
• 编译时强制指定源码编码：javac -encoding UTF-8 Main.java
• 如果项目里有中文字符串字面量、注释、甚至类名含中文（不推荐），这步不能省

java 命令运行后中文输出仍是乱码？file.encoding 决定运行时行为

即使源码编译成功，JVM 运行时默认用系统编码（Windows 上是 GBK）处理 System.out.println() 的内容。它把字符串转成字节写入 stdout，而控制台此时是 chcp 65001（UTF-8），自然对不上。

• 必须加 JVM 参数：java -Dfile.encoding=UTF-8 Main
• 注意：-Dfile.encoding 影响字符串到字节的转换，也影响 new Scanner(System.in) 的输入解码
• 不要只写 -Dfile.encoding=GBK 来“迁就”控制台——那等于倒退回旧模式，跨平台时必崩
• PowerShell 用户额外注意：chcp 65001 在 PowerShell 中需配合 $OutputEncoding = [System.Text.UTF8Encoding]::new()，否则 java 输出仍可能被截断或二次乱码

想一劳永逸？别依赖 chcp，改终端或换工具更可靠

靠每次输 chcp 65001 和一堆 JVM 参数，容易漏、难维护，尤其写脚本或 CI 场景下。真正稳定的做法是绕过 cmd 的老旧代码页机制。

• 用 Windows Terminal（微软商店免费下载），默认支持 UTF-8，无需 chcp，java -Dfile.encoding=UTF-8 就够
• VS Code 集成终端默认也是 UTF-8，且可配置 Java 扩展自动加参数
• 实在要用 cmd，可在快捷方式目标中加 /k chcp 65001 >nul，但不解决 JVM 编码问题，仍要配 -Dfile.encoding
• 最隐蔽的坑：某些国产杀毒软件或输入法会 hook 控制台，干扰 UTF-8 输出，表现为偶尔乱码——换终端能快速验证是不是环境干扰

真正卡住人的，往往不是哪个命令没敲对，而是以为改了 chcp 就万事大吉，忽略了 Java 编译、运行、终端三端编码必须严格对齐。少一个环节，就多一个乱码点。