Java 原生不支持 ISO-2022-CN 的编码（仅支持解码），直接使用 getBytes("ISO-2022-CN") 会抛出 UnsupportedOperationException；本文提供安全、可落地的字符串级转换方案，兼顾兼容性与实用性。
java 原生不支持 iso-2022-cn 的编码（仅支持解码），直接使用 `getbytes("iso-2022-cn")` 会抛出 `unsupportedoperationexception`；本文提供安全、可落地的字符串级转换方案，兼顾兼容性与实用性。
ISO-2022-CN 是一种基于 ESC 序列切换字符集的中文编码标准，常用于早期电子邮件和新闻组传输。其核心机制依赖控制字符（如 0x1B、0x0E、0x0F）动态切换 G0/G1 字符集，而 Java 标准库中的 ISO-2022-CN Charset 实现仅提供解码器（Decoder），不提供编码器（Encoder）——这正是 new String(...).getBytes("ISO-2022-CN") 报 UnsupportedOperationException 的根本原因。
值得注意的是：你提供的 NIO 手动编解码示例逻辑存在本质缺陷——它错误地假设输入字符串 iso2022cn = "Text" 已是 ISO-2022-CN 编码的字节序列，但实际上传入的是 Java 内部的 UTF-16 字符串。"Text".getBytes("ISO-2022-CN") 在运行时就会失败，导致整个流程无法启动。
✅ 正确前提：你持有的原始数据应为 ISO-2022-CN 编码的 byte[] 字节数组（例如从文件、网络流或数据库中读取），而非一个已解码的 String。若源头确实是字节数组，则标准解码方式简洁可靠：
// ✅ 推荐：从原始字节数组安全解码为 UTF-8 字符串
byte[] iso2022cnBytes = ...; // 来自文件/Socket等
String utf8String = new String(iso2022cnBytes, Charset.forName("ISO-2022-CN"));
// utf8String 即为 UTF-8 编码的 Java 字符串（内部为 UTF-16，但语义等价）⚠️ 但若你确实只能拿到一个已被错误解析为 String 的 ISO-2022-CN 文本（即发生过乱码，当前 String 内容是“伪 UTF-16”表示的 ISO-2022-CN 字节流），则需按字节逻辑修复。此时提供的 iso2022cn2utf8 方法是一种轻量级、面向特定场景的修复函数，其原理是模拟 ISO-2022-CN 的转义状态机：
立即学习“Java免费学习笔记（深入）”；
- 0x1B（ESC）后跟随 $( @ 或 $) A 等序列，用于切换汉字集（本方法跳过3字节，简化处理）；
- 0x0E（SO）启用 G1 区（通常为 GB2312 高位字节），后续字节需高位置 1；
- 0x0F（SI）返回 G0 区（ASCII）；
- 其他字符按状态决定是否 | 0x80（还原 GB2312 的高字节）。
public static String iso2022cn2utf8(String corruptedStr) {
StringBuilder result = new StringBuilder();
boolean inG1Mode = false;
for (int i = 0; i < corruptedStr.length(); i++) {
char c = corruptedStr.charAt(i);
int code = c & 0xFF; // 强制截取低8位，模拟原始字节
switch (code) {
case 0x1B: // ESC — 跳过后续2字节（如 "$(@"）
if (i + 2 < corruptedStr.length()) i += 2;
break;
case 0x0E: // SO → 进入 G1 模式（双字节汉字区）
inG1Mode = true;
break;
case 0x0F: // SI → 返回 G0 模式（单字节 ASCII）
inG1Mode = false;
break;
default:
if (inG1Mode && code < 0x80) {
// G1 区字节需补高位：GB2312 中 0x21–0x7E 映射为 0xA1–0xFE
result.append((char) (code | 0x80));
} else {
result.append(c);
}
break;
}
}
return result.toString();
}? 重要提醒：
- 该方法属于「乱码抢救」手段，不应替代标准字节解码流程；
- 它未处理全部 ISO-2022-CN 切换序列（如 ESC $ ) A 表示 CNS 11643），仅覆盖常见 GB2312 子集；
- 生产环境务必优先确保输入为原始 byte[]，并使用 new String(bytes, "ISO-2022-CN") 解码；
- 如需完整、健壮的支持，建议集成 ICU4J 库，其 CharsetProvider 提供全功能 ISO-2022 系列编解码器。
总结：Java 中 ISO-2022-CN → UTF-8 的正确路径是 byte[] → String（通过 ISO-2022-CN 解码）→（自动视为 UTF-8 语义）；所有绕过字节数组直接操作 String 的方案，都是对数据损坏的妥协修复。
