FileReader无法指定字符编码，因其构造器不接受charset参数，仅依赖系统默认编码，易致跨平台乱码；正确做法是用InputStreamReader包装FileInputStream并显式指定编码。
FileReader 无法指定字符编码集——它压根没有提供任何接受 charset 参数的构造方法。所有试图“给 FileReader 设置编码”的操作，本质上都是绕过它，用 InputStreamReader 替代。
为什么 FileReader 根本不支持指定编码
它的构造器只有两个：FileReader(String fileName) 和 FileReader(File file)，连 Charset 或编码名字符串参数都没有。所谓“默认使用平台编码”，其实是把解码责任甩给了 FileInputStream → InputStreamReader 这一隐式链路，而你完全无法干预中间环节。
这意味着：
- Windows 上默认按
GBK解码，读 UTF-8 文件必乱码（尤其含中文或 BOM） - Linux/macOS 默认可能是
UTF-8，但遇到 ISO-8859-1 编码的老配置文件仍会错解为代理对 - 即使设置
file.encodingJVM 参数，FileReader也视而不见
正确做法：用 InputStreamReader + FileInputStream 替代 FileReader
必须显式切断 FileReader 的默认解码路径，改走可控的字节流→字符流转换链：
try (InputStream fis = new FileInputStream("legacy.conf");
InputStreamReader isr = new InputStreamReader(fis, "ISO-8859-1");
BufferedReader reader = new BufferedReader(isr)) {
String line;
while ((line = reader.readLine()) != null) {
System.out.println(line);
}
}
关键点：
- 不要写
new FileReader(...)，哪怕只读一行也不行 - 编码名必须与文件真实编码一致；老旧文件常见编码包括
ISO-8859-1、GBK、Big5、Windows-1252 - 推荐用
StandardCharsets.ISO_8859_1等常量代替字符串，避免拼写错误 - 务必套
BufferedReader，否则每次read()都触发系统调用，性能极差
如何确认老旧文件的真实编码
不能靠猜，得验证：
- Linux/macOS 终端执行：
file -i legacy.conf，看输出中的charset=字段 - Windows 下用 VS Code 打开，右下角状态栏显示当前识别的编码；点击可重新以其他编码重载
- 若文件开头有 BOM：
head -c 3 legacy.conf | xxd查看前几个字节（ef bb bf= UTF-8 BOM） - 用
TextDecoder在浏览器控制台试探（仅限前端调试）：new TextDecoder('gbk').decode(new Uint8Array(arrayBuffer))
容易忽略的坑：BOM 和自动编码探测失效
很多老旧文件带 BOM，但 InputStreamReader 不会自动跳过它——比如 UTF-8 BOM（EF BB BF）在 GBK 解码下会变成「锟斤拷」开头；反过来，用 UTF-8 解 ISO-8859-1 文件，BOM 字节会被当普通字符解析，导致第一行内容偏移。
更麻烦的是：某些工具（如 file 命令）对无 BOM 的老旧编码识别不准，可能把 GBK 误报成 UTF-8。这时只能靠人工观察乱码规律反推，例如：
- 中文显示为两个问号（）→ 很可能是 GBK 写入、UTF-8 读取
- 英文后紧跟方块或符号 → 可能是 ISO-8859-1 中的控制字符被 UTF-8 错解
一旦编码判断错误，后续所有文本处理都不可信——这个环节没法自动化，必须人工交叉验证。
