旧版JDK配置类读取隐式乱码面向对象逻辑优雅规避方法

面对旧版JDK中配置文件乱码问题，许多开发者首先想到的是更换编码或添加过滤器，但这些方式往往治标不治本。更优雅的做法是将“读取配置”这一行为封装成可配置、可替换、可测试的对象，从而在设计层面隔离乱码风险，而非在运行时靠猜测来补救。

核心思路极为简洁：将配置加载行为抽象为接口，借助组合与策略模式，使编码问题与数据源彻底解耦。下面我们逐一展开说明。

把配置加载行为抽象成接口

不要一开始就直接使用 Properties.load() 进行硬编码。建议先定义一个 ConfigLoader 接口，它仅暴露 load(String path) 或 load(InputStream is) 方法，返回 Map 或自定义对象。不同的实现类各司其职：Utf8PropertiesLoader 采用 UTF-8 解码，Native2AsciiLoader 处理 Unicode 转义，AutoDetectingLoader 自动嗅探 BOM 标记。调用方无需关心底层使用的是 ISO-8859-1 还是 UTF-8，只需遵循接口契约即可——这样便实现了“怎么读”与“读什么”的分离。

用组合代替硬编码路径

Properties 类本身并非问题根源，真正的问题在于滥用 new Properties() 并直接调用 load(InputStream)。采用组合设计：创建一个 WrapperProperties 类，内部持有 Properties 实例以及 Charset 字段。构造时传入 StandardCharsets.UTF_8，load 方法仅接受 InputStream，并在内部自动包装为 InputStreamReader。这样做既能复用 Properties 的解析能力（包括对 uXXXX 转义的支持），又能绕过其 ISO-8859-1 的硬编码限制。此外，还可以添加横切逻辑，例如日志记录、空行过滤、键名大小写标准化等。

让配置源和编码策略解耦

同一份配置文件，在开发环境中可能是 UTF-8 编码，而在遗留生产环境中却是 GBK。面向对象的做法是将“数据来源”与“读取方式”完全分离：定义 ConfigSource 接口（提供 getResourceAsStream()、getFilePath()、asBytes() 等方法来获取原始字节流），再定义 CharsetStrategy 接口（负责 guessCharset(byte[])、getFixedCharset()、fallbackTo(StandardCharsets.GBK)）。ConfigReader 类接收这两个依赖，首先获取字节数据，然后根据策略选择字符集，最后交由 Properties.load(Reader) 处理。不同环境仅需注入不同的 Strategy 实现，无需修改任何业务代码。

用工厂+SPI支持运行时切换

避免在代码中使用繁琐的 if-else 判断 JDK 版本或文件后缀。采用标准的 Java SPI 机制：在 META-INF/services 目录下声明 com.example.ConfigLoader，并提供多个实现如 jdk8-utf8-loader、jdk11-gbk-loader 等。启动时通过 ServiceLoader.load(ConfigLoader.class) 自动选择匹配的实现。甚至可以利用系统属性 -Dconfig.loader=gbk 动态加载对应的实现——这才是真正的运行时切换能力。