Java读取文件乱码的根本原因是程序字符编码与文件实际编码不一致，需明确文件真实编码并显式指定，禁用系统默认编码，处理BOM，统一项目UTF-8规范。
Java读取文件时出现乱码，根本原因是程序使用的字符编码与文件实际编码不一致。关键在于明确文件真实编码，并在读取时显式指定，而不是依赖系统默认编码（如Windows的GBK、Linux/macOS的UTF-8）。
确认文件的真实编码格式
不能仅凭文件扩展名或编辑器显示判断编码。推荐使用以下方式验证：
- 用支持编码检测的文本编辑器（如Notepad++、VS Code）打开文件，查看右下角显示的编码名称；
- 用命令行工具检测：Linux/macOS下可运行 file -i filename，Windows可用PowerShell命令 Get-Content filename -Encoding Byte | Select-Object -First 10 查看BOM头（如EF BB BF代表UTF-8）；
- 若文件无BOM且无明确来源，可尝试用开源库（如juniversalchardet）进行概率化检测，但结果仅供参考。
读取时显式指定编码，禁用系统默认
Java中很多API默认使用 Charset.defaultCharset()，这是隐患源头。必须主动传入正确的Charset对象：
- 使用 Files.readAllLines(path, StandardCharsets.UTF_8) 替代 Files.readAllLines(path)；
- 使用 new InputStreamReader(new FileInputStream(file), StandardCharsets.GBK) 而非 new FileReader(file)（后者隐式使用默认编码）；
- 用Scanner读取时： new Scanner(file, "UTF-8")，注意第二个参数是编码字符串，不是Charset对象。
处理带BOM的UTF文件（尤其是UTF-8）
部分编辑器保存UTF-8文件时会写入BOM（Byte Order Mark），而Java标准API不会自动跳过它，导致首行开头多出“”等乱码字符：
立即学习“Java免费学习笔记（深入）”；
- 读取前先检查并剥离BOM：可用Apache Commons IO的 BOMInputStream，或手动读取前3字节判断是否为EF BB BF；
- 更稳妥的做法是统一要求文件不带BOM，或在保存时选择“UTF-8 without BOM”选项；
- 如果必须兼容，可在读取后对第一行调用 line.replace("\uFEFF", "")（U+FEFF是BOM的Unicode表示）。
统一项目编码规范，从源头减少问题
团队协作中，编码不一致常引发隐性Bug。建议：
- 所有源码文件、配置文件、资源文件强制使用UTF-8（无BOM）；
- 在IDE中设置全局编码：IntelliJ IDEA → File → Settings → Editor → File Encodings，将Global、Project、Default encoding for properties files都设为UTF-8；
- 构建工具层面约束：Maven项目在pom.xml中添加
UTF-8 ； - 读取外部文件（如用户上传、第三方接口返回）时，优先通过HTTP头、XML声明、JSON元数据等渠道获取编码信息，再动态构造InputStreamReader。
乱码问题本质是编码契约未对齐。只要坚持“知其编码、明示解码”，就能稳定读取各类文件。不复杂但容易忽略。
