Java中ISO-8859-1导致中文乱码可恢复，前提是UTF-8字节被错误用ISO-8859-1解码且未修改字符串；典型表现为显示为ä¸æ–‡、长度不变、无?符号；恢复写法为String restored = new String(wrongStr.getBytes("ISO-8859-1"), "UTF-8")。
Java 中处理 ISO-8859-1 编码导致的中文乱码，核心在于“还原原始字节再正确解码”，而不是强行替换或猜测字符。乱码通常不是数据损坏，而是 UTF-8 字节被错误地用 ISO-8859-1 解码了一次——只要没做截断、replace 或其他字符串修改，就能原样恢复。
确认乱码是否属于 ISO-8859-1 误解 UTF-8
这是最关键的一步。典型表现是：
- 原始中文（如“中文”）显示为类似 ä¸æ–‡ 这样的拉丁字符组合；
- 字符串长度与原始中文字符数一致（UTF-8 中文占 3 字节/字，ISO-8859-1 解码后变成 3 个 Latin-1 字符，长度不变）；
- 没有出现 ? 或 （那是编码不支持时的替换符，说明已发生不可逆丢失）。
满足以上条件，基本可判定是 ISO-8859-1 错解 UTF-8，适用标准恢复流程。
标准恢复写法（一行代码）
对已拿到的乱码字符串 wrongStr，执行：
String restored = new String(wrongStr.getBytes("ISO-8859-1"), "UTF-8");
原理分两步：
-
wrongStr.getBytes("ISO-8859-1")：利用 ISO-8859-1 的字节透明性，把每个字符的 Unicode 码点值（U+00E4、U+00B8…）直接转回原始字节（0xE4、0xB8…），还原出当初的 UTF-8 字节流； -
new String(..., "UTF-8")：用 UTF-8 正确解码这些字节，得到原始中文字符串。
常见错误场景及规避方式
以下操作会让恢复失效，需提前避免：
- 对乱码字符串调用
trim()、substring()、replace()等方法——会破坏字节与字符的一一对应关系； - 先用
getBytes("GBK")或getBytes("UTF-16")转换过——字节已变，无法还原； - 原始输入流本身不是合法 UTF-8（比如实际是 GBK 编码却被当 UTF-8 处理），此时该方法不适用；
- 网络传输中发生丢包、文件被截断——字节不完整，恢复结果可能部分错乱。
从源头预防比事后恢复更可靠
真正稳定的方案，是在读取阶段就指定正确编码：
- 读文件时：
new InputStreamReader(new FileInputStream(file), StandardCharsets.UTF_8)； - 读 HTTP 请求体（POST）：
request.setCharacterEncoding("UTF-8")（在获取参数前调用）； - 处理 Servlet 输入流：
new InputStreamReader(inputStream, StandardCharsets.ISO_8859_1)—— 如果源确实是 ISO-8859-1，就该用它解码，而非默认编码； - JDBC 连接串加上
?characterEncoding=utf-8，确保数据库通信统一。
不复杂但容易忽略。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
