打开文档、网页或导出的数据时 ，若是中文造成“????–?”、一串问号、方框或齐全无法辨认的符号 ，文字乱码的原因通常不是文自炀空隐没 ，而是保留、传输、读取和显示过程中使用的字符编码不一致 。排查时不要先反复点击“转换编码”或直接覆盖原文件 ，应先确认乱码呈此刻哪个环节 ，再凭据场景复原 。
先凭据乱码阐发判断问题地点
| 看到的景象 | 更可能的原因 | 优先查抄地位 |
|---|---|---|
| 中文造成“????–?”等奇怪拉丁字符 | UTF-8、GBK或其他编码被谬误读取 | 文件打开方式、网页申明、法式解码设置 |
| 文字造成问号 | 转换时字符无法暗示 ，或内容曾被谬误保留 | 原始文件、导出设置、数据库字段和衔接编码 |
| 文字显示为方框、空缺框或豆腐块 | 当前字体没有对应的中文字形 | 字体、系统说话、利用的字体回退设置 |
| 只有号令杏注终端中的中文异常 | 法式输出编码与终端代码页不一致 | 终端代码页、法式输出选项、剧本编码 |
| 所有软件中的文件名或中文都异常 | 系统区域设置、字体或系统说话环境出现问题 | 操作系统设置和字体装置情况 |
其中 ，乱码字样与方框要分辨处置 。编码谬误会让一个字符被诠释成多个谬误字符；字体缺失则通常阐发为方框 ，即便编码齐全正确 ，系统也无法绘造对应字形 。
只在一个文件或一个利用中乱码：先建改打开方式
若是统一设备上的其他文件正常 ，只有某个文本、CSV、日志或字幕文件出现乱码 ，问题通常集中在文件编码或利用的读取方式 。此时可按以下挨次处置 。
- 先复造原文件 。将原文件另存一份 ，不要直接用乱码内容覆盖原文件 ，也不要在未确认编码前点击保留 。
- 确认文件类型 。纯文本、CSV、日志、字幕和网页源文件能够尝试更换字符编码；DOCX、PDF、图片或数据库文件不应单一地当作TXT打开 ，不然看到的异常字符可能只是文件二进造数据 。
- 使用支持编码选择的编纂器沉新打开 。常见候选蕴含UTF-8、GBK或GB18030；来自特定地域或旧系统的文件 ，也可能使用Big5等编码 。应先预览了局 ，哪一种能让大部门中文、标点和换行都正常 ，就更靠近原始编码 。
- 查抄是否存在编码象征 。部门UTF-8文件带有BOM ，部门旧软件会依赖该象征鉴别编码 。没有BOM不代表文件肯定不是UTF-8 ，但在旧软件之间互换时可能造成误判 。
- 确认显示正常后再另存 。新文件通�Ｄ芄煌骋槐Ａ粑猆TF-8；若是必须兼容只支持旧编码的系统 ，则应按对方系统要求导出 ，并先确认指标软件可能正确打开 。
复原成功的前提是：用正确编码沉新诠释原始字节后 ，中文、标点和特殊符号都能正常显示 。若文件已经用谬误编码打开并保留 ，原始字符可能已经被问号代替 ，这时仅靠再次选择编码通常无法还原 ，应寻找未批改的原文件、备份或沉新导出的数据 。
网页、接口或文件传输后乱码：查抄编码链路是否一致
若是文字在一个法式中正常 ，经过网页展示、接口返回、邮件发送、CSV导入或数据库写入后才乱码 ，排查沉点不是单个显示窗口 ，而是“天生、传输、存储、读取、显示」剽条链路 。只有其中一环的申明和现实编码不一致 ，就可能出现乱码 。
网页显示乱码时
- 先对比页面源数据和浏览器最终显示的内容 。若是源文件自身已经乱码 ，应回到天生页面或模板的法式查抄；若是源文件正常而浏览器异常 ，应查抄响应头、页面字符集申明和现实保留编码 。
- 页面文件、服务器响应和浏览器解析应尽量使用统一种编码 。现代网页通常优先统一为UTF-8 ，不要只批改页面申明而不转换现实文件内容 。
- 若是只有部门页面乱码 ，沉点比力这些页面的模板、接口返回值和数据起源；若所有页面都异常 ，再查抄服务器默认字符集或公共模板 。
接口、JSON或CSV导入乱码时
- JSON通常按UTF-8处置 ，但发送方和接管方仍需确认现实字节与响应申明一致 。不要由于内容体式写着JSON ，就默认所有环节都已经正确解码 。
- CSV时时在分歧办公软件之间出现编码差距 。导入时应明确选择文件编码 ，并确认分隔符、换行符和引号规定；只有中文乱码而列结构正常时 ，优先查编码 ，列错位则还要查抄CSV体式 。
- 数据库场景要同时查抄字段或表的字符集、客户端衔接编码、驱动设置以及导入导出工具的编码 。数据库里存储正常、查问页面乱码 ，通常是衔接或显示层问题；数据库中已经造成问号 ，则必要从原始数据沉新导入 。
这一场景最有效的做法是别离查看每一环的了局：原始文本是否正常 ，传输内容是否正常 ，存储后的内容是否正常 ，客户端解码后是否正常 。不要陆续进行屡次“转码” ，由于沉复转换可能把正本正确的内容再次粉碎 。只有找到初次出现乱码的地位 ，建复才不会反复产生 。
所有软件或文件名都异常：分辨字体问题与系统说话环境
若是不仅一个文件 ，而是多个利用、文件名、菜单或系统界面都出现异常 ，应先观察字符状态 。若是重要是方框、空缺框 ，优先处置字体：装置可能覆盖中文字符的字体 ，在利用当选择相宜的字体 ，或查抄系统是否关关了字体回退 �；蛔痔逯荒芙饩觥懊挥凶中巍钡南允疚侍� ，不能建复真正的编码谬误 。
若是异常集中在旧软件、号令行或老系统天生的文件中 ，可能是系统区域设置与法式所使用的旧编码不一致 �？刹槌低车乃祷昂颓蛏柚谩⒎荱nicode法式的说话环境 ，以及终端使用的代码页 。调整这类设置前应纪录原设置并保留文件备份 ，由于它可能影响旧法式读取文件的方式 。
若终端中只有某条号令的中文输出异常 ，先查看该法式是否支持指定输出编码 ，再让终端与法式使用匹配的编码 。不要把“输入法无法输入中文”和“已经输入的文字显示乱码”混为一谈：前者多与输入法有关 ，后者更常见于字体或编码诠释问题 。
按这个挨次排查 ，预防越建越乱
- 保留原始内容：复造文件、导出数据库备份或保留接口原始响应 ，暂停覆盖保留 。
- 确认影响领域：判断是一个文件、一个利用、一条传输链路 ，还是整个系统 。
- 看乱码状态：区吩戽怪字符、问号、方框和号令行异常 ，它们对应的处置方向分歧 。
- 寻找正常参照：用其他利用打开统一文件 ，或比力发送端与接管端的统一条内容 。
- 查抄现实编码与申明：不要只改“编码名称” ，要确认文件真实保留方式和法式读取方式一致 。
- 建复后再保留或转换：确认文字齐全、标点正常、换行和字段结构没有变动 ，再天生新的指标文件 。
哪些情况不能靠沉新选择编码复原
若是原文件只是被谬误读取 ，沉新用正确编码打开明�Ｄ芄桓丛�；若是内容已经在某次谬误转换中造成问号、缺失字符或被截断 ，原始信息可能已经不在当前文件里 。此时应优先寻找自动备份、汗青版本、发送端原文或数据库备份 。
因而 ，文字乱码的原因判断不能只看“换一个编码后是否暂使佚常” 。真正复原的尺度是：原始中文可能不变显示 ，沉新关关并打开后依然正常 ，在指标软件或接管环境中也没有再次变形 。找到初次出现乱码的环节 ，并让该环节与高低游选取一致的字符编码 ，才是持久有效的解决法子 。
Android版
iPhone版