绝大多数情况下必须填utf-8，因其支持全球字符（含简繁中文、emoji、多语言），而gb2312仅覆盖约6700汉字，无法显示生僻字及现代网页常用符号；文件编码、meta声明、http响应头三者须严格一致，否则必现乱码。
HTML里该填utf-8还是gb2312
绝大多数情况下，填 utf-8 是唯一合理选择。不是“可以选”，而是“必须选”——除非你维护一个 2005 年上线、至今未改过数据库和文件编码的老系统。
原因很简单：utf-8 能正确显示简体中文、繁体中文、日文、韩文、emoji、数学符号、阿拉伯文字……而 gb2312 只能覆盖约 6700 个汉字，连“?”（U+20BB7）这种常用生僻字都打不出来，更别说现代网页中常见的图标字体或国际化文案。
- 浏览器遇到
<meta charset="gb2312">却读到 utf-8 编码保存的文件，立刻出现乱码（比如“文嗔） - 编辑器默认保存为 utf-8（VS Code、Sublime、WebStorm 全部如此），硬配
gb2312等于主动制造不一致 - 服务器响应头若设为
Content-Type: text/html; charset=gb2312，但 HTML 里写的是utf-8，以响应头为准，照样乱码
为什么有些老项目还在用gbk或gb2312
不是技术优势，是历史包袱。早期 Windows 记事本默认用 gbk（微软叫 ANSI），很多政府/国企内网系统当年直接用记事本写页面，没意识到编码要统一声明。
这类项目现在的问题不是“能不能用”，而是“改不改得起”：数据库表字段是 CHARSET gbk、后端 PHP 文件是 gbk 编码、JS 字符串里还混着 \xa1\xa2 这种双字节裸码——动一处可能全崩。
-
gb2312不支持“镕”“煊”等扩展汉字；gbk支持更多，但仍远少于 utf-8 - 即使只做简体中文站，用户复制粘贴微信里的内容（含 emoji 或特殊标点）也会出错
- 现代前端构建工具（Vite、Webpack）默认按 utf-8 处理所有文本，强行塞 gbk 会触发编译警告甚至失败
如何确认当前 HTML 文件实际编码格式
别信文件后缀或编辑器右下角小字——那只是编辑器“以为”的编码。真实编码藏在字节流里。
最可靠方法是用命令行看前几个字节：
file -i index.html
或用 xxd 查 BOM：
head -c 3 index.html | xxd
- 输出
00000000: efbb bf→ utf-8 with BOM（虽不推荐，但合法） - 输出
00000000: ff fe→ utf-16le（少见，需改） - 无 BOM 且中文显示正常 → 极大概率是 utf-8（UTF-8 本身无强制 BOM）
- 用 Notepad++ 打开 → “编码”菜单里灰色不可点的项，就是当前识别出的实际编码
charset声明和文件编码不一致时会发生什么
浏览器会按 <meta charset="xxx"> 的指示去解码字节流。如果声明和实际不符，每个中文字符都会被拆成 2–3 个错误 ASCII 字符，比如“测试”变成“测试”。
注意：这个过程发生在 HTML 解析早期，DOM 都没建起来就错了，JS 无法事后修复。
- 常见诱因：用 UTF-8 编辑器保存文件，但忘了删掉旧的
<meta charset="gb2312"> - 某些国产浏览器（如老版 360）曾默认按 GBK 解码无声明页面，导致同一份 HTML 在不同浏览器表现不同
-
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">和<meta charset="utf-8">效果相同，但前者冗长且易拼错，优先用后者
真正容易被忽略的，是服务器配置和 HTML 声明的双重校验——哪怕文件、编辑器、meta 全对了，Nginx 或 Apache 若在响应头里硬塞了 charset=gbk，照样覆盖前端声明。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
