声明与判定顺序
浏览器确定网页编码遵循一套优先级：先看字节流开头的 BOM；没有 BOM 就看 HTTP 响应头里的 charset；头里没有才读 HTML 里的 meta 声明，且该声明必须位于文档前 1024 字节之内；再往后还有继承与编码探测等回退手段，最终可能按平台默认编码解析。因此页面文档写的 meta 不代表一定生效——响应头一旦声明了别的编码，meta 会被忽略，这也是「本地正常、线上乱码」的常见原因。
基本信息
| 优先级顺序 | BOM > HTTP 响应头 charset > meta 声明 > 继承 > 编码探测 |
|---|---|
| 推荐写法 | <meta charset="utf-8"> 等价于带 http-equiv 的长写法 |
| 位置约束 | meta 必须出现在文档前 1024 字节内，否则可能被忽略 |
| 服务端配合 | 响应头同时给出 Content-Type: text/html; charset=utf-8 |
| 表单相关 | 页面编码影响表单提交的编码，跨编码提交容易出乱码 |
| 检查方法 | curl -I 看响应头，再比对文档内的 meta 声明 |
典型使用场景
- 新站点规范：模板统一 UTF-8，服务端与页面声明保持一致
- 页面乱码排查：先比对响应头与 meta，再看内容实际字节
- 静态站点托管：托管平台可能按扩展名或配置重写响应头，需要核对
- 老站改造：历史页面用 GBK 声明，迁移时统一转成 UTF-8 并同步改声明
- 接口返回 HTML 片段：缺少声明时由调用方按默认编码解析，容易出错
声明与排查示例
声明与排查示例
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="utf-8"> # 必须在 head 顶部，1024 字节内
<title>示例页面</title>
</head>
<body>中文内容</body>
</html>
# 服务端响应头示例（Nginx）：add_header Content-Type 'text/html; charset=utf-8';
# 排查：curl -I https://example.com 看 charset 是否与页面声明一致判定来源与优先级
| 来源 | 优先级 | 说明 |
|---|---|---|
| BOM | 最高 | 存在时优先于其他所有声明 |
| HTTP 响应头 charset | 高 | 存在时页面内 meta 会被忽略 |
| meta 声明 | 中 | 仅当响应头未给出 charset 时生效，且需在 1024 字节内 |
| 继承与链接关系 | 低 | 来自父文档或预加载关系等场景 |
| 编码探测 | 最低 | 按内容统计猜测，结果依浏览器实现而不同 |
「本地打开正常」不代表没问题：本地文件没有 HTTP 头，只有 meta 生效；一旦上线，服务器或 CDN 注入的响应头会覆盖 meta，于是现象只在线上出现。排查异常时优先看响应头而不是页面源码。
编码声明与实际内容不一致会带来安全风险：历史上利用「浏览器探测结果与校验逻辑不一致」构造过 XSS 与绕过。规范做法是响应头与内容都固定 UTF-8，并禁止中间层重写 charset。
JSON 接口不依赖 HTML 元数据：JSON 规范要求使用 UTF-8，Content-Type 通常写作 application/json，不要给 JSON 加 charset 之外的自定义约定，也不要给响应体加 BOM。