17370845950

必须置于最前面，且为唯一推荐写法；值须为标准编码名，服务端响应头优先级更高。

charset meta 标签必须放在 最前面

浏览器解析 HTML 时，一旦遇到非 ASCII 字符（比如中文、日文），会立即用当前猜测的编码去解码；如果此时还没读到 ，就可能按默认编码（如 ISO-8859-1）错误解析，导致后续所有文本乱码，且无法回退修复。

所以它不能塞在 后面，也不能和 或 混排——必须是 中第一个可执行的标签（注释和空格不算）：

只认 charset 属性，不接受 http-equiv 写法

HTML5 明确废弃了旧式写法 。虽然多数浏览器仍兼容，但存在两个实际问题：

• 部分严格模式解析器（如某些 SSR 渲染引擎或校验工具）会警告或拒绝该写法
• 若服务器已通过 HTTP 响应头返回了 Content-Type: text/html; charset=GBK，而页面又用了 http-equiv，两者冲突时行为不可控

正确且唯一推荐的写法只有这一种：

值必须是标准编码名称，utf8 和 utf-8 都合法但推荐后者

HTML5 规范接受大小写不敏感的编码名，也接受带/不带连字符的变体。但要注意：

• UTF8、utf8、UTF-8、utf-8 全部被识别为 UTF-8
• gbk、GB2312、Big5 等也支持，但仅限 legacy 场景；现代项目一律用 UTF-8
• 不要写 utf_8、unicode、default 这类非标准名，会导致浏览器 fallback 到默认编码

实际部署中，统一用小写连字符形式最稳妥：

服务端响应头比 meta 标签优先级更高

如果服务器在 HTTP 响应头里明确写了 Content-Type: text/html; charset=ISO-8859-1，那么无论 怎么写，浏览器都会以响应头为准——这是规范强制要求。

这意味着：

• 本地双击打开 HTML 文件（file:// 协议）时，没有响应头，才真正依赖
• 上线前务必检查服务器配置（Nginx/Apache/Node.js 等），确保响应头未覆盖或冲突
• 用浏览器开发者工具的 Network → Response Headers 查看真实返回的 Content-Type

常见疏漏点：PHP 文件开头有 BOM 或空格，导致 header() 失败，最终没发 Content-Type，浏览器只能靠 meta 标签——这种“侥幸生效”其实掩盖了更深层的问题。