打开文档、网页或导出的数据时，如果中文变成“–?”、一串问号、方框或完全无法辨认的符号，文字乱码的原因通常不是文字凭空消失，而是保存、传输、读取和显示过程中使用的字符编码不一致。排查时不要先反复点击“转换编码”或直接覆盖原文件，应先确认乱码出现在哪个环节，再根据场景恢复。
先根据乱码表现判断问题所在
| 看到的现象 | 更可能的原因 | 优先检查位置 |
|---|---|---|
| 中文变成“–?”等奇怪拉丁字符 | UTF-8、GBK或其他编码被错误读取 | 文件打开方式、网页声明、程序解码设置 |
| 文字变成问号 | 转换时字符无法表示，或内容曾被错误保存 | 原始文件、导出设置、数据库字段和连接编码 |
| 文字显示为方框、空白框或豆腐块 | 当前字体没有对应的中文字形 | 字体、系统语言、应用的字体回退设置 |
| 只有命令行、终端中的中文异常 | 程序输出编码与终端代码页不一致 | 终端代码页、程序输出选项、脚本编码 |
| 所有软件中的文件名或中文都异常 | 系统区域设置、字体或系统语言环境出现问题 | 操作系统设置和字体安装情况 |
其中，乱码字样与方框要区分处理。编码错误会让一个字符被解释成多个错误字符；字体缺失则通常表现为方框，即使编码完全正确，系统也无法绘制对应字形。
只在一个文件或一个应用中乱码：先修正打开方式
如果同一设备上的其他文件正常，只有某个文本、CSV、日志或字幕文件出现乱码，问题通常集中在文件编码或应用的读取方式。此时可按以下顺序处理。
- 先复制原文件。将原文件另存一份，不要直接用乱码内容覆盖原文件，也不要在未确认编码前点击保存。
- 确认文件类型。纯文本、CSV、日志、字幕和网页源文件可以尝试更换字符编码；DOCX、PDF、图片或数据库文件不应简单地当作TXT打开，否则看到的异常字符可能只是文件二进制数据。
- 使用支持编码选择的编辑器重新打开。常见候选包括UTF-8、GBK或GB18030；来自特定地区或旧系统的文件，也可能使用Big5等编码。应先预览结果，哪一种能让大部分中文、标点和换行都正常，就更接近原始编码。
- 检查是否存在编码标记。部分UTF-8文件带有BOM，部分旧软件会依赖该标记识别编码。没有BOM不代表文件一定不是UTF-8，但在旧软件之间交换时可能造成误判。
- 确认显示正常后再另存。新文件通常可以统一保存为UTF-8；如果必须兼容只支持旧编码的系统，则应按对方系统要求导出，并先确认目标软件能够正确打开。
恢复成功的条件是：用正确编码重新解释原始字节后，中文、标点和特殊符号都能正常显示。若文件已经用错误编码打开并保存，原始字符可能已经被问号替代，这时仅靠再次选择编码通常无法还原，应寻找未修改的原文件、备份或重新导出的数据。
网页、接口或文件传输后乱码：检查编码链路是否一致
如果文字在一个程序中正常，经过网页展示、接口返回、邮件发送、CSV导入或数据库写入后才乱码，排查重点不是单个显示窗口，而是“生成、传输、存储、读取、显示”这条链路。只要其中一环的声明和实际编码不一致，就可能出现乱码。
网页显示乱码时
- 先对比页面源数据和浏览器最终显示的内容。如果源文件本身已经乱码，应回到生成页面或模板的程序检查；如果源文件正常而浏览器异常，应检查响应头、页面字符集声明和实际保存编码。
- 页面文件、服务器响应和浏览器解析应尽量使用同一种编码。现代网页通常优先统一为UTF-8，不要只修改页面声明而不转换实际文件内容。
- 如果只有部分页面乱码，重点比较这些页面的模板、接口返回值和数据来源；若所有页面都异常，再检查服务器默认字符集或公共模板。
接口、JSON或CSV导入乱码时
- JSON通常按UTF-8处理，但发送方和接收方仍需确认实际字节与响应声明一致。不要因为内容格式写着JSON，就默认所有环节都已经正确解码。
- CSV经常在不同办公软件之间出现编码差异。导入时应明确选择文件编码，并确认分隔符、换行符和引号规则；只有中文乱码而列结构正常时，优先查编码，列错位则还要检查CSV格式。
- 数据库场景要同时检查字段或表的字符集、客户端连接编码、驱动设置以及导入导出工具的编码。数据库里存储正常、查询页面乱码，通常是连接或显示层问题；数据库中已经变成问号，则需要从原始数据重新导入。
这一场景最有效的做法是分别查看每一环的结果：原始文本是否正常，传输内容是否正常，存储后的内容是否正常，客户端解码后是否正常。不要连续进行多次“转码”，因为重复转换可能把本来正确的内容再次破坏。只有找到首次出现乱码的位置，修复才不会反复发生。
所有软件或文件名都异常：区分字体问题与系统语言环境
如果不仅一个文件，而是多个应用、文件名、菜单或系统界面都出现异常，应先观察字符形态。如果主要是方框、空白框，优先处理字体：安装能够覆盖中文字符的字体，在应用中选择合适的字体，或检查系统是否关闭了字体回退。换字体只能解决“没有字形”的显示问题，不能修复真正的编码错误。
如果异常集中在旧软件、命令行或老系统生成的文件中，可能是系统区域设置与程序所使用的旧编码不一致。可检查系统的语言和区域设置、非Unicode程序的语言环境，以及终端使用的代码页。调整这类设置前应记录原设置并保留文件备份，因为它可能影响旧程序读取文件的方式。
若终端中只有某条命令的中文输出异常，先查看该程序是否支持指定输出编码，再让终端与程序使用匹配的编码。不要把“输入法无法输入中文”和“已经输入的文字显示乱码”混为一谈：前者多与输入法有关，后者更常见于字体或编码解释问题。
按这个顺序排查，避免越修越乱
- 保留原始内容：复制文件、导出数据库备份或保存接口原始响应，暂停覆盖保存。
- 确认影响范围：判断是一个文件、一个应用、一条传输链路，还是整个系统。
- 看乱码形态：区分奇怪字符、问号、方框和命令行异常，它们对应的处理方向不同。
- 寻找正常参照：用其他应用打开同一文件，或比较发送端与接收端的同一条内容。
- 检查实际编码与声明：不要只改“编码名称”，要确认文件真实保存方式和程序读取方式一致。
- 修复后再保存或转换：确认文字完整、标点正常、换行和字段结构没有变化，再生成新的目标文件。
哪些情况不能靠重新选择编码恢复
如果原文件只是被错误读取，重新用正确编码打开通常可以恢复；如果内容已经在某次错误转换中变成问号、缺失字符或被截断，原始信息可能已经不在当前文件里。此时应优先寻找自动备份、历史版本、发送端原文或数据库备份。
因此，文字乱码的原因判断不能只看“换一个编码后是否暂时正常”。真正恢复的标准是：原始中文能够稳定显示，重新关闭并打开后仍然正常，在目标软件或接收环境中也没有再次变形。找到首次出现乱码的环节，并让该环节与上下游采用一致的字符编码，才是长期有效的解决办法。
