旧版jdk数组读取乱码的根源是字符编码链路断裂，需显式指定charset贯穿i/o全流程：用inputstreamreader+bufferedreader替代filereader，优先使用standardcharsets常量；编码不明时探测前4kb字节按utf-8→gbk→iso-8859-1→big5顺序解码；写回时须保持同编码，禁用filewriter；bom需手动处理；-dfile.encoding仅作临时辅助。
旧版 JDK（Java 17 及之前）中数组读取出现乱码，本质不是数组结构的问题，而是字符编码链路断裂——从文件/输入流读取字节时，未显式指定与源数据一致的字符集，导致 JVM 依赖操作系统默认编码（如 Windows 上是 GBK），而实际文件可能是 UTF-8 或其他编码。规避的关键在于切断对 file.encoding 的隐式依赖，用明确的字符集贯穿 I/O 全流程。
用 BufferedReader + InputStreamReader 显式绑定编码
不要使用 FileReader（它强制使用系统默认编码且不可配置），必须组合 InputStreamReader 与 BufferedReader，并传入确定的 Charset 实例：
- 读取已知为 UTF-8 的配置文件：
new InputStreamReader(new FileInputStream("config.txt"), StandardCharsets.UTF_8) - 读取老旧 GBK 文件（如 Windows 记事本保存的中文配置）：
new InputStreamReader(fis, StandardCharsets.GBK) - 优先使用
StandardCharsets.XXX常量，避免字符串拼写错误（如"UTF-8"写成"UTF8"）
封装安全读取逻辑，自动适配常见旧编码
面对编码不明的遗留配置文件，可先探测再读取。不推荐全文件检测（性能差），可用前 4KB 字节快速判断：
- 用
Files.readAllBytes(path)读取头部字节，配合java.nio.charset.CharsetDecoder或第三方库（如 juniversalchardet）尝试解码 - 按常见优先级顺序试探：
UTF-8 → GBK → ISO-8859-1 → Big5，首个无异常解码成功的即为真实编码 - 封装为工具方法，返回
String[]数组时，确保每个元素都是经正确解码的 Unicode 字符串
数组内容写回时保持编码一致性
若需将处理后的数组（如修改后的配置项）写回文件，必须与读取时使用相同编码，否则形成“二次乱码”：
- 写入时同样禁用
FileWriter，改用OutputStreamWriter指定 charset - 示例：
try (Writer w = new OutputStreamWriter(new FileOutputStream("config.txt"), StandardCharsets.UTF_8)) { for (String line : configArray) w.write(line + "\n"); } - 若原文件含 BOM（如 UTF-8 with BOM），读取时需跳过 BOM 字节；写入时如需兼容旧工具，可手动写入
\uFEFF
运行时强制统一默认编码（辅助手段）
在无法修改代码的场景下，可通过 JVM 启动参数临时对齐环境：
- 启动命令加
-Dfile.encoding=UTF-8，使FileReader和未指定 charset 的 API 也走 UTF-8 - 注意：该方式治标不治本，仅适用于全项目确认所有配置文件均为 UTF-8 的情况
- 更稳妥的做法仍是代码层显式指定，避免被不同机器的系统 locale 干扰
