底部版权中文乱码是HTML编码链断裂的末端表现，根源在于文件实际编码、<meta charset="UTF-8">位置与格式、BOM存在、HTTP响应头Content-Type四者未统一为UTF-8。
底部版权中文乱码不是独立问题，而是整个 HTML 编码链断裂的末端表现——© 2026 йŮ 显示成 © 2026 中国女女 或一堆问号、方块、Ã，说明浏览器根本没用 UTF-8 解码，它在用 GBK、ISO-8859-1 甚至乱猜。
确认文件实际编码是不是 UTF-8（别信右下角）
VS Code 右下角写着 “UTF-8”，不代表文件真是 UTF-8。尤其 Windows 下用记事本保存过、从邮件拖进来的 HTML，常被误标为 UTF-8，实则 GBK。
- 按
Ctrl+Shift+P→ 输入Reopen with Encoding→ 选GBK或GB2312，看底部文字是否立刻变正常；如果能，说明文件是 GBK，不是 UTF-8 - Linux/macOS 终端运行：
file -i yourfile.html，若输出charset=gbk或charset=us-ascii（实为检测失败），就别信编辑器显示 - Sublime Text：菜单
File → Reopen with Encoding → GB2312同理验证
强制保存为无 BOM 的 UTF-8（BOM 是隐形杀手）
BOM（EF BB BF）在文件开头会干扰浏览器扫描 <meta charset="UTF-8">。浏览器只扫描前 1024 字节找 charset 声明，BOM 占了头三个字节，后面哪怕紧跟着 <meta>，也可能被跳过。
- VS Code：
Ctrl+Shift+P→Save with Encoding→ 选UTF-8（注意不是UTF-8 with BOM） - Notepad++：菜单
编码 → 转为 UTF-8 无 BOM 格式 - 验证是否真去 BOM：
head -c 3 yourfile.html | xxd，输出不含ef bb bf才算成功
<meta charset="UTF-8"> 必须在 <head> 最前面
它必须是 <head> 内第一个可解析内容，前面不能有任何空格、换行、注释或 BOM。哪怕只有 <head>\n\n<meta charset="UTF-8">，中间两个换行都可能导致 fallback 到 GBK。
立即学习“前端免费学习笔记（深入）”；
- 正确写法（开头即生效）：
<head> <meta charset="UTF-8"> <title>页面标题</title> </head>
- 错误写法（带空格或注释）：
<head> <!-- 页面编码声明 --> <meta charset="UTF-8">
—— 这种会被跳过 - 不要写成
<meta charset="utf8">或<meta charset="UTF8">，只有"UTF-8"是标准值，大小写敏感
检查 HTTP 响应头是否覆盖了 meta（上线后必查）
本地双击打开（file://）时，HTTP 头无效，只靠 <meta>；但一旦走 http:// 或 https://，服务器返回的 Content-Type 响应头优先级高于 <meta>。Nginx、Apache、Express 等若配置了 charset=iso-8859-1 或没设 charset，就会压掉你的 <meta>。
- F12 →
Network→ 刷新 → 点 HTML 请求 → 查Response Headers中的Content-Type - Nginx 配置需含：
charset utf-8;（不是add_header Content-Type ...，那是错的） - Express 中用
res.set('Content-Type', 'text/html; charset=utf-8')，且必须在res.send()之前 - PHP 中用
header('Content-Type: text/html; charset=utf-8')，且必须在任何输出（包括空格、BOM）之前调用
真正容易被忽略的是：底部乱码从来不是“底部的问题”，而是整页编码链里最脆弱的一环暴露了上游所有漏洞——BOM 没清、<meta> 写错位、文件存错编码、HTTP 头覆盖、甚至 JS 动态插入版权文本时用了错误的字符串来源（比如从 GBK 数据库读出未转码的字段）。修复时别只盯着 <footer> 里的文字，得从文件开头、HTTP 头、服务端响应一路查到底。
