Java处理乱码的核心是明确原始字节的真实编码和目标文本的预期编码，再用正确Charset解码；乱码本质是解码时用了错误字符集，字节未损坏，只需用真实编码重新解码即可。

Java 中处理乱码字节流的核心，是明确原始字节的**真实编码**和目标文本的**预期编码**，再用正确的字符集重新解码。乱码本身不是数据损坏，而是“用错钥匙开了锁”——字节没丢，只是当初解码时用了错误的 Charset。

先确认原始字节的真实编码

这是最关键的一步。不能靠猜，得结合来源判断：

• HTTP 响应中看 Content-Type 头（如 text/html; charset=gbk）
• 文件读取前查文档或 BOM（如 UTF-8-BOM 开头是 EF BB BF，GBK 没有 BOM）
• 数据库连接 URL 或表结构里指定的字符集（如 MySQL 的 useUnicode=true&characterEncoding=gb2312）
• 若完全未知，可用工具（如 juniversalchardet 库）做概率检测，但结果仅供参考

用正确编码把字节转成 String

拿到字节数组（byte[]）后，用它原本的编码构造字符串：

byte[] rawBytes = ...; // 你的乱码字节流
// 假设真实编码是 GBK，但之前被误当成 ISO-8859-1 解码过（常见于表单提交）
String decodedByMistake = new String(rawBytes, StandardCharsets.ISO_8859_1); // 错误解码 → 得到“伪字符串”
// 把这个伪字符串按原编码（GBK）再转回字节，再用 UTF-8 正确解码
byte[] gbkBytes = decodedByMistake.getBytes(StandardCharsets.GBK);
String correctText = new String(gbkBytes, StandardCharsets.UTF_8);

更直接的方式（推荐）：跳过中间 String，直接用原始字节 + 真实编码构建正确字符串：

Gradle 9.8.0

下载

立即学习“Java免费学习笔记（深入）”；

byte[] rawBytes = ...;
String correctText = new String(rawBytes, "GBK"); // 直接用真实编码解码

常见乱码场景与修复示例

场景1：UTF-8 字节被当成 ISO-8859-1 解码
原始字节 [0xE4, 0xB8, 0xAD]（UTF-8 的“中”）→ 错用 ISO-8859-1 解成字符串 “中” → 再把“中”按 ISO-8859-1 编码回字节 → 得到 [0xE4, 0xB8, 0xAD] → 用 UTF-8 解码即正确。

String wrongStr = "中"; // 乱码字符串
byte[] fixBytes = wrongStr.getBytes(StandardCharsets.ISO_8859_1);
String fixed = new String(fixBytes, StandardCharsets.UTF_8); // → "中"

场景2：GBK 字节被当成 UTF-8 解码（出现 ）
此时会抛 MalformedInputException 或产生替换字符。需改用 GBK 解码原始字节，而非修复已损坏的字符串。

预防胜于修复

从源头避免乱码最有效：

• 读文件时显式指定 Charset：Files.readString(path, StandardCharsets.UTF_8)
• 网络请求设置 Accept-Charset 和解析响应时读取 Content-Type
• 数据库连接、JDBC URL、ORM 配置统一字符集（如 UTF-8）
• IDE 和项目编码设为 UTF-8（File Encoding in IntelliJ / Eclipse）

不复杂但容易忽略。