乱码可恢复，因其本质是utf-8字节被iso-8859-1错误解码为unicode码点与原字节值一一对应的伪字符串，再用iso-8859-1编码还原字节、utf-8解码即可复原。
Java 中 ISO-8859-1 转 UTF-8 出现乱码，本质不是数据损坏，而是字节被错误解码了一次。只要原始字节没丢、没改，大多数情况都能原样恢复——关键在搞清“错在哪一步”，然后在正确环节操作。
确认是不是典型的 ISO-8859-1 误解 UTF-8 场景
这是可逆恢复的前提。典型表现是：字符串看起来像“且“é”这类拉丁字符组合，但复制粘贴后仍能识别出原始中文或符号的轮廓。它往往发生在：
- Tomcat 接收 GET 请求参数时，默认用 ISO-8859-1 解码 UTF-8 字节（如浏览器发来“中”的 UTF-8 字节
0xE4 0xB8 0xAD，被当成三个 Latin-1 字符ä¸） - 读取本为 UTF-8 的文件或响应体，却用
InputStreamReader无参构造（依赖平台默认编码），而实际源是 ISO-8859-1 编码的流 - 数据库字段存的是 UTF-8 字节，但 JDBC 连接未设
characterEncoding=utf-8，驱动误用 ISO-8859-1 解析
已得乱码字符串，直接还原（仅限误解场景）
如果你手头已经是那个“看着像乱码”的 String wrongStr（比如 "ä¸"），且确定它是 UTF-8 字节被 ISO-8859-1 错解而来，一行代码即可复原：
String restored = new String(wrongStr.getBytes("ISO-8859-1"), "UTF-8");
原理很清晰：
-
wrongStr.getBytes("ISO-8859-1")把每个字符（如ä→ U+00E4）按 Latin-1 规则“压回”字节（U+00E4 →0xE4），恰好还原原始 UTF-8 字节流 -
new String(..., "UTF-8")再用 UTF-8 正确解码这些字节，得到原本的中文
⚠️ 注意：这个方法对中间做过 substring、replace、trim 或转过其他编码的字符串无效。
从源头避免乱码（推荐做法）
修复是补救，预防才省心。核心原则：**解码动作必须与原始字节的真实编码严格匹配**。
- 读文件或网络流时，
InputStreamReader一定要显式传入真实源编码：new InputStreamReader(inputStream, StandardCharsets.ISO_8859_1)或new InputStreamReader(inputStream, "UTF-8") - 处理 HTTP 请求时，GET 参数在 Tomcat 下需手动反转：
String param = request.getParameter("name");<br>param = new String(param.getBytes("ISO-8859-1"), "UTF-8");
POST 则优先调用request.setCharacterEncoding("UTF-8")（放在getParameter()前） - JDBC 连接字符串加上
?useUnicode=true&characterEncoding=UTF-8，确保驱动按 UTF-8 解析结果集
无法确定源编码时怎么办
如果不确定输入到底是 ISO-8859-1、GBK 还是 UTF-8，硬编码会翻车。此时应：
- 查协议头：HTTP 的
Content-Type、HTML 的<meta charset>、XML 的encoding属性 - 看文件 BOM：UTF-8（EF BB BF）、UTF-16（FE FF 或 FF FE）可据此自动识别
- 用检测库：如
juniversalchardet或 Apache Tika 做启发式探测，不依赖猜测
别拿 new String(bytes, guessedCharset) 反复试——错一次，字符串就永久失真了。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
