Java处理编码转换非法字符的关键是控制解码行为而非简单替换，应通过CharsetDecoder显式配置onMalformedInput、onUnmappableCharacter及replaceWith来实现可控fallback处理。
Java 中处理编码转换时遇到非法字符，通常是因为源字节序列不符合目标字符集的编码规则（比如用 UTF-8 解码一段实际是 GBK 编码的字节数组）。这类问题不会直接抛出异常（取决于解码器配置），但可能导致乱码、截断，或在严格模式下抛出 CharacterCodingException。关键不是“替换非法字符”，而是**控制解码行为，让非法字节有可控的 fallback 处理方式**。
使用 CharsetDecoder 设置替换策略
最标准、推荐的方式是通过 CharsetDecoder 显式配置替换逻辑：
- 调用
charset.newDecoder()获取解码器 - 用
.onMalformedInput(CodingErrorAction.REPLACE)和.onUnmappableCharacter(CodingErrorAction.REPLACE)启用替换 - 用
.replaceWith("")指定替换字符串（默认就是 ）
示例：把可能含非法 UTF-8 字节的 byte[] 安全转为 String
byte[] bytes = { (byte)0xFF, (byte)0xFE, 0x41, 0x42 }; // 前两字节不是合法 UTF-8
CharsetDecoder decoder = StandardCharsets.UTF_8.newDecoder()
.onMalformedInput(CodingErrorAction.REPLACE)
.onUnmappableCharacter(CodingErrorAction.REPLACE)
.replaceWith("\uFFFD"); // Unicode 替换字符
String result = decoder.decode(ByteBuffer.wrap(bytes)).toString();
// result == "AB"
用 String 构造函数 + 自定义 fallback（简单场景）
如果只是临时处理、不追求高性能，可先用 new String(bytes, charset) 尝试解码；捕获 UnsupportedEncodingException（极少发生）或更常见的是底层解码失败导致的乱码。但注意：这个构造函数本身不抛异常，也不会自动替换 —— 它依赖 JVM 默认的解码器策略（通常是 REPLACE）。所以更稳妥的做法仍是显式用 CharsetDecoder。
立即学习“Java免费学习笔记（深入）”；
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
若想完全自定义替换逻辑（比如把每个非法字节替换成 "[?]"），需手动遍历字节数组 + 分段解码，或借助第三方库（如 Apache Commons Codec 的 StringUtils 配合 Charset 检测）。
避免源头问题：明确字节来源和预期编码
很多“非法字符”其实源于误判编码。例如：
- 从文件读取时没指定正确 charset（如文件是 GB2312，却用 UTF-8 读）
- HTTP 响应头声明 charset 与实际内容不符
- 数据库连接 URL 或字段 collation 设置与 Java 端不一致
解决思路优先是校准编码约定，而不是事后替换。可用 Charset.isSupported("GBK") 检查支持性，用 java.nio.charset.Charset.availableCharsets() 查看当前环境支持的编码列表。
补充：处理已存在的乱码字符串（非字节层）
如果乱码已经变成 String 对象（比如显示为 ""），说明解码已完成且不可逆。此时无法还原原始字节，只能做文本级清洗，例如：
- 用正则替换连续的 Unicode 替换符：
str.replaceAll("\uFFFD+", "?") - 对已知编码混淆场景（如 UTF-8 字节被当 ISO-8859-1 解码），尝试“再编码再解码”纠偏（风险高，需谨慎验证）
这类操作属于补救，不应作为常规方案。
