如果遇到中文栏目名或正文变成问号、空白方框、无意义符号，可以按“先确认故障范围，再查编码、浏览器、缓存”的顺序处理。若网站保存的原始文字已经损坏，调整本机设置通常无法还原原文，需要由站点维护者从备份或原稿恢复。
先判断乱码出现在什么位置
先对照同一站点的栏目标题、正文和菜单，再用当前浏览器打开其他中文站点。若只在一个栏目或一篇文章中看到乱码，优先检查该处的字符集声明或存储文本；若多个站点都异常，再检查浏览器、系统语言和字体。若网页上汉字正常，复制到文档软件后才变成杂符，则应检查剪贴板和目标软件的编码识别方式。
| 看到的现象 | 先检查什么 | 如何判断 |
|---|---|---|
| 只有一篇文章或一个栏目乱码 | 该处的字符集声明、站点缓存 | 其他中文站点正常，故障多半局限在目标站点 |
| 多个中文站点同时乱码 | 浏览器设置、系统语言、字体 | 换一款浏览器后恢复，说明原浏览器环境值得优先排查 |
| 下载的文本文件打开后乱码 | 文件实际编码、编辑器的识别方式 | 用正确编码重新打开后，汉字恢复正常 |
| 同一串乱码在多台设备上都一样 | 网站或文件保存的原始文字 | 若原始文字已损坏，本机调整通常无效 |
| 只有复制后的文字乱码 | 剪贴板、粘贴目标软件 | 网页显示正常而粘贴结果异常，故障更可能发生在复制或导入环节 |
按编码、浏览器、缓存的顺序排查
- 重新载入并确认故障范围。刷新目标站点，再打开另一个中文站点作对照。若其他站点正常，不要急着更改系统语言；先把排查范围缩小到目标站点的字符集、浏览器扩展或本地缓存。
- 检查网页字符集。中文网页常用 UTF-8。站点维护者可检查 HTML 文档中的字符集声明，以及服务器响应头的字符集设置；两者都应与实际保存文字时采用的编码一致。若文件按一种编码保存、浏览器却按另一种编码解析，汉字就可能显示为问号或杂符。查看源文件时，也要确认声明位于文档开头并且没有与服务器设置冲突。
- 单独检查下载文件的编码。若乱码出现在文本、字幕或文档文件中，先用编辑器选择其他常见编码重新打开，确认汉字恢复后再另存为 UTF-8。操作前先复制一份原文件；不要在未确认显示正常时直接覆盖保存，以免把还能识别的文字进一步写坏。
- 用另一款浏览器或无痕窗口测试。如果无痕窗口显示正常，逐个停用扩展程序并重新载入，找出是否有扩展改写字符或拦截请求。若换浏览器后仍只有目标站点异常，而其他中文站点正常，就继续检查该站点的编码声明和响应设置。浏览器菜单名称因产品而异，无须安装来源不明的“乱码修复”工具。
- 最后清理目标站点的缓存。如果站点刚更新过，但浏览器仍显示旧版文字，可只清除该站点的缓存和临时数据，再重新载入。先不要删除全部浏览记录、登录状态和已保存数据。清理后仍出现完全相同的乱码，说明故障可能在服务器返回的文字或编码声明，而不只是本机缓存。
- 遇到方框时再检查字体和系统语言。若只有少数字符显示为空白方框，而句子结构和其他汉字正常，可检查系统是否安装相应字体、中文语言支持是否启用。个别生僻字缺字形时，字体缺失较为常见；若整段文字都变成问号或规则的杂符，应回到编码环节检查。
修复后逐项复测
确认故障消失时，不要只看站点是否能打开。依次检查栏目标题、文章正文、菜单文字和复制后的汉字；刷新浏览器或重新打开文件后，再复测一次。站点维护者修改字符集后，还应在不同浏览器中查看同一篇文章，并确认新旧文本没有混用编码。若同一篇文章在多台设备上持续显示相同的错误字符，可能是服务器保存的原稿已损坏，应从原始文档或备份恢复；反复切换浏览器设置无法补回丢失的汉字。
避免把乱码问题弄得更严重
怀疑文件编码异常时，先复制备份，再尝试切换编码；不确定显示结果前，不要连续另存并覆盖原文件。排查浏览器时，只调整常规显示设置，不安装要求额外权限的未知工具，也不要在不可信站点输入账号、密码或个人资料。第三方站点的汉字恢复正常，并不代表站点来源已经可信；若要提交截图或文件请人协助排查，先遮住姓名、账号和联系方式。
