网页显示乱码，通常不是文字内容本身损坏，而是网页实际使用的字符编码与浏览器解析方式不一致。排查时不要一开始就反复切换编码或修改页面文字，应先确认乱码范围，再按“浏览器环境—响应头—HTML声明—文件保存编码—数据来源—字体”的顺序定位。只有页面恢复后中文、标点和特殊符号均能正常显示，问题才算真正解决。
先判断乱码属于哪一类
先在同一浏览器打开其他中文网页，再用无痕窗口或另一款浏览器打开出现问题的页面。不同测试结果对应的处理方向不同：
- 只有一个页面乱码：优先检查该页面的响应头、HTML编码声明、源文件编码和页面数据。
- 同一网站多个页面乱码：重点检查网站服务器配置、模板文件、统一响应头、数据库连接或接口返回格式。
- 大多数中文网页都乱码：先排查浏览器缓存、扩展、代理软件、系统字体或浏览器环境。
- 文字变成方框、空白或问号：不一定是编码问题，也可能是缺少字体、字体文件加载失败，或原始数据已经用问号替换。
乱码形态也能提供线索。如果中文变成“ä¸æ–‡”这类看似有规律的拉丁字符，通常是UTF-8内容被按其他编码读取；如果出现大量“�”，往往说明解码时已经发生字符替换；如果只有图标、表情或少数字符异常，则应优先检查字体和字符支持范围。
第一步：排除浏览器缓存和扩展干扰
先按住刷新按钮执行强制刷新，或清除该网站的缓存后重新打开。缓存可能保留旧版HTML、旧的脚本或错误的编码响应，导致服务器已经修复，但浏览器仍显示旧结果。也可以使用无痕窗口测试，并暂时停用翻译、网页改写、阅读模式、广告过滤和脚本管理类扩展。
如果无痕窗口正常、普通窗口仍乱码，故障通常在缓存、Cookie或扩展，而不是网页源文件。此时不必马上修改页面编码，清理该站点数据或逐个恢复扩展即可。若不同浏览器都出现相同乱码，浏览器本身的可能性降低，应转向检查网页响应和源文件。
第二步：检查网页响应头是否声明了正确编码
如果是自己维护的网站，响应头是最先应确认的地方。HTML页面通常应返回类似以下信息：
Content-Type: text/html; charset=UTF-8
字符集名称应与实际文件编码一致。文件使用UTF-8，却在响应头中声明GBK，浏览器就可能按GBK解释UTF-8字节；反过来也会产生乱码。检查时可使用浏览器开发者工具的网络面板，重新加载页面，查看文档请求的响应头，而不是只看网页上显示的文字。
如果响应头中没有字符集声明，浏览器可能根据HTML内容猜测编码，结果会受到文档结构和历史规则影响。对中文页面而言，建议在服务器或应用框架中统一输出UTF-8，并避免同一站点不同页面使用互相冲突的声明。JSON、XML、CSV等接口也要分别检查返回类型和编码，不能只修复HTML页面。
第三步：检查HTML中的编码声明位置
HTML文档应尽早声明字符集，常见写法是：
<meta charset="UTF-8">
这条声明应放在页面头部靠前位置，并且不能与服务器响应头冲突。若页面仍保留旧式的GB2312或GBK声明，却实际保存为UTF-8，就需要统一修改；不能只增加一条新的声明，让同一页面同时出现多个不同字符集。
修改后应查看页面源代码和实际响应，确认浏览器收到的内容与声明一致。仅修改开发工具中的临时DOM不会改变服务器上的源文件，刷新后乱码仍会回来。对于由模板生成的页面，还要检查公共头部模板，避免单独修好一个页面后，其他页面继续使用旧声明。
第四步：确认文件保存编码与声明一致
网页文件、模板文件、样式文件和脚本中的中文，可能在编辑器保存时被转换成另一种编码。应使用编辑器查看当前文件编码，再按项目约定统一保存。新项目通常统一采用UTF-8，并同步确认服务器响应头和HTML声明也使用UTF-8。
不要根据乱码外观盲目把文件从UTF-8转换成GBK。正确做法是先备份原文件，确认原始字节编码，再进行一次明确的转换。若文件已经被错误解码后再次保存，部分字符可能已经不可逆地变成问号或替换符，这时仅切换编码无法恢复，必须从版本控制、备份或原始数据重新取回。
第五步：沿着数据链检查接口和数据库
页面源码正常，但某个列表、评论、标题或用户输入乱码，说明问题可能发生在数据传输链路中。应从数据源开始逐段确认：数据库实际存储内容、数据库连接字符集、后端读取方式、接口返回编码、前端解码方式，以及最终写入页面的内容。
常见错误包括数据库使用一种字符集，连接配置使用另一种字符集；接口返回的UTF-8文本被后端按本地编码读取；前端把已经解码的内容再次解码；或者数据在导入、导出CSV时被转换。处理原则是每一段都明确编码，并且只解码一次、只编码一次。如果接口返回的原始内容已经乱码，前端改字体或改HTML声明都不能修复源数据。
可以分别查看接口原始响应、服务器日志和数据库中的原值。若接口原始响应正常，而页面显示异常，重点检查前端处理和页面模板；若数据库原值已经异常，应先恢复数据源，再处理展示层。
第六步：区分编码乱码与字体缺失
编码错误通常会把一种文字显示成另一组错误字符；字体缺失则更常见于方框、空白、问号或部分生僻字无法显示。此时应检查操作系统是否安装所需字体、网页CSS指定的字体是否存在，以及远程字体文件是否加载成功。
如果只有某些Emoji、少数民族文字、数学符号或生僻汉字显示异常，应检查字体覆盖范围，并准备合理的备用字体。网页使用自定义字体时，还要确认字体文件路径、格式、跨域设置和加载状态。更换字体只能解决字形缺失，不能修复已经被错误编码的中文。
修改后如何确认已经恢复
修复后不要只看首页的一句话。先清除缓存并重新加载，再检查正文、标题、导航、表单输入、搜索结果、接口列表、标点、数字、Emoji和生僻字符。随后用至少一种不同浏览器或设备复测，确认不是某个本地环境的偶然正常。
- 响应头中的字符集与实际文件编码一致。
- HTML中的编码声明只有明确且有效的一种。
- 页面源代码中的中文正常，接口原始响应也正常。
- 刷新、重新登录或切换页面后不会再次乱码。
- 清理缓存后仍能正常显示，说明修复已进入实际发布内容。
暂时无法修改网站时怎么处理
如果乱码来自第三方网站，普通访问者通常只能尝试强制刷新、清除该站点数据、关闭网页改写扩展或更换浏览器。若多个浏览器和设备均异常，问题大概率在网站自身，继续调整本地编码不会改变服务器返回内容。
反馈给网站维护者时，提供出现乱码的页面、发生时间、浏览器和系统、乱码截图，以及其他页面是否正常。若页面涉及账号、订单或表单，不要在公开反馈中提交密码、身份证号等敏感信息。维护者应优先检查响应头和HTML声明，再沿数据链定位，而不是直接让用户反复切换浏览器编码。
排查结论
网页显示乱码的恢复顺序可以归纳为：先判断影响范围，随后排除缓存和扩展；如果问题稳定复现，就检查响应头、HTML编码声明和文件保存编码；局部内容异常时，再检查接口、数据库和数据转换；出现方框或空白时，补充检查字体。只有编码声明、实际字节、数据来源和字体显示彼此一致，页面才能在刷新和不同环境下持续正常显示。
