Charset.forName() 因运行时查表且JVM未预置指定字符集（如Alpine镜像缺GBK）而抛UnsupportedEncodingException；应优先用StandardCharsets常量，或先调Charset.isSupported()校验。
Charset.forName() 为什么经常抛 UnsupportedEncodingException
Java 的 Charset.forName() 是运行时查表，不是编译期校验。如果传入一个 JVM 不支持的字符集名（比如 "GBK" 在某些精简 JRE 或 Alpine Linux 的 OpenJDK 镜像里默认不带），就会直接抛 UnsupportedEncodingException——注意，这是 RuntimeException 的子类，但名字带 “Exception”，容易误以为要强制 try-catch。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先用标准常量，比如
StandardCharsets.UTF_8、StandardCharsets.ISO_8859_1，它们在 Java 7+ 全平台稳定可用，零异常风险 - 若必须用字符串名（如从配置读取），改用
Charset.isSupported("GBK")先判断，再调用forName() - Alpine 基础镜像下，OpenJDK 默认不包含
sun.nio.cs.ext包，"GBK"、"GB2312"、"BIG5"都不可用；要么换eclipse-jdk镜像，要么提前加载：-Dfile.encoding=GBK -Dsun.jnu.encoding=GBK不起作用，得靠--add-modules java.base/sun.nio.cs.ext（Java 17+）
new String(byte[], Charset) 和 String.getBytes(Charset) 的编码方向别搞反
中文乱码八成出在这里：把“字节 → 字符串”和“字符串 → 字节”当成对称操作，却忽略了原始字节流的真实编码。比如 HTTP 响应体是 UTF-8 编码的字节，你用 new String(bytes, StandardCharsets.ISO_8859_1) 解，必然满屏问号；反过来，用 UTF-8 调 getBytes() 写进本该是 GBK 的数据库字段，也会存坏。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 永远明确「这串字节是谁编码的」，而不是「我想让它变成什么」。解码时用源头编码，编码时用目标系统要求的编码
- HTTP 场景下，优先从
Content-Typeheader 读charset，而不是硬写UTF_8；没声明时，默认按规范是ISO_8859_1，不是 UTF-8 -
String.getBytes(StandardCharsets.UTF_8)返回的是 UTF-8 字节，但如果你把它喂给一个只认 GBK 的旧系统，对方解出来就是乱码——这不是 Java 的错，是协议没对齐
InputStreamReader/OutputStreamWriter 的 Charset 参数漏传会踩平台默认编码坑
不传 Charset 构造参数时，InputStreamReader 会调用 Charset.defaultCharset()，而这个值取决于 JVM 启动环境：file.encoding 参数、操作系统 locale、甚至容器内 LANG 环境变量。本地测试是 UTF-8，上生产变 GBK，日志全乱。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 所有
InputStreamReader、OutputStreamWriter、Files.newBufferedReader()、Files.newBufferedWriter()必须显式传StandardCharsets.UTF_8或其他确定值，禁止依赖默认 -
Files.readAllLines(path)和Files.write()这类便捷方法也默认用defaultCharset()，务必换成带Charset参数的重载 - Spring Boot 应用里，
spring.http.encoding.charset只管 Web 层，不影响ResourceLoader读取 classpath 下的 properties 文件——那还得单独配ResourceBundle.Control
Properties.load() 读中文键值对为什么还是乱码
Properties.load(InputStream) 规范强制要求使用 ISO-8859-1 解码，哪怕你传的是 UTF-8 字节流。它内部会把每个字节当 Latin-1 处理，遇到 >127 的字节就转成 Unicode 转义（如 \u4f60），但前提是源文件本身得是 Latin-1 编码格式——显然没人这么干。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 不要用
Properties.load(InputStream)直接读 UTF-8 的 .properties 文件；改用Properties.load(Reader)，并确保Reader用 UTF-8 初始化，例如：new InputStreamReader(is, StandardCharsets.UTF_8) - 如果必须用原生 load 方法，就得把中文转成
\uXXXX形式（用native2ascii工具或 IDE 自动转换），否则一定乱码 - Java 9+ 提供了
Properties.load(Stream)（带Charset参数），但要注意它只适用于InputStream，且仍不支持 BOM；UTF-8 with BOM 的文件需先跳过前 3 字节
最麻烦的不是选错 Charset，而是整个调用链里有多个环节各自做了一次隐式编码转换，比如 HTTP client 解一次、Jackson 反序列化又解一次、最后 log 输出再 encode 一次——每层都可能偷偷用 defaultCharset。这种问题没法靠单点修复，得顺着数据流画一张编码流向图。
