中文乱码转换方法的关键，是先找出文字原本使用的字符编码，再用同一种编码正确解码。常见情况是 UTF-8 字节被误当成 GBK、GBK 字节被当成 UTF-8，或者程序先用错误编码读入，之后又把乱码保存下来。仅把乱码文字再次转换成另一种编码，通常不能恢复原文；如果原始字节还在，或错误解码过程可逆，才有机会还原。

先分清乱码发生在哪一步

文字从文件、网页或数据库传到程序时，通常经历“字节—字符—字节”的过程。编码负责把字符写成字节，解码负责把字节还原为字符。两端约定不一致时，就可能出现“中文”这类乱码，原文“中文”对应的字节被按其他规则解释后，显示出的便不再是中文。

• 打开文件就乱码：检查文件实际编码，读取时明确指定编码。
• 网页显示乱码：检查响应头与网页声明的字符集，并确认服务端实际输出的字节编码。
• 程序变量已经乱码：查明字符串是如何产生的；如果源字节已丢失，随意转换编码通常无法复原。
• 保存后再次打开乱码：检查写文件时的编码，以及打开文件的软件采用的解码方式。

可以先用同一段原始数据分别按 UTF-8、GBK 等常见编码读取，观察哪种结果符合预期。确定编码后，后续读取、处理和写出都明确指定字符集，不要依赖系统默认值。这里的重点不是反复尝试转换，而是让每一次字节与字符之间的转换都有清楚的编码依据。

Python：按已知编码读取或恢复

如果拿到的是 UTF-8 文件，直接在读取时指定编码：

with open("data.txt", "r", encoding="utf-8") as file:
    text = file.read()

print(text)

如果数据来自原始字节，也可以明确解码。下面的字节序列是“中文”的 UTF-8 编码：

raw = bytes()
text = raw.decode("utf-8")
print(text)  # 中文

若同一批 UTF-8 字节曾被错误地按 Latin-1 解码，且中间没有经过其他修改，可以按相反步骤尝试恢复：

wrong = raw.decode("latin-1")
fixed = wrong.encode("latin-1").decode("utf-8")
print(fixed)  # 中文

这类修复只适用于错误解码过程确实是 Latin-1，且字符串仍保留了对应字节信息的情况。若乱码经过替换字符处理、截断或人工编辑，原始字节可能已无法从当前字符串中还原。读写时都应指定编码，例如写成 UTF-8：open("out.txt", "w", encoding="utf-8")。

Java：构造字符串时指定字符集

Java 处理中文时，应避免使用依赖系统默认字符集的构造方式。手中有字节数组时，直接指定其真实编码：

import java.nio.charset.StandardCharsets;

byte[] bytes = new byte[] {
    (byte) 0xE4, (byte) 0xB8, (byte) 0xAD,
    (byte) 0xE6, (byte) 0x96, (byte) 0x87
};

String text = new String(bytes, StandardCharsets.UTF_8);
System.out.println(text); // 中文

如果字符串是 UTF-8 字节被错误地按 ISO-8859-1 解码所得，并且该过程可逆，可将字符串先按错误字符集还原为字节，再按 UTF-8 解码：

String fixed = new String(
    wrong.getBytes(StandardCharsets.ISO_8859_1),
    StandardCharsets.UTF_8
);

这段处理不能用于所有乱码。实际程序中更稳妥的做法是在读取文件、请求数据或数据库结果时就统一字符集，避免先生成错误字符串，再尝试补救。

JavaScript：正确解码字节数据

在浏览器或支持 TextDecoder 的环境中，可以指定字节数据的编码。下面将 UTF-8 字节解码为中文：

const bytes = new Uint8Array([
  0xE4, 0xB8, 0xAD,
  0xE6, 0x96, 0x87
]);

const text = new TextDecoder("utf-8").decode(bytes);
console.log(text); // 中文

如果数据是 GBK 编码，应按数据的实际来源选择相应解码方式；把已有字符串交给 UTF-8 解码器并不会自动修复它，因为字符串已经不是原始字节。接口返回数据时，还要保证服务端输出的字符集与客户端解码方式一致。

网页、CSV 与数据库中的处理重点

网页乱码通常要同时检查响应字节和声明信息。服务端按 UTF-8 输出时，响应头应与其一致；HTML 文档也应声明相同字符集。若响应头标为 GBK、实际内容却是 UTF-8，浏览器可能按错误方式显示。修改声明只能解决解码规则不一致的问题，不能修复已经写坏的文字。

CSV 文件也常因编辑器的打开方式不同而出现乱码。导出时明确使用一种编码，导入时选择相同编码；若文件来自不同系统，先确认原文件编码再读入，不要只靠更改扩展名或另存文件名解决。数据库场景则应检查连接编码、字段字符集和应用程序读写编码是否一致。若数据在入库前已被错误解码，单独修改字段设置通常不能让旧记录自动恢复。

转换时的判断顺序

1. 保留原始文件或原始字节，避免覆盖后失去恢复依据。
2. 确认数据来源及其真实编码，分别检查读取端和写入端。
3. 在程序中明确指定编码，先正确解码，再按目标编码输出。
4. 只有在误解码方式明确且可逆时，才对现有乱码字符串做反向转换。
5. 用包含中文、标点和特殊字符的样本检查结果，确认文件、程序和显示端一致。

归根结底，中文乱码转换不是把一串错字换成另一套编码名称，而是恢复正确的字节解读方式。原始字节仍在时，按真实编码重新解码通常最直接；字符串已经被错误解码时，则需要知道错误发生的具体环节，再判断能否逆向还原。