14

当我尝试验证任何没有像这样的元编码的简单 HTML 文档时，我对收到的错误消息感到非常困惑：

<!DOCTYPE html>
<html>
<head>
<title>Test</title>
</head>
<body>Test</body>
</html>

W3C 验证器http://validator.w3.org在将文档粘贴到直接输入表单时不情愿地接受该文档为有效，但是当文档通过 URI 上传或加载时，验证失败并显示此错误消息

未声明字符编码。继续使用 windows-1252。

关于这个错误，我有两件事不明白：

  • 当存在回退规则时，为什么缺少字符编码会被视为错误？
  • 为什么验证器假设 windows-1252 而不是 UTF-8，就像任何浏览器一样？

有人可以解释这两点吗？我对这些东西很陌生，所以请多多包涵。

4

4 回答 4

15

好吧，这取决于您使用的是什么。

  • 如果您使用“文件上传”选项，则取决于保存 HTML 文件时使用的编码。
  • 如果您使用的是直接输入选项，则取决于导航器。

如果您不希望验证器猜测并使用UTF-8，则可以添加以下行

<meta charset="UTF-8">

在head 元素内部。

于 2013-07-29T23:35:45.160 回答
6

验证器的“直接输入”模式默认为 UTF-8。用户代理（浏览器）将基于以下因素默认使用其他编码：

维基百科

如果用户代理读取没有字符编码信息的文档，它可以回退到使用其他一些信息。例如，它可以依赖于用户的设置，无论是浏览器范围的设置还是给定文档的特定设置，或者它可以根据用户的语言选择默认编码。对于西欧语言，假定 Windows-1252 是典型且相当安全的，它类似于 ISO-8859-1，但使用可打印字符代替了一些控制代码。

于 2013-07-29T23:29:16.370 回答
3

W3C 验证者说：

验证器使用实验性功能检查您的文档：HTML5 一致性检查器。为了您的方便，提供了此功能，但请注意，它可能不可靠，或者与某些尖端技术的最新发展不完全同步。

因此，用少许盐来取得一些结果。

此外，没有有用的“回退”，验证器只需要选择一些东西/任何东西，它就可以尝试为你验证。W3C 无法确定/决定您想要/需要使用什么编码。您必须根据需要在网页上提供的字符自行声明，然后要求 W3C 以此验证您的文档。

您使用什么编辑器/所见即所得来制作网页？我们可以提供您要验证的 URL 吗？

于 2013-07-29T23:35:24.970 回答
2

当您使用 URI 验证时，服务器应该在 HTTP 标头中宣布字符编码，更准确地说是在标头值的charset参数中。Content-Type在这种情况下，这显然不会发生。您可以检查情况，例如使用Rex Swain 的 HTTP 查看器。

根据条款4.2.5.5在 HTML5 CR 中指定文档的字符编码，“如果 HTML 文档不以 BOM 开头，并且其编码未由 Content-Type 元数据明确给出，并且该文档不是 iframe srcdoc 文档，那么所使用的字符编码必须是与 ASCII 兼容的字符编码，并且必须在 Encoding 声明状态下使用具有 charset 属性的元元素或具有 http-equiv 属性的元元素来指定编码。” 这有点复杂，但底线是：声明编码的方法有多种，但如果都不使用，则文档不符合要求。

为什么它如此指定有点推测，但一般的想法是这样的规则促进了可靠性和稳健性。当不遵守规则时，不同的浏览器可能会使用不同的默认值或猜测。

验证器假定 windows-1252，因为这是 HTML5 规则导致的。处理规则见8.2.2.1 确定字符编码。它们相当复杂，但它们在很大程度上反映了现代浏览器的工作方式（并旨在使其成为标准）。那里的规则也旨在处理不符合要求的文件，但这并不能使这些文件符合要求；错误处理规则并不是真正的“后备”，不应依赖，特别是因为旧浏览器并不总是遵守规则。

当遇到其他一切都失败并且要使用“实现定义的或用户指定的默认字符编码”的情况时，错误规则会变得有些松散。关于浏览器可能做什么只有“建议”（再次反映现代浏览器通常做什么），这可能涉及使用“用户的区域设置”，一个模糊的概念。然后验证器使用 windows-1252，可能是因为这是英语的默认设置并且验证器会“说”英语，或者可能只是因为它的猜测比任何其他单一替代方案更经常被认为是正确的。

于 2013-07-30T08:39:17.160 回答