java默认字符集由-dfile.encoding控制，但仅影响string.getbytes()、filereader/writer等有限操作；它不控制网络、数据库、日志等场景，且cmd乱码还取决于终端代码页与字体，故应始终显式指定standardcharsets.utf_8。
Java 中的默认字符集由 JVM 启动时的 -Dfile.encoding 参数决定，但它**不是万能开关**，也不能单靠它“一劳永逸”解决所有乱码问题。它的实际作用范围有限，且受操作系统、IDE、构建工具等多层影响。
–Dfile.encoding 控制哪些行为
该参数主要影响以下几类操作的默认编码方式：
- String.getBytes() 和 new String(byte[]) 的无参重载（即不显式传入 charset 名称时）
- FileReader / FileWriter 构造器（底层依赖平台默认 Charset，而 -Dfile.encoding 会覆盖该默认值）
- System.console().reader()/writer()（在支持 Console 的环境）
- 部分未显式指定编码的 I/O 工具类，如 Scanner（使用 System.in 时）
⚠️ 注意：它不控制 class 文件读取、网络传输（如 HTTP 请求体）、数据库连接、日志框架输出、或第三方库内部的编码逻辑——这些都需各自单独配置。
为什么 System.getProperty("file.encoding") 显示 UTF-8，但 CMD 是 GBK？
因为 -Dfile.encoding 是 JVM 级别参数，只对当前 JVM 实例生效。你在 IDEA 中运行程序时，IDEA 默认会向 JVM 传递 -Dfile.encoding=UTF-8（即使系统 chcp 显示 936），所以 System.getProperty("file.encoding") 返回 UTF-8 是正常的。这说明 JVM 已按你（或 IDE）的意图设置了默认编码，而非继承自操作系统终端。
真正决定 CMD 输出是否乱码的，是：
– Windows 控制台当前代码页（chcp）
– 终端字体是否支持对应字符
– JVM 输出流（System.out）写入字节后，终端用什么编码去解码这些字节 —— 这个解码过程不由 JVM 控制，而是由 CMD 自己完成。
如何正确配置并验证
推荐在启动 Java 程序时显式指定：
-
命令行启动：
java -Dfile.encoding=UTF-8 MyApp -
IDEA 配置：
File → Settings → Build → Compiler → Java Compiler → “Project encoding” 设为 UTF-8；
同时在 Run → Edit Configurations → VM options 中添加
-Dfile.encoding=UTF-8 -
Maven/Gradle 构建：
在
maven-surefire-plugin或test任务中配置<argline>-Dfile.encoding=UTF-8</argline>
✅ 验证是否生效：运行以下代码
System.out.println(System.getProperty("file.encoding")); // 应输出 UTF-8
System.out.println(Charset.defaultCharset()); // 应返回 utf-8 的 Charset 实例
更可靠的替代方案：始终显式指定编码
比起依赖 -Dfile.encoding，更健壮的做法是在所有涉及字节与字符串转换的地方，强制传入 Charset 名称：
"文本".getBytes(StandardCharsets.UTF_8)new String(bytes, StandardCharsets.UTF_8)Files.readString(path, StandardCharsets.UTF_8)new InputStreamReader(inputStream, StandardCharsets.UTF_8)
这样可完全规避默认编码带来的不确定性，尤其在跨环境部署（Linux 服务器默认 locale 可能是 en_US.UTF-8，而 Windows 开发机是 zh_CN.GBK）时尤为关键。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
