当我尝试验证任何没有像这样的元编码的简单HTML文档时，我对我收到的错误消息感到非常困惑：
<!DOCTYPE html>
<html>
<head>
<title>Test</title>
</head>
<body>Test</body>
</html>
W3C验证器 http://validator.w3.org 当将文档粘贴到直接输入表单时，不情愿地接受该文档只有几个警告，但是当通过URI上载或加载文档时，验证失败并显示此错误消息
未声明字符编码。继续使用 窗口1252。
关于此错误，我有两件事我不明白：
有人可以解释这两点吗？我对这些东西很新，所以请耐心等待。
验证器的“直接输入”模式默认为UTF-8。用户代理（浏览器）将根据许多内容默认使用其他编码：
如果用户代理读取没有字符编码的文档 信息，它可以回退到使用其他一些信息。对于 例如，它可以依赖于用户的设置，无论是浏览器范围还是 特定于给定文档，或者它可以选择基于默认编码 用户的语言。对于西欧语言来说，这是典型的 并且相当安全地假设Windows-1252，类似于ISO-8859-1 但有可打印的字符代替一些控制代码。
W3C验证员说：
验证器使用实验性功能检查了您的文档：HTML5一致性检查器。此功能是为了您的方便而提供的，但请注意，它可能不可靠，或者与最新的一些尖端技术的最新发展不完全一致。
所以用一小撮盐取一些结果。
此外，没有有用的“后退”，验证器只需要选择一些/任何东西，以便它可以尝试为您验证。 W3C无法确定/决定您想要/需要使用的编码。您必须根据需要在网页上提供的字符自行声明，然后要求W3C根据该文档验证您的文档。
您使用什么编辑器/ WYSIWYG来制作网页？ 我们可以提供您要验证的网址吗？
当您使用Validate by URI时，服务器应该在HTTP标头中宣布字符编码，更确切地说是在 charset 的参数 Content-Type 标头值。在这种情况下，这显然不会发生。您可以查看情况，例如运用 Rex Swain的HTTP查看器。
根据条款 4.2.5.5指定文档的字符编码 在HTML5 CR中，“如果HTML文档不是以BOM开头，并且其内容类型元数据未明确给出其编码，并且该文档不是iframe srcdoc文档，则使用的字符编码必须是ASCII兼容的字符编码，必须使用带有charset属性的meta元素或在Encoding声明状态中带有http-equiv属性的元素来指定编码。“这有点复杂，但底线是：有几种方法声明编码，但如果没有使用它们，则文档不符合要求。
为什么 它指定的是有点推测，但一般的想法是这样的规则提高了可靠性和稳健性。如果不遵守规则，不同的浏览器可能会使用不同的默认值或猜测。
验证器假定使用windows-1252，因为HTML5规则导致了这一点。处理规则在 8.2.2.1确定字符编码。它们相当复杂，但它们在很大程度上反映了现代浏览器的做法（并旨在使其成为标准）。那里的规则也是为了处理不合格的文件，但这并不能使这些文件符合要求;错误处理规则并不是真正的“后备”，不应该依赖，特别是因为旧的浏览器并不总是遵守规则。
当涉及到其他一切都失败并且要使用“实现定义的或用户指定的默认字符编码”的情况时，错误规则会有些松散。关于浏览器可能做什么只是“建议”（再次反映现代浏览器通常做的事情），这可能涉及使用“用户的语言环境”，这是一个模糊的概念。然后验证器使用windows-1252，也许是因为这是英语的默认值，验证器“说”英语，或者可能只是因为它的猜测比任何其他单一选择更频繁。