字符集

字符编码规定字节与字符之间的对应关系。在 text/plain; charset=utf-8 中，字符集参数声明了这层关系，但修改参数不会改变正文。可靠的文本交付要求生产者实际使用的编码与消费者采用的解码规则相符，不能只检查配置文件里是否出现了 UTF-8 这个名称。标签、字节和格式规则需要共同成立。 先由格式确定规则 应用通常先把内存中的字符序列编码成字节，再发送响应；接收方则在处理文本之前把字节解码回来。如果响应还经过压缩，需要先解除 gzip 这样的内容编码，再进行字符解码。这是两次不同的转换，不能因为名称里都有“编码”就当成同一层。数据库连接、模板引擎和响应生成器都可能引入不一致，因此最后一个 HTTP 响应头写对了，并不能证明之前的转换过程正确。 HTML 遇到声明冲突时并不是任意猜测，而是有明确的编码探测算法。对于没有用户手动覆盖的普通网络解析，能够识别的字节顺序标记先于受支持的传输层编码声明被考虑，正文里的声明则在后面。因此，页面中的 meta 一般不能覆盖明确且受支持的 HTTP 字符集。应让两处都准确，并把 HTML 编码声明完整放在前一千零二十四个字节之内，而不是依赖冲突优先级去挽救错误输出。 各种文本格式没有一个统一的“缺失字符集时默认如何解码”规则。RFC 8259 要求非封闭生态系统之间交换的 JSON 使用 UTF-8，它的媒体类型注册没有定义 charset 参数，而且网络发送方不得在 JSON 前添加字节顺序标记。不能因为 JSON 和 HTML 都能看成文字，就把 HTML 的探测规则搬到 JSON 上。应先确定内容格式，再执行这个格式规定的编码契约。 坏掉的样子 仅包含 ASCII 的测试很容易掩盖错误，因为这些字符在 UTF-8 和常见旧编码中的字节相同。测试样本应包含重音字符、货币符号，或产品真实支持语言中的代表性文字。一份 Windows-1252 正文如果误标 UTF-8，严格解码可能直接报错；反过来，本实验的 UTF-8 字节被当成 Windows-1252 时却能成功解码，只是字符已经变了。因此，“没有异常”不是文字正确的证据，必须与已知原文比较。 ...