遇到乱码时 ，先不要反复切换字体或直接覆盖保留原文件。乱码通常来自三类问题：文本被用谬误的字符编码解析、系统短缺对应字体 ，或数据在传输和保留过程中已经败坏。正确的处置挨次是先判断乱码影响领域 ，再确认原始文件和数据是否齐全 ，随后针对编码、字体、软件设置或文件起源逐项建复。只有原始内容没有被覆盖粉碎 ，绝大无数乱码都能够复原。
乱码先从哪里查 ，怎么判断是哪一类问题 ？
第一步是观察乱码的阐发 ，而不是立即选择某个编码。分歧景象对应的排查方向并不一样。
| 阐发 | 优先疑惑的问题 | 先做什么 |
|---|---|---|
| 文字造成“?¤????”“??—”等混合符号 | UTF-8、GBK 等编码被谬误会析 | 换用原文件可能使用的编码沉新打开 |
| 文字显示成方框、问号或空缺 | 字体缺失、字符不支持 ，或内容已被代替 | 更换支持该文字的字体 ，并查抄原始数据 |
| 只有某个软件中乱码 ，其他软件正常 | 软件导入设置、默认编码或说话环境不一致 | 查抄该软件的打开、导入或字符集选项 |
| 整个网页、文件或数据库都出现异常 | 页面申明、文件编码、衔接编码或传输环节不一致 | 沿数据起源逐段查抄编码是否一致 |
| 统一文件每次打开的乱码内容分歧 | 文件败坏、读取方式谬误或法式存在兼容问题 | 终场覆盖保留 ，改用副本和其他工具测试 |
若是乱码只呈此刻少数字符 ，例如表情、少数民族文字或特殊符号 ，优先查抄字体和字符支持；若是汉字整体造成有法规的拉丁字母、符号组合 ，优先查抄编码。若原文已经大量造成问号 ，问号可能已经代替了原字符 ，仅靠换编码通常无法找回。
确认是编码问题后 ，应该按什么挨次复原 ？
- 保留原始文件。先复造一份副本再操作 ，不要在唯一文件上反复“另存为”。若是是压缩包、导出文件或数据库数据 ，优先保留原始起源和最近一次正常备份。
- 确认文件起源。判断内容来自网页、文本编纂器、表格、压缩包、终端、数据库还是其他系统。起源往往能缩幼编码领域。例如中文旧系统常见 GBK 或其他本地编码 ，跨平台导出的文本更常见 UTF-8 ，但不能仅凭文件扩大名确定编码。
- 使用能选择编码的工具沉新打开。在打开或导入界面寻找“字符编码”“文本编码”“编码体式”等选项 ，顺次尝试 UTF-8、GBK、GB18030、UTF-16 蹬纂起源相符的编码。每次切换后 ，应观察齐全句子、标点和数字是否同时复原 ，而不是只看个别汉字。
- 确认后再转换保留。当内容已经正常显示时 ，再将文件统一转换为当前环境通用的 UTF-8 ，或按接管方要求保留。转换前应查抄文件开头、结尾、特殊符号和多说话内容 ，预防只复原了部门文字。
- 查抄传输过程。若是文件在上传、下载、接口导入或复造粘贴后才乱码 ，必要比力源文件与指标文件。源文件正常而指标文件异常 ，问题通常在导出参数、接口申明、法式读取方式或中央转码环节。
判断复原成功的前提不是“看起来像中文” ，而是原文的句子、标点、换杏注数字和特殊字符都能与起源一致。若只改编码后部门内容正常、部门内容仍异常 ，可能是文件自身混用了多种编码 ，或者乱码产生在不止一个处置环节。
为什么换了编码依然乱码 ？下一步该查字体、软件还是数据 ？
若是常见编码都无法让内容复原 ，就不要持续盲目切换� Ｄ芄灰勒铡跋允径恕寥《恕菰础钡陌ご纬中ㄎ�。
显示成方框或空缺：先查抄字体
方框通常暗示当前字体没有对应字形� Ｄ芄桓恢С种形摹⒎呕蛑副暧镅缘淖痔� ，并确认系统或利用没有强造使用一套不齐全的字体。字体问题只影响显示 ，不愿定代表文件内容败坏。若把文本复造到其他支持该字符的编纂器后可能正常显示 ，注明原文件或许率齐全 ，建复字体或显示设置即可。
若是方框现实是问号 ，尤其是文件保留后一向维持问号 ，则必要查抄原始数据。某些法式在无法鉴别字符时会直接用问号代替 ，代替实现后再换字体也不能恢复原字。
只有一个软件乱码：查抄打开和导入设置
统一文件在编纂器中正常、在表格软件中乱码 ，通常是导入时默认编码不匹配。不要直接双击文件打开 ，能够先进入“导入文本”或类似界面 ，指定分隔符、文本编码和列类型 ，再预览了局后导入。表格中的长数字、日期和前导零还可能被自动鉴别为其他类型 ，这不齐全属于编码乱码 ，应同时查抄列体式。
网页中的乱码则要查抄页面现实编码与申明是否一致。若服务器输出的是一种编码 ，页面申明却写成另一种编码 ，浏览器会按谬误方式解析。单独批改浏览器字体不能解决这类问题；应从网页源文件、响应设置和现实保留编码三处查对。
终端或号令行乱码：查抄说话环境和输出链路
终端乱码不愿定是文件乱码 ，也可能是法式输出编码与终端当前说话环境不一致� Ｄ芄槐鹄氩馐裕和骋晃谋驹诒嘧肫髦惺欠裾！⒅斩耸淙牒褪涑鍪欠穸家斐！⒊炼ㄏ虻轿募笪募欠裾�。若沉定向文件正常而终端显示异常 ，沉点查抄终端字体、说话环境和法式输出编码；若天生的文件也乱码 ，则回到法式的读写编码设置排查。
数据库或系统导入乱码：不要只批改显示页面
数据库场景至少要别离查抄数据写入前的编码、衔接字符集、表或字段的字符集 ，以及查问端的解码方式。只有页面乱码而数据库中原文正常 ，通常应建复查问衔接或页面输出设置；若是数据库中已经保留为问号或谬误字符 ，必要从源数据、备份或沉新导入解决。直接批量批改字符集可能造成二次败坏 ，必须先在副本上验证。
什么时辰能够直接转换 ，什么时辰应终场操作 ？
当乱码只是读取方式谬误 ，且原始字节内容没有扭转时 ，能够通过沉新选择正确编码并另存为统一体式复原。文件未被覆盖、分歧工具显示了局分歧、乱码拥有不变法规 ，通常都切合这一前提。
若是文件已经被谬误编码打开并保留 ，原字符被代替成问号、空缺或不成逆符号 ，或者源文件与备份都无法打开 ，就应终场反复转换。此时更适合寻找原始导出文件、汗青版本、发送方副本或数据库备份�８丛ぞ咧荒艹⑹猿两ú棵拍谌� ，不能保障找回被覆盖的原文。
建复乱码后怎么确认不会再次出现 ？
- 统一约定新文件使用 UTF-8 ，并在导入、导出和接口文档中明确写出编码 ，而不是依赖软件默认值。
- 跨系统传输前 ，用蕴含中文、英文、数字、标点、表情和特殊字符的测试样本验证一次。
- 转换后不要只查抄前几行 ，应查抄文件末尾、换杏注空值、长数字和少见字符。
- 对数据库、批量文本和沉要文档保留原始副本 ，先在测试文件上转换 ，再处置正式数据。
- 若是统一起源反复乱码 ，应纪录“起源编码—读取编码—保留编码”的齐全链路 ，定位产生转码的地位 ，而不是每次手工建复了局。
总的来说 ，乱码排查应先分辨编码谬误、字体缺失和数据败坏 ，再从原始起源向显示了局逐段查抄。能正�８丛那疤崾窃甲址廊淮嬖�；当内容已经被问号代替或文件被覆盖时 ，复原沉点就应转向备份和沉新导出 ，而不是持续尝试更多字体或编码。
![[09-17]午餐--9.17](http://n.sinaimg.cn/front/108/w1024h684/20180322/2b7m-fysnevk7495594.jpg "2b7m-fysnevk7495594")
