UTF-8是HTML唯一合法编码，为何仍需显式指定字符编码？

根据HTML标准 § 4.2.5.4 指定文档字符编码章节规定：

Encoding标准要求必须使用UTF-8字符编码，且必须使用"utf-8"编码标签进行标识。该要求规定：若文档存在字符编码声明，则指定的编码标签必须与"utf-8"实现ASCII大小写不敏感匹配。无论是否存在字符编码声明，文档实际使用的编码必须为UTF-8。

(…)

若HTML文档未以BOM开头、未通过Content-Type元数据显式指定编码，且不属于iframe srcdoc文档，则必须通过带charset属性的meta元素，或处于编码声明状态、带http-equiv属性的meta元素指定编码。

注：即使文档所有字符均属于ASCII范围，也必须（在Content-Type元数据或文件中显式）提供字符编码声明，因为处理表单中用户输入的非ASCII字符、脚本生成的URL等场景时，均需要用到字符编码信息。

从上述规则可以得到两个明确结论：

• HTML规范层面只允许使用UTF-8作为文档编码
• 即便文档实际用的是UTF-8，规范仍强制要求显式声明编码

很多人会觉得这个要求多此一举：既然最终都要用UTF-8，显式声明是不是冗余设计？如果已经写了<!DOCTYPE html>标记为HTML5文档，能不能省掉charset声明，让浏览器默认按UTF-8解析就行？
答案是这个要求一点都不冗余，charset声明绝对不能省，所有规则都是踩了几十年Web兼容坑攒出来的硬约束，核心原因有三个：

• 编码判断的时机远早于DOCTYPE解析。浏览器是边下载边解码边渲染的流式工作模式，不会等整个文档下载完成、把所有标签读一遍再决定用什么编码——一般拿到前1024字节的时候就必须确定编码，否则后续内容根本没法解码。这个位置通常还没轮到DOCTYPE标签（标准要求charset必须写在文档前1024字节，就是适配这个解析逻辑），等浏览器读到<!DOCTYPE html>知道这是HTML5文档的时候，编码判断早就结束了，根本没机会触发所谓的“HTML5默认UTF-8”逻辑。如果这时候没找到显式charset声明，浏览器会直接启用沿用了几十年的旧编码嗅探逻辑，根据系统区域、字节特征猜测编码，很容易把纯UTF-8的文档错判成GBK、Latin-1等旧编码，直接出乱码，且不会因为后面读到DOCTYPE就回头重解析。
• HTML的运行场景远不止浏览器走HTTP访问这一种。网页会被用户存到本地双击打开、被邮件客户端渲染、被爬虫/电子书生成工具/富文本编辑器解析、被各种代理和中间设备转发，这些场景里很多根本不会解析DOCTYPE标签，甚至没有HTTP层的Content-Type头来传递编码信息，没有显式charset声明的话，不同工具会按自己的默认编码处理，乱码是大概率事件。
• 规范要求用UTF-8，不代表整个互联网已经没有非UTF-8的存量内容。直到现在全球范围内还有海量HTML5普及前建设的旧网站，用着GBK、Shift_JIS、Windows-1252等传统编码，浏览器不可能直接删掉传承了几十年的编码兼容逻辑、强制“无声明就默认UTF-8”，否则所有旧网站打开都会直接乱码，这个成本是整个Web生态承担不起的。显式写charset声明本质是给所有处理这份文档的环节一个最明确的信号，直接跳过所有编码猜测逻辑按UTF-8处理，反而是最高效、最不容易出问题的方案。

内容的提问来源于stack exchange，提问作者gaazkam