关键在于准确识别源文件真实编码并在读取时显式指定，而非适配所有编码；乱码主因是用错charset解码字节流，确认编码需借助工具（如notepad++、file -i）或文档，慎用自动探测库；读取时禁用默认编码，强制使用standardcharsets或标准名称（如gbk、gb18030、big5），配合inputstreamreader与bufferedreader并用try-with-resources管理资源。
Java 中处理非 UTF-8 编码文件的乱码问题，关键不是“适配所有编码”，而是**准确识别源文件真实编码，并在读取时显式指定它**。乱码几乎都源于“用错的 Charset 去解码字节流”，只要这一步做对，后续字符串操作就完全安全。
确认文件真实编码
不能靠猜测或系统默认值。常见非 UTF-8 编码有 GBK、GB18030（兼容 GBK 且支持更多生僻字）、Big5（繁体）、ISO-8859-1（常用于旧系统或 HTTP 默认）等。
- 用工具辅助判断：Notepad++ 右下角显示当前编码；Linux/macOS 下运行
file -i filename；VS Code 打开后右下角点击编码名可切换并预览效果 - 若来源明确（如老系统导出的 Excel CSV、政府接口返回文本），优先查文档或沟通确认编码
- 慎用自动探测库（如 juniversalchardet）：对含少量中文或纯数字字母的文件误判率高，生僻字更难识别，仅作参考
读取时强制指定 Charset
跳过平台默认编码（Charset.defaultCharset()），直接传入已确认的编码。推荐使用 StandardCharsets 静态常量或标准名称字符串：
- 读 GBK 文件：
new InputStreamReader(new FileInputStream("a.txt"), StandardCharsets.UTF_8)❌ 错误写法；应为StandardCharsets.GBK或"GBK" - 读 GB18030 文件（推荐用于含生僻字的中文数据）：
new InputStreamReader(is, Charset.forName("GB18030")) - 读 Big5 文件：
new InputStreamReader(is, "Big5")（注意大小写不敏感，但建议大写） - 避免写
"utf8"、"gb2312"等非标准名，可能抛UnsupportedEncodingException
包装 BufferedReader 并规范资源管理
InputStreamReader 是桥梁，本身无缓冲；配合 BufferedReader 才能高效按行读取，且避免手动处理换行符逻辑错误。
- 必须用 try-with-resources 确保流关闭，防止句柄泄漏
- 示例（读 GB18030 文件）：
try (FileInputStream fis = new FileInputStream("data.txt");
InputStreamReader isr = new InputStreamReader(fis, "GB18030");
BufferedReader br = new BufferedReader(isr)) {
String line;
while ((line = br.readLine()) != null) {
System.out.println(line); // 此时已是正确 Unicode 字符串，可放心处理
}
}
写入与转换环节不引入新编码错误
只要读取阶段已得到正确的 String，后续所有操作都应在内存中以 Unicode 进行。只有在写入新文件或传输时才需再次指定编码——且目标编码要明确、有意为之。
- 不要把“读错的字符串”再转成字节数组：比如用 GBK 读了 UTF-8 文件，得到乱码字符串，再调用
str.getBytes("UTF-8")写出，结果是二次损坏 - 若需转码输出（如把 GBK 源文件内容存为 UTF-8）：
Files.write(path, content.getBytes(StandardCharsets.UTF_8)) - 控制台输出乱码？那通常是终端/IDE 控制台自身编码设置问题，和 Java 代码无关，需单独调整（如 Windows CMD 改用
chcp 65001）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
