Charset.forName() 不抛 UnsupportedEncodingException，而是抛 IllegalArgumentException；真正抛该异常的是 String.getBytes(String) 等老式 API；推荐用 StandardCharsets.UTF_8 或先调用 Charset.isSupported() 校验。
Charset.forName() 为什么抛出 UnsupportedEncodingException？
这个异常其实不会在 Charset.forName() 中抛出——它声明抛出的是 IllegalArgumentException。真正抛出 UnsupportedEncodingException 的是 String.getBytes(String) 或 new String(byte[], String) 这类老式 API。现代写法应优先用 Charset 实例，避免传编码名字符串。
- 传错名称（如写成
"UTF-8 "带空格、"utf8"少横线）会触发IllegalArgumentException -
StandardCharsets.UTF_8是最安全的获取方式，编译期检查，零异常风险 - 若必须动态加载，用
Charset.isSupported("GBK")先校验，再调用forName()
ISO-8859-1 和 US-ASCII 在 Charset 中有何实质区别？
二者都只覆盖 0x00–0x7F 范围，但语义不同：US-ASCII 明确要求字节值 0x00–0x7F 必须映射到对应 ASCII 字符；ISO-8859-1 则将 0x00–0xFF 全部定义（后半段是拉丁扩展），Java 中它的 new String(bytes, ISO_8859_1) 实际等价于“把每个 byte 当作 unsigned int 直接转 char”，常被用来做“假解码”绕过乱码。
-
StandardCharsets.US_ASCII解码时遇到 0x80+ 字节会抛MalformedInputException -
StandardCharsets.ISO_8859_1对任意字节都无条件接受，适合做字节↔字符透传 - 别用
ISO_8859_1去“修复” UTF-8 乱码文本——它只是掩盖问题，原始信息已损坏
如何检测字节数组实际使用的编码？
Java 标准库不提供可靠自动检测，Charset.availableCharsets() 只返回可用列表，不负责识别。真实场景需借助外部库或启发式规则。
-
InputStreamReader构造时不指定 charset，默认用Charset.defaultCharset()，这依赖系统环境，不可靠 - 可尝试用
UniversalDetector（来自 ICU4J）或cpdetector，但准确率受文本长度、语言、BOM 影响很大 - 有 BOM 时最稳妥：
0xEF 0xBB 0xBF→ UTF-8，0xFF 0xFE→ UTF-16LE，0xFE 0xFF→ UTF-16BE - 纯文本协议（如 HTTP）应以
Content-Type: text/plain; charset=utf-8显式声明，别指望猜
CharsetEncoder / CharsetDecoder 的 flush() 和 reset() 什么时候必须调用？
当你复用同一个 CharsetEncoder 或 Decoder 处理多段数据（比如网络分包、流式解析），且每段不保证是完整字符边界时，flush() 和 reset() 就关键了。
立即学习“Java免费学习笔记（深入）”；
-
encode()输入末尾若截断在一个 UTF-8 多字节序列中间（如只读到0xE4），encoder会缓存状态，下次encode()前必须flush()清空残留输出 -
reset()清除内部状态（如未完成的代理对、UTF-8 残留字节），否则后续输入可能被错误拼接 - 单次完整转换（如整个文件一次性读入）可忽略；流式处理或自定义 Channel 时漏掉会导致乱码或异常
ISO_8859_1 打开 UTF-8 文件，你看到的不是乱码而是完全合法的拉丁字符，但语义已彻底丢失。 
