UnsupportedCharsetException 是 JVM 运行时因未注册指定字符集（如 Alpine JRE 缺失 GBK）而抛出的异常；需用 Charset.isSupported() 或 availableCharsets() 验证支持性，避免拼写误判。
UnsupportedCharsetException 是什么错误
这是 Java 在尝试使用一个 JVM 根本不认的字符集名时抛出的运行时异常，比如传了 "GBK" 却在某些精简版 JRE（如 Alpine Linux 上的 OpenJDK 无 GUI 版）里没加载对应 charset provider。
它不是编码写错了（比如把 "UTF-8" 写成 "UTF8"），而是 JVM 启动时压根没注册那个字符集——连 Charset.isSupported("GBK") 都返回 false。
怎么判断是不是真不支持，而不是拼写错误
别急着改代码，先用最简单的验证逻辑确认问题根源：
- 用
Charset.availableCharsets()打印所有可用 charset 名，看你要用的是否在列表里（注意大小写和连字符：比如"UTF-8"有，"utf8"就没有） - 调用
Charset.isSupported("你的字符集名")，返回false就是真不支持 - 常见“看似合法但实际不支持”的名字：
"GB2312"（部分 JDK 8+ 支持）、"Big5"（某些嵌入式 JRE 剔除了）、"EUC-KR"（Alpine 默认镜像常缺失）
为什么有些环境支持、有些不支持
Java 的 charset 实现靠 sun.nio.cs 包下的 provider 类，而这些类是否被加载，取决于 JVM 启动时的 java.nio.charset.spi.CharsetProvider 服务发现机制——它会扫描 META-INF/services/ 下的配置文件。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
影响因素很实在：
- 基础镜像：Alpine Linux + OpenJDK 官方镜像默认用
musllibc，且裁剪了非核心 charset（如 GBK、Big5），除非显式安装openjdk-jre-headless的完整包或换用debian:slim - JDK 版本：JDK 17+ 的某些精简 profile（如
java.baseonly）可能不包含sun.nio.cs.ext模块 - 打包方式：用
jlink构建自定义运行时镜像时，如果没显式加--add-modules java.naming或相关 charset 模块，GBK 等扩展 charset 就不会进去
遇到 UnsupportedCharsetException 怎么处理
不能只 catch 住然后随便 fallback，得按场景选策略：
- 如果是用户输入的字符集名（比如 HTTP
Content-Type头里的charset=xxx），必须先Charset.isSupported(input)校验，不支持就拒绝或返回 400，别硬转 - 如果是自己代码里写的固定值（比如
new String(bytes, "GBK")），优先换成标准 charset："UTF-8"或"ISO-8859-1"；若业务强依赖 GBK，就得确保部署环境装了完整 JDK（比如 Dockerfile 里用openjdk:17-jre-slim而不是openjdk:17-jre-alpine） - 极少数必须动态加载 charset 的场景（如插件系统），可以用
ServiceLoader.load(CharsetProvider.class)手动触发 provider 发现，但要注意类加载器隔离问题——不是所有 provider 都能被当前 CL 加载到
真正麻烦的是跨平台分发：Windows 开发时用 "GBK" 没问题，一上 Linux 容器就崩，这种隐性依赖最容易漏测。
