Java Properties.load Reader 和 InputStream 的编码有什么区别

我第一次遇到 Properties.load 中文乱码时，代码看起来没有任何异常：同一个配置文件，换了一个重载，键还能读出来，值却变成了奇怪的字符。根因不在 Properties 会“随机选编码”，而在两个重载接收的输入层次不同。

官方文档：https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Properties.html

一句话结论：load(Reader) 接收已经解码成字符的输入，编码由创建 Reader 时决定；load(InputStream) 把输入流中的每个字节按 ISO-8859-1 解释。UTF-8 文件要保留中文，通常应使用 InputStreamReader 明确指定 UTF-8。

两个重载真正差在哪里

Reader 面向字符，InputStream 面向字节。调用 load(Reader) 时，字符集转换已经在进入 Properties 之前完成，Properties 只负责按属性格式解析键和值；调用 load(InputStream) 时，API 契约规定每个字节对应一个 Latin-1 字符，不能把它理解成“自动识别 UTF-8”。

ASCII 配置容易掩盖这个区别，因为 ASCII 字节在常见编码中一致。只要文件含中文、日文或其他超出 Latin-1 的字符，直接传 InputStream 就可能乱码。文件里的 \u4E2D 这类 Unicode 转义则是另一条路径：两个重载都会按 Properties 规则处理转义。

UTF-8 属性文件应该怎么读取

如果文件本身保存为 UTF-8，就把字符集选择写在 InputStreamReader 上。下面的示例只展示静态调用关系；真实项目中应让调用方负责关闭自己打开的文件流。

import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.nio.charset.StandardCharsets;
import java.util.Properties;

public class PropertiesReader {
    public static Properties loadUtf8() throws IOException {
        Properties properties = new Properties();
        // Reader 先按 UTF-8 把字节解码成字符，再交给 Properties 解析。
        try (InputStream input = PropertiesReader.class
                .getResourceAsStream("/app.properties")) {
            if (input == null) {
                // 资源不存在时尽早失败，避免把空配置误判为读取成功。
                throw new IOException("找不到 app.properties");
            }
            try (InputStreamReader reader = new InputStreamReader(
                    input, StandardCharsets.UTF_8)) {
                // load(Reader) 不再猜测文件编码，字符集由上面的 Reader 固定。
                properties.load(reader);
            }
        }
        return properties;
    }
}

这里最重要的是 StandardCharsets.UTF_8，而不是重载本身的名字。不要省略字符集参数改用默认编码的构造器，因为同一个包在不同运行环境中可能得到不同结果。还要注意 load 返回后输入流仍保持打开，示例用 try-with-resources 明确了关闭责任。

什么时候可以直接使用 load(InputStream)

如果属性文件按传统 Java Properties 的 ISO-8859-1 约定保存，非 Latin-1 字符写成 Unicode 转义，那么直接传 InputStream 是合适的。典型内容如下：

# Latin-1 文件中的非 Latin-1 字符使用 Unicode 转义
app.name=\u4E2D\u6587\u914D\u7F6E
app.mode=prod

这时可以使用下面的配对方式：

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

public class LegacyPropertiesReader {
    public static Properties loadLegacy(InputStream input) throws IOException {
        Properties properties = new Properties();
        // load(InputStream) 按 API 约定把每个字节当作 ISO-8859-1 字符。
        properties.load(input);
        // 不在这里关闭调用方传入的流，所有权仍由调用方决定。
        return properties;
    }
}

若文件是 UTF-8，却误用这个重载，中文的多字节序列会被拆成多个 Latin-1 字符。把文件改成转义格式可以匹配旧约定，但新代码更容易维护的方式通常是保留 UTF-8 文件，并显式创建 UTF-8 Reader。

读取和保存要成对考虑

选择读取重载时，也要看文件由哪个保存重载生成。store(OutputStream, ...) 输出 ISO-8859-1，并把不能直接表示的字符写成 Unicode 转义，适合与 load(InputStream) 配对；store(Writer, ...) 写入字符流，适合与 load(Reader) 配对。

我现在的判断顺序是：先确认文件实际保存的字符集，再看调用方能否拿到字符流；不要先凭“代码能跑”决定重载。只有键和值都是 ASCII 时，两种方式才容易表现得一样。

常见疑问

Reader 版本会跳过 Unicode 转义吗？不会。Reader 只决定字节如何变成字符，Properties 自己的属性转义规则仍然会继续处理。

load 方法会自动关闭输入流吗？不会。官方契约说明流在方法返回后仍保持打开，谁创建或拥有流，谁就应负责关闭。

用默认字符集的 InputStreamReader 可以吗？不建议。除非文件编码和运行环境默认编码被同一份部署约定严格固定，否则应显式传入 StandardCharsets.UTF_8 或文件实际使用的字符集。