出现乱码，通常不是文字本身突然损坏，而是写入、传输、读取或显示时使用了不匹配的字符编码。常见原因包括 UTF-8 与 GBK、GB18030 等编码识别错误，文件被重复转换，网页声明与实际编码不一致，数据库连接字符集配置错误，以及系统缺少对应字体。排查时不要一开始就反复转换编码，正确顺序是：先保留原始内容，再确认乱码最早出现的位置，最后只修正发生错误的那一层。

先判断乱码出现在哪个环节

把同一段文字分别与原始文件、导入前数据、程序读取结果和最终显示结果进行比较。只要能找到“正常文字变成乱码”的第一个环节，后续处理通常就比较明确。

现象	优先怀疑原因	排查方向
只有一个文件乱码	文件编码被误判或保存时转换错误	用其他编码重新打开，确认原始字节是否仍在
网页源码正常，浏览器显示乱码	响应头、HTML 声明或模板编码不一致	检查服务器响应和页面编码声明
网页、接口和数据库中的内容都乱码	写入或数据库连接阶段已发生错误	对比提交前数据、接口数据和数据库原值
只有命令行或日志乱码	终端代码页、区域设置或日志读取编码不匹配	检查终端环境和日志文件实际编码
文字变成方框、空白或问号	字体缺失，或字符在转换时被替换	先区分字体显示问题和数据已经丢失的问题

乱码排查的正确顺序

1. 先备份，不要直接覆盖原文件

先复制原文件、数据库备份或原始导出包，再进行尝试。尤其不要在已经乱码的内容上连续执行“转成 UTF-8”“转成 GBK”等操作，因为错误转换可能会把原始字节再次改写，导致后续无法恢复。

如果是网页或程序问题，保存一份原始响应、接口返回值和出现乱码时的输入内容；如果是数据库问题，先导出受影响表或记录。排查的目标是找出错误边界，而不是立刻让某一处看起来正常。

2. 判断原始数据是否仍然完整

如果同一文件用不同编码重新打开后，某一种方式能恢复正常，通常说明原始字节还在，只是编辑器或程序选择了错误编码。常见情况是 UTF-8 文件被按 GBK 打开，或者 GBK 文件被按 UTF-8 读取。

出现“涓枃”“中文”这类字样，往往是 UTF-8 内容被用其他单字节或中文编码错误解释。此时应关闭自动保存，重新以正确编码打开，再使用“另存为”明确指定目标编码。不要根据乱码后的文字再次猜测并反复转换。

3. 文件乱码：先试读取，再做一次转换

处理文本、CSV、TXT、JSON 或日志文件时，先查看编辑器、导入工具或脚本当前采用的编码。优先尝试 UTF-8、GB18030 和原系统常用编码，但每次尝试都应基于备份文件，并观察完整内容，而不是只看一行。

确认正确编码后，再根据使用场景统一保存。新文件一般可采用 UTF-8；需要兼容旧版软件时，应先确认软件支持的编码范围。CSV 文件还要留意分隔符、引号和 BOM，这些问题有时会与中文乱码同时出现，但不能靠更换编码单独解决。

如果所有编码打开后都不正常，或者文字已经变成大量问号，可能是在此前保存、导入或导出时发生了不可逆替换。此时应寻找原始文件、旧版本、备份或上游重新导出数据，而不是继续转换当前文件。

4. 网页乱码：检查“实际响应”而不是只看源码

网页显示乱码时，应按以下顺序确认：服务器返回的响应头、HTML 中的字符集声明、模板文件保存编码，以及页面内容生成程序使用的编码。页面声明为 UTF-8，但服务器实际按其他编码发送，浏览器仍可能错误解析。

页面响应头中的字符集、HTML 的字符集声明和文件实际保存编码应保持一致。动态页面还要检查模板、接口响应和中间层是否分别进行了编码转换。接口返回 JSON 时，也应确认响应头和序列化过程使用同一套约定。

如果查看网页源代码时文字已经乱码，问题通常发生在服务器生成页面、读取模板或读取数据库之前；如果源代码正常而浏览器显示异常，则优先检查响应头和页面声明。修正配置后，需要清理缓存或重新部署，并用浏览器重新加载验证。

5. 数据库乱码：分开检查写入、存储和读取

数据库场景不能只查看字段类型。应分别对比三份内容：写入数据库前的原始文字、数据库中实际保存的值，以及查询接口返回的结果。三者的差异可以判断问题发生在应用提交、数据库连接、字段存储还是查询输出阶段。

常见错误包括客户端连接字符集不正确、导入工具编码选错、表或字段字符集不支持目标字符，以及应用查询后再次错误转换。修复时要先确认数据库中保存的内容是否已经损坏：如果数据库中的值正常，只需修正连接或输出配置；如果数据库中的值已乱码，应从备份或原始数据重新导入。

不要直接对乱码字段批量执行替换或更新。错误编码下的批量修复可能扩大影响，且同一字段中的不同记录未必经历了相同的转换过程。

6. 命令行和日志乱码：确认终端与文件编码

命令行乱码不一定代表程序生成的数据有问题。程序输出的编码、日志文件的保存编码，以及终端当前代码页可能不同。先把同一输出重定向到文件，再用明确编码的编辑器打开；如果文件正常而终端异常，问题多半在终端显示环境。

Windows 命令行可检查当前代码页，部分环境可以切换到 UTF-8 代码页后重新运行；Linux 或 macOS 则应检查语言环境变量和终端字体。需要注意，改变终端显示编码只能解决显示层问题，不能修复已经错误写入文件或数据库的内容。

7. 方框、空白和问号要单独判断

文字显示成方框，常见原因是系统或应用缺少对应字体，特别是少见汉字、特殊符号和表情字符。此时复制文字、查看源码或更换支持该字符的字体，可能仍能得到正常内容。

如果文字变成问号，需确认问号是显示效果，还是数据中实际保存的字符。数据本身已经被替换为问号时，原字符通常无法通过安装字体恢复，只能从原始输入、备份或上游数据重新获取。

修复后如何确认乱码已经恢复

1. 用原始样本测试，不只检查一两个字，至少覆盖中文、数字、标点和特殊字符。
2. 关闭并重新打开文件，重新加载网页或重新建立数据库连接，确认结果不是临时缓存。
3. 检查数据在完整链路中的表现：输入、保存、传输、读取和显示都应保持一致。
4. 确认新产生的数据不再乱码，再处理历史数据；不要让修复前的错误配置继续写入内容。

如果只是读取方式错误，改用与原始数据匹配的编码并重新打开后即可恢复；如果是网页或程序配置错误，修正发生乱码的边界并重新部署即可；如果原始字节已经被错误转换或替换，则不能靠再次选择编码恢复，必须使用备份或重新获取原始内容。按照“保留原始数据—定位首次异常—修正单一环节—重新验证”的顺序处理，通常比盲目转换编码更快，也更不容易造成二次损坏。