HTML5规范明确支持UTF-8和UTF-16编码，其中UTF-8是强制要求必须支持的唯一编码，UTF-16为可选支持；其他如ISO-8859-1、GBK等虽被主流浏览器实际支持，但非HTML5规范强制要求。
HTML5 规范明确支持的字符编码有哪些
HTML5 允许浏览器解析任意 IANA 注册的字符编码，但实际支持程度取决于浏览器实现。主流浏览器（Chrome、Firefox、Safari、Edge）稳定支持的编码包括：UTF-8、ISO-8859-1、Windows-1252、GBK、GB2312、Big5、Shift_JIS、EUC-JP。其中只有 UTF-8 是 HTML5 强制要求必须支持的编码。
为什么只推荐用 UTF-8，而不是 GBK 或 ISO-8859-1
UTF-8 是唯一能无损表示所有 Unicode 字符的通用编码，而其他编码存在根本性局限：
-
ISO-8859-1只能表示 256 个字符，中文完全不可用；误用会导致替换符号或静默截断 -
GBK/GB2312虽能显示简体中文，但无法兼容日文假名、韩文、emoji、数学符号等；服务端或 CDN 若未显式声明charset=gbk，浏览器大概率 fallback 到UTF-8解码，直接乱码 -
UTF-8文件即使包含纯英文内容，字节流也与ASCII兼容，不会引发历史系统兼容问题
<meta charset> 声明位置和写法的硬性要求
这个标签必须满足三个条件，缺一不可，否则浏览器可能忽略它：
- 必须放在
<head>内，且是<head>中**前 1024 字节内**的第一个meta标签（实际开发中就放第一行） - 必须写成
<meta charset="UTF-8">，不能写成<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">—— 后者在某些旧版 IE 中解析不稳定 - HTML 文件本身必须以 UTF-8 无 BOM 格式保存；用 VS Code、Notepad++ 打开时注意右下角编码显示，避免误存为 UTF-8 with BOM
服务端响应头与前端声明不一致时会发生什么
浏览器按优先级顺序决定解码方式：HTTP Content-Type 响应头 > <meta charset> > 浏览器默认（通常是 UTF-8 或基于语言环境猜测）。常见问题包括：
立即学习“前端免费学习笔记（深入）”；
- Node.js/Express 默认不设
Content-Type: text/html; charset=UTF-8，导致即使写了<meta charset="UTF-8">，仍可能被忽略 - Nginx 静态服务若未配置
charset utf-8;，返回的响应头不含charset，此时依赖<meta>，但加载速度慢于响应头 - 使用
fetch()或XMLHttpRequest加载 HTML 片段时，响应头中的charset会覆盖片段内<meta>，这点极易被忽略
<meta charset> 声明、HTTP 响应头中的 charset —— 任一环节出错，中文就大概率变方块或问号。 
