优先使用standardcharsets.utf_8等静态常量，因其零开销、线程安全、编译期校验；charset.forname()需运行时解析且可能抛异常，仅在动态编码名场景下配合try-catch使用。
Java里用Charset.forName()还是StandardCharsets？
直接结论：优先用 StandardCharsets 中的静态常量（如 StandardCharsets.UTF_8），而不是 Charset.forName("UTF-8")。前者零开销、线程安全、编译期校验；后者会触发类加载和字符串解析，可能抛出 UnsupportedCharsetException，且拼写错误只能到运行时才发现。
常见误用场景：从配置文件读取编码名再调用 Charset.forName(config.get("charset"))——这时必须加 try-catch，并 fallback 到默认值（如 StandardCharsets.UTF_8）。
- 所有 JDK 7+ 支持的字符集，
StandardCharsets都已预定义，包括US_ASCII、ISO_8859_1、UTF_8、UTF_16、UTF_16BE、UTF_16LE -
Charset.availableCharsets()返回的是 JVM 实际支持的映射表（含别名），但不建议遍历它做动态选择——别名不统一（如 "UTF8"、"utf-8"、"UTF-8" 都可能被接受，但行为未必一致）
byte[] ↔ String 转换时最容易踩的坑
核心问题：不显式指定 Charset，依赖平台默认编码。Windows 上是 GBK，Linux/macOS 通常是 UTF-8，同一段代码在不同环境输出乱码或解析失败。
正确写法永远带 Charset 参数：
立即学习“Java免费学习笔记（深入）”；
String s = new String(bytes, StandardCharsets.UTF_8); // ✅ byte[] b = s.getBytes(StandardCharsets.UTF_8); // ✅
反例（危险）：
String s = new String(bytes); // ❌ 用系统默认 byte[] b = s.getBytes(); // ❌ 同上
- 涉及 I/O 时同理：
InputStreamReader、OutputStreamWriter、Files.readAllLines(path, charset)必须传 Charset -
String.getBytes()不带参数时，返回的是平台默认编码的字节，不是 UTF-8 —— 即使你的源文件是 UTF-8 编码，也不代表运行时默认就是 UTF-8 - HTTP 场景下，
Content-Type: text/plain; charset=gbk中的 charset 值需手动提取并转成Charset对象，不能硬编码
需要“转换编码”时，其实只是重新解释字节序列
Java 没有内置的“UTF-8 → GBK 字符集转换函数”。所谓转换，本质是：先按原编码解码成 String，再按目标编码编码回 byte[]。中间 String 是 Unicode 抽象表示，不绑定任何字节格式。
例如把 GBK 字节转为 UTF-8 字节：
byte[] gbkBytes = ...; String s = new String(gbkBytes, StandardCharsets.GBK); // 先用 GBK 解码 byte[] utf8Bytes = s.getBytes(StandardCharsets.UTF_8); // 再用 UTF-8 编码
- 如果原始字节实际不是 GBK 编码（比如本是 UTF-8 却用 GBK 解），
new String(..., GBK)会产生或异常字符，后续转 UTF-8 也无法恢复 - 不推荐用
CharsetDecoder/CharsetEncoder手动处理，除非要控制替换策略（如CodingErrorAction.REPLACE）或流式处理超大文本 - 第三方库如 Apache Commons Codec 的
StringUtils或 Guava 的Charsets并未提供更底层的转换能力，只是封装了上述两步
跨语言/网络传输时 Charset 名称怎么写才可靠？
HTTP、XML、数据库连接字符串等外部协议中传递编码名，必须用 IANA 注册名称（如 UTF-8、ISO-8859-1），不能用 JDK 别名（如 UTF8、Latin-1）。
JDK 内部对大小写和横线不敏感（Charset.forName("utf8") 和 "UTF-8" 等价），但外部系统往往严格匹配。
- XML 声明必须写
<?xml version="1.0" encoding="UTF-8"?>，写成utf8或UTF8可能被某些解析器拒绝 - JDBC URL 中
useUnicode=true&characterEncoding=utf8是 MySQL 驱动的特例（它接受小写无横线），但标准做法仍是characterEncoding=UTF-8 - 检查
Charset.isSupported("UTF-8")可以提前发现非法名称，但注意它不校验是否为 IANA 标准名，只查 JVM 是否注册了该别名
真正难的不是写法，而是确认源头数据到底用的什么编码——没有元信息时，只能靠统计或 BOM 推断，这部分 Java 标准库不提供支持。
