中文乱码转换方法的关键，是先找出文字原本使用的字符编码，再用同一种编码正确解码。常见情况是 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 文件也常因编辑器的打开方式不同而出现乱码。导出时明确使用一种编码，导入时选择相同编码；若文件来自不同系统，先确认原文件编码再读入，不要只靠更改扩展名或另存文件名解决。数据库场景则应检查连接编码、字段字符集和应用程序读写编码是否一致。若数据在入库前已被错误解码，单独修改字段设置通常不能让旧记录自动恢复。
转换时的判断顺序
- 保留原始文件或原始字节，避免覆盖后失去恢复依据。
- 确认数据来源及其真实编码，分别检查读取端和写入端。
- 在程序中明确指定编码，先正确解码，再按目标编码输出。
- 只有在误解码方式明确且可逆时，才对现有乱码字符串做反向转换。
- 用包含中文、标点和特殊字符的样本检查结果，确认文件、程序和显示端一致。
归根结底，中文乱码转换不是把一串错字换成另一套编码名称，而是恢复正确的字节解读方式。原始字节仍在时，按真实编码重新解码通常最直接；字符串已经被错误解码时，则需要知道错误发生的具体环节，再判断能否逆向还原。