java无标准api可靠检测文本编码，需依赖bom检查或统计型库；bom可快速识别utf系列编码，而juniversalchardet和hutool的fileutil则适用于无bom场景，后者封装更优。
Java 本身没有标准 API 能直接、可靠地检测任意文本文件的字符编码。检测必须依赖字节层面的分析，核心方法是检查 BOM 标记或使用统计型识别库。
看文件开头是否有 BOM（快速判断 UTF 系列）
BOM（Byte Order Mark）是某些编码在文件头部写入的特殊字节序列，可作为明确依据：
- UTF-8：前 3 字节为 0xEF 0xBB 0xBF（即 byte[] = {-17, -69, -65}）
- UTF-16 BE：前 2 字节为 0xFE 0xFF
- UTF-16 LE：前 2 字节为 0xFF 0xFE
- UTF-32 BE / LE 也有对应 BOM，但极少见
- GBK、ISO-8859-1、Big5 等传统编码通常无 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") 解码再检查乱码——这既不可靠，又消耗资源：
- 不同编码解码后可能都“看起来正常”，尤其纯 ASCII 内容
- 中文混合符号时极易误判
- 仅适合临时调试，生产环境应避免
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
