网页文字显示乱码，通常不是字体大小或页面样式造成的，而是网页实际使用的字符编码与浏览器解析编码不一致。常见表现包括中文变成“é…”，出现问号、方框、无法识别的符号，或只有部分内容显示异常。排查时不要一开始反复切换浏览器编码，应先判断乱码范围，再依次检查浏览器环境、网页声明、服务器响应、源文件和数据来源。
先判断是单个网页乱码，还是所有网页乱码
先刷新当前页面，并在无痕窗口、另一种浏览器或另一台设备中打开同一网址。这个动作可以快速区分问题发生在本机，还是发生在网页本身。
- 只有一个网站或一个页面乱码：优先检查该网页的字符集声明、服务器响应头、模板文件和数据源。
- 同一网站在多个浏览器中都乱码：页面编码或服务端编码不一致的可能性较高。
- 很多不同网站都乱码：检查浏览器扩展、缓存、代理软件、系统区域设置或网络中间设备。
- 静态文字正常，文章内容或用户昵称乱码：重点检查数据库连接、接口返回内容和数据本身，而不是只改页面编码。
如果只是偶发显示异常，可以先执行强制刷新，并暂时禁用翻译插件、阅读模式插件和页面美化扩展。若问题仍能稳定复现，再进入编码排查。
第一步：检查服务器返回的字符编码
对于网站维护者，服务器返回的响应头是最先要确认的内容。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 文件编码、页面声明、接口内容和数据库连接能够保持一致，且清除旧缓存后各类中文内容均能正常显示，才可以确认问题已经恢复。若原始数据早已被错误编码覆盖，应优先恢复正确数据，再处理页面显示；单纯切换浏览器编码无法找回已经丢失的文字。
