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-api-doc-generator

分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。

下载

• 读取前先检查并剥离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。

乱码问题本质是编码契约未对齐。只要坚持“知其编码、明示解码”，就能稳定读取各类文件。不复杂但容易忽略。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南