为什么我必须为我的 <script> 标签指定字符集属性？

Question

我有点奇怪的情况：

1. 主要 HTML 页面以 UTF-16 字符集提供（由于某些要求超出了此问题的范围）
2. HTML 页面使用<script> 标签来加载外部脚本（即它们具有src 属性）
3. 那些外部脚本是 US-ASCII/UTF-8
4. Web 服务器正在为内容类型为“application/javascript”的脚本提供服务，没有字符集提示
5. 脚本没有字节顺序标记 (BOM)

加载上述页面时，Firefox 和 Chrome（当前版本）都会抛出错误，指出脚本文件的第一个字符无效。

查看各个开发工具视图的“网络”选项卡显示文件很好（它们在预览器中呈现很好）。

我的结论是，浏览器对于“整个页面”的编码应该是什么或类似的愚蠢行为感到困惑。

所以我尝试在<script> 标签中添加charset="UTF-8" 属性，这似乎解决了问题。

但我真的不应该那样做，不是吗？

首先，服务器告诉客户端文档的类型是什么。它是 application/javascript 并且没有指定字符集。 （事实上​​，RFC 表示charset 仅适用于text/* MIME 类型）。好的，我可以理解为什么会有一些模棱两可的地方。

但是文档类型是 javascript，并且对于如何处理您不知道其实际字符集的 javascript 文件有一些明显的规则。例如，如果它有 BOM，则使用它。如果没有任何 BOM，应该很容易区分 UTF-16 和 UTF-8。 （请注意，在这些相同的页面上加载 CSS 文件似乎没有任何问题，这些文件的情况也与脚本相同。）

最后，封闭页面不必知道其依赖项的编码是什么。事实上，它可能不可能知道并明确指定charset 然后将页面与其依赖项紧密耦合，反之亦然。

有没有办法让浏览器正确检测这些依赖项的字符集，而无需在页面本身中指定charset？

Answer 1

如果文件中没有 BOM，或者文件的 <script> 或 Content-Type 中没有显式的 charset，则文件的编码不明确。浏览器可能假定为 UTF-8（并且应该，根据RFC 4329），但如果脚本包含任何实际上未以 UTF-8 编码的非 ASCII 字符，则不会处理该文件正确。

但是，HTML 5 第 4.11 节规定，如果 <script> 没有 charset 属性，则 <script> 的后备编码是文档的编码。如果没有 BOM 或charset 指定文件的实际编码，则回退生效。

因此，要么确保您的 HTML 和 JS 文件始终使用相同的编码，否则您必须明确说明 JS 文件的 charset，无论哪种方式。