java无法直接获取文件真实编码，需通过bom检测（如utf-8为ef bb bf）、juniversalchardet概率统计（建议读取4kb以上）或hutool的fileutil.getcharset()自动组合策略来识别；不推荐手动试探法。
Java 本身不提供标准 API 直接获取文件真实编码，必须依赖字节特征分析或第三方库。核心思路是：先读取文件头部（尤其是 BOM），再结合统计规律或规则匹配，综合判断最可能的编码。
看文件开头是否有 BOM 标记
BOM（Byte Order Mark）是最快速可靠的识别依据，但仅对部分编码有效：
- UTF-8：前 3 字节为 0xEF 0xBB 0xBF
- UTF-16 BE：前 2 字节为 0xFE 0xFF
- UTF-16 LE：前 2 字节为 0xFF 0xFE
- UTF-32 BE / LE、UTF-7 等也有对应 BOM，但实际中少见
- GBK、ISO-8859-1、ASCII 等传统编码通常无 BOM，不能靠此识别
用 juniversalchardet 做概率统计识别
这是 Mozilla 开源的成熟方案，基于字节频率和语言模型做多编码匹配，支持 UTF-8、GBK、Big5、Shift_JIS、ISO-8859 系列等几十种编码：
- Maven 引入：
com.github.albfernandez juniversalchardet 2.4.0 - 需读取足够字节数（建议至少 4KB），纯英文短文本易误判为 ISO-8859-1
- 代码示例：传入 InputStream 后调用 UniversalDetector.detectCharset()，返回如 "UTF-8" 或 "GB2312"
用 Hutool 的 FileUtil 一行搞定
Hutool 封装了 BOM 检查 + juniversalchardet + 启发式规则，自动跳过 BOM 并组合多种策略，对中文文本识别率高：
- Maven 引入：
cn.hutool hutool-all 5.8.22 - 调用方式简单：Charset charset = FileUtil.getCharset(file);
- 返回 Charset 对象，可直接用于 Files.readString(path, charset) 等操作
不推荐手动试探法
比如用不同编码反复 new String(bytes, "GBK") / new String(bytes, "UTF-8")，再检查是否乱码：
- 效率低，无法覆盖所有边界情况
- 对含控制字符、纯数字/英文文本极易误判
- 生产环境应避免，仅限临时调试
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
