java乱码本质是编码与解码字符集不一致：需先确认文件真实编码（notepad++、file/enca命令），再确保java显式指定charset（禁用默认编码），并统一jvm、ide、控制台编码，同时处理utf-8 bom问题。
字符串乱码不是字符“坏了”，而是字节被用错了规则去解读。Java里所有乱码问题，归根结底就一件事：编码端和解码端用的字符集不一致。
先确认文件或数据的真实编码
别猜，要检测。乱码常发生在读取阶段，而根源往往在源头——文件本身存的是什么编码？
- 用 Notepad++ 打开文件，右下角直接显示当前编码（如 UTF-8、GBK、UTF-8-BOM）
- Linux/macOS 下运行：file -i filename 或 enca -L zh filename
- 如果文件由别人提供，务必问清保存时用的编码；若来自网页/数据库/API，查响应头、建表语句或文档说明
检查 Java 程序的解码方式是否匹配
这是最常翻车的一环。很多代码看似简洁，实则暗藏默认编码陷阱：
- new String(bytes) → 用的是 JVM 默认编码（Windows 常为 GBK，Linux/macOS 常为 UTF-8），极不可靠
- FileReader / FileWriter → 不接受编码参数，强制使用平台默认编码，应避免用于中文场景
- 正确写法是显式指定 Charset：new String(bytes, StandardCharsets.UTF_8) 或 new InputStreamReader(in, StandardCharsets.UTF_8)
- 用 Apache Commons IO 更省心：FileUtils.readFileToString(file, StandardCharsets.UTF_8)
排查 JVM 和运行环境的默认编码
即使代码写了 UTF-8，也可能被环境覆盖：
- 运行时加参数强制统一：java -Dfile.encoding=UTF-8 MyApp
- IDE 中检查：IntelliJ → File → Settings → Editor → File Encodings，确保 Project Encoding 和 Default encoding for properties files 都设为 UTF-8
- 控制台输出乱码？Windows cmd 可执行 chcp 65001 切换到 UTF-8；更稳妥的是用 PrintWriter 包装输出流，指定编码
- 验证当前默认编码：System.getProperty("file.encoding")，打印出来看看是不是你预期的
注意 BOM 和特殊格式干扰
某些编辑器（如 Windows 记事本）保存 UTF-8 时会悄悄加上 3 字节 BOM（EF BB BF），Java 读成字符串后开头多出一个 \uFEFF，可能引发解析失败或显示异常：
- 读取后手动过滤：content.startsWith("\uFEFF") ? content.substring(1) : content
- 推荐用 Notepad++ 或 VS Code 将文件另存为 “UTF-8 无 BOM” 格式
- 避免用 Files.readAllLines(path) 直接读取，它不处理 BOM；改用带 Charset 的 BufferedReader
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
