网页文字显示乱码，通常不是字体大小或页面样式造成的，而是网页实际使用的字符编码与浏览器解析编码不一致。常见表现包括中文变成“é…”，出现问号、方框、无法识别的符号，或只有部分内容显示异常。排查时不要一开始反复切换浏览器编码，应先判断乱码范围，再依次检查浏览器环境、网页声明、服务器响应、源文件和数据来源。

先判断是单个网页乱码，还是所有网页乱码

先刷新当前页面，并在无痕窗口、另一种浏览器或另一台设备中打开同一网址。这个动作可以快速区分问题发生在本机，还是发生在网页本身。

• 只有一个网站或一个页面乱码：优先检查该网页的字符集声明、服务器响应头、模板文件和数据源。
• 同一网站在多个浏览器中都乱码：页面编码或服务端编码不一致的可能性较高。
• 很多不同网站都乱码：检查浏览器扩展、缓存、代理软件、系统区域设置或网络中间设备。
• 静态文字正常，文章内容或用户昵称乱码：重点检查数据库连接、接口返回内容和数据本身，而不是只改页面编码。

如果只是偶发显示异常，可以先执行强制刷新，并暂时禁用翻译插件、阅读模式插件和页面美化扩展。若问题仍能稳定复现，再进入编码排查。

第一步：检查服务器返回的字符编码

对于网站维护者，服务器返回的响应头是最先要确认的内容。HTML 页面应明确返回文本类型及其字符集，例如响应头中的 Content-Type 应包含 HTML 类型和 UTF-8 字符集信息。若服务器声明为一种编码，而页面文件实际保存为另一种编码，浏览器就可能按照错误方式解释字节。

检查浏览器开发者工具的网络请求，打开出现乱码的 HTML 文档，查看响应头和响应内容。重点确认以下情况：

• HTML 页面是否被返回成文本或 HTML 类型，而不是错误的二进制类型。
• 响应头声明的字符集是否与页面文件真实编码一致。
• 是否有反向代理、CDN、网关或服务器配置覆盖了应用原本的字符集。
• 不同页面是否由不同服务生成，导致部分页面使用 UTF-8，部分页面仍使用旧编码。

如果响应头明确声明了错误编码，应先修改服务器或应用的统一配置，再清理缓存并重新加载。只在浏览器中临时切换编码，最多用于验证原因，不能替代服务端修复。

第二步：确认 HTML 文件和字符集声明一致

如果服务器响应头没有问题，就检查 HTML 源文件本身。编辑器可能把文件保存为 GBK、GB2312、Windows 本地编码或 UTF-8，而网页声明却使用了另一种编码。文件中的中文在保存、上传或构建过程中被转换后，也可能直接变成问号。

打开页面源文件或模板文件，确认编辑器显示的文件编码，再核对 HTML 中的字符集声明。字符集声明应尽早出现在页面头部，并且与文件实际保存编码保持一致。实际项目中更适合统一使用 UTF-8，但不能只修改声明而不转换文件内容；如果文件仍是旧编码，单独改声明可能让乱码更严重。

修改前应保留原文件备份。正确的处理顺序通常是：确认原文件编码，使用可靠编辑器转换为目标编码，保存后重新上传或重新构建，再检查服务器响应头和浏览器实际显示结果。转换过程中如果原文件已经包含问号，原始汉字可能已经丢失，仅靠重新转换编码无法恢复。

第三步：区分页面文字乱码和动态数据乱码

如果页面标题、导航和按钮显示正常，只有文章正文、商品名称、评论或用户名异常，问题往往发生在动态数据链路。此时应沿着“数据库或文件—后端程序—接口响应—前端页面”的顺序检查，而不是继续修改 HTML 页面编码。

• 数据库中查看就是乱码：可能是导入时编码错误，或历史数据已经被错误转换。应从备份、原始文件或上游系统恢复正确内容。
• 数据库中正常，接口返回乱码：检查数据库连接字符集、驱动配置、后端字符串处理和接口响应头。
• 接口返回正常，页面显示乱码：检查前端解码、模板输出、脚本拼接和页面容器的编码处理。
• 保存后才乱码：重点检查表单提交编码、接口接收参数和写入数据库前的转换逻辑。

JSON、接口文本和 HTML 不应在多个环节被重复转换。尤其不要为了“修复”乱码，对已经是 UTF-8 的内容再次执行 GBK 与 UTF-8 互转，否则可能把正常文字变成不可逆的错误字符。

第四步：检查浏览器缓存、扩展和旧资源

如果服务器和源文件已经修正，但浏览器仍显示旧乱码，可能是缓存了旧页面、旧脚本或旧的字符集响应。先使用强制刷新，再清除该网站的缓存和站点数据。若网站使用了 Service Worker、离线缓存或 CDN，还要确认旧版本资源已经失效。

同时可以在无痕窗口中测试。无痕窗口正常而普通窗口异常，通常说明浏览器缓存、扩展或本地站点数据存在影响。逐个停用翻译、代理、阅读模式和内容替换类扩展，找到原因后只清理对应站点的数据即可，不必立即重置整个浏览器。

第五步：排查表单、网址参数和文件导入

如果乱码只出现在搜索词、表单提交内容、网址参数或上传文件中，应检查传输过程的编码处理。中文参数在页面提交、服务器接收、重定向和再次显示时，需要使用一致的编码和正确的转义方式。直接拼接未编码的参数，可能造成文字截断、问号替代或特殊符号异常。

导入文本文件时，也要确认文件本身的编码。有些旧系统会把 UTF-8 文件按本地编码读取，或把带有字符标记的文件处理错误。可以先用文本编辑器确认文件编码，再用系统要求的格式导入，并随机抽查中文、标点和特殊符号，而不要只检查英文内容。

按乱码表现快速定位原因

什么时候可以确认网页乱码已经修复

修复后不要只看首页。应在目标浏览器中重新加载页面，并分别检查静态文字、动态内容、表单输入、搜索结果、特殊标点和移动端显示。再用另一种浏览器或无痕窗口打开，确认不是本地缓存造成的假象。

当服务器返回的字符集、HTML 文件编码、页面声明、接口内容和数据库连接能够保持一致，且清除旧缓存后各类中文内容均能正常显示，才可以确认问题已经恢复。若原始数据早已被错误编码覆盖，应优先恢复正确数据，再处理页面显示；单纯切换浏览器编码无法找回已经丢失的文字。