Java Files.readString 怎样指定字符集避免中文乱码

我在接手一段 Java 文件导入代码时，最先看到的症状是中文字段变成了连续的问号或不可读字符。问题并不在 String，而在“文件字节使用什么字符集解释”这一步。Files.readString(path) 的无参重载固定按 UTF-8 解码；如果文件来自旧系统、Windows 工具或人工导出，真实编码可能是 GB18030 等其他字符集，这时就要使用带 Charset 参数的重载。

小文本且确认是 UTF-8 时直接使用 Files.readString(path)；文件编码已知但不是 UTF-8 时显式传入对应的 Charset。不要靠修改系统区域设置来碰运气。

为什么默认重载会读出乱码

文件保存的是字节，Java 程序需要用字符集把这些字节解码成字符。只要保存端和读取端的字符集不一致，乱码就会在读取阶段产生。Oracle 的 Java SE API 明确说明，Files.readString(Path) 等价于使用 StandardCharsets.UTF_8 的重载，它不会根据操作系统当前语言自动切换。

这条规则的好处是跨机器稳定：同一个 UTF-8 文件在不同服务器上有一致结果。代价是旧文件不能被“猜编码”。例如文件实际用 GB18030 保存，却调用无参重载，解码器拿 UTF-8 规则解释字节，中文就可能变成乱码，甚至抛出解码异常。

显式 Charset 才是非 UTF-8 文件的稳定入口

当文件来源协议已经写明编码时，把它直接表达在调用处。UTF-8 使用标准常量；GB18030 这类编码可以通过字符集名称获取。示例只负责读取一个适合一次性装入内存的小文本文件，异常交给调用方决定是重试、记录还是拒绝导入。

import java.io.IOException;
import java.nio.charset.Charset;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Path;

public final class TextFileReader {
    private TextFileReader() {}

    public static String readUtf8(Path path) throws IOException {
        // 文件协议明确为 UTF-8 时，使用标准常量表达约定。
        return Files.readString(path, StandardCharsets.UTF_8);
    }

    public static String readLegacy(Path path) throws IOException {
        // 旧系统导出的文本若明确使用 GB18030，就显式指定解码字符集。
        Charset charset = Charset.forName("GB18030");
        return Files.readString(path, charset);
    }
}

不要把 Charset.forName("GB18030") 当成通用乱码修复按钮。它只适用于来源确实采用该编码的文件；如果源文件是 UTF-8，强行换成 GB18030 同样会得到错误文本。工程上最好让上传协议、文件扩展名约定或元数据明确记录字符集，而不是从乱码结果反推。

字符集问题和 BOM、换行符不是一回事

排查时我会把三个问题分开：第一，字节是否用正确字符集解码；第二，开头是否带 BOM；第三，换行符是否需要保留。readString 会读取文件中的换行符，包括末尾换行，但它不会替业务代码清理 BOM，也不会替你判断字段格式。

因此，看到第一列字段多出一个不可见字符时，不要立即改成 GB18030；先确认文件是否是带 BOM 的 UTF-8，再决定是否在业务层处理首字符。字符集选择解决的是“字节如何变成字符”，字段清洗解决的是“字符内容是否符合业务规则”，两者的责任边界不同。

什么时候不该继续使用 readString

Files.readString 的 API 目标是方便地读取完整文本，官方文档也提醒它不适合非常大的文件。它会把内容一次性物化成一个 String，所以文件大小、字符数量和堆内存都要放进同一个判断里。字符集传对了，并不意味着内存风险消失。

可以按下面的判断做选择：

把字符集约定写进代码和测试

最终我会留下三条检查项：确认文件生产端的编码；在读取调用处显式表达非 UTF-8 规则；用包含中文、BOM 和末尾换行的样例覆盖解码边界。这样排查时就能先定位字节域、解码域还是业务清洗域，而不是反复更换字符集。

如果文件协议尚未定义编码，正确的修复不是在代码里猜一个“最常见”的字符集，而是补齐协议字段或让生产端统一输出 UTF-8。读取端只能忠实执行约定，不能从一串已经损坏的字符中可靠恢复原文。

相关问题

Files.readString 会自动识别文件编码吗？

不会。无参重载按 UTF-8 读取，其他编码必须由调用方显式提供。

为什么传入正确 Charset 仍然有乱码？

继续检查文件是否带 BOM、实际导出编码是否与协议一致，以及后续字段清洗或数据库连接是否再次发生了错误转码。

大文件只换成 UTF-8 就能解决内存问题吗？

不能。字符集只影响解码规则，readString 仍然会一次性构造完整字符串；文件规模不稳定时应改用分段处理。