网页中文乱码的根源是字符编码未明确声明，需同步确保HTTP响应头Content-Type含charset=utf-8、HTML中置于head最前、文件实际保存为UTF-8、数据库连接使用utf8mb4、JS请求用TextDecoder解码。
网页显示或方块字，Content-Type里没指定编码
浏览器没收到明确的字符编码声明时，会按默认规则猜（比如 IE 用系统区域设置，Chrome 有时回退到 ISO-8859-1），一猜就错，中文直接变。关键不是“有没有编码”，而是“有没有在 HTTP 响应头或 HTML 里说清楚”。
- 优先检查响应头：
Content-Type: text/html; charset=utf-8—— 缺少charset=utf-8是最常见原因 - HTML 文件开头必须有：
，且必须在最前面（不能等 JS 加载完再插） - 如果用 Nginx，确认没被其他配置覆盖：检查
charset指令是否写在 server 或 location 块里，且没被add_header Content-Type覆盖掉
后端输出 UTF-8 字节流，但文件本身是 GBK 编码保存的
编辑器保存文件时选错编码，会导致源码里的中文文字实际以 GBK 字节写入，而服务器按 UTF-8 发出去，浏览器再按 UTF-8 解，结果每个中文变成两三个乱码字符。这种问题在 Windows 上老项目里高频出现。
- 用 VS Code 打开文件，右下角看当前编码（如显示
GBK），点它 → “Save with Encoding” → 选UTF-8 - Sublime Text：菜单
File → Save with Encoding → UTF-8 - 命令行快速验证：
file -i your-file.html（Linux/macOS）或用iconv -l | grep -i utf辅助判断
fetch 或 XMLHttpRequest 加载文本后中文变乱码
JS 原生请求默认把响应体当 ISO-8859-1 处理，即使后端返回了 charset=utf-8，responseText 也可能已损坏；response.body 是原始字节流，更可靠。
- 用
fetch时，别直接读response.text()，改用：response.arrayBuffer().then(buf => new TextDecoder('utf-8').decode(buf)) - 如果确定服务端一定发 UTF-8，可在
fetch后手动指定：response.text().then(txt => new TextDecoder('utf-8').decode(new TextEncoder().encode(txt)))（不推荐，绕远路） - AJAX 请求中设
xhr.overrideMimeType('text/plain; charset=utf-8')可强制解码，但只对部分浏览器有效，兼容性差
数据库查出的数据在网页显示乱码
乱码链经常是：数据库存的是 UTF-8 → 连接层用了 latin1 → PHP/Python 拿到的就是错的字节 → 再吐给前端还是错的。单改 HTML 或响应头没用。
- MySQL 连接初始化时必须执行：
SET NAMES utf8mb4（注意是utf8mb4，不是utf8） - PHP PDO 示例：
new PDO($dsn, $user, $pass, [PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4']) - Python MySQLdb 或 PyMySQL：连接参数加
charset='utf8mb4'，且确保表和字段也是CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci
最容易被忽略的是「多层编码叠加」：文件编码、传输头、HTML 声明、数据库连接、甚至终端 locale，任何一层断掉，乱码就出现。修的时候别只盯一个地方。
