<meta charset="utf-8"> 与 <meta http-equiv="Content-Type">答案

【问题标题】：<meta charset="utf-8"> vs <meta http-equiv="Content-Type"><meta charset="utf-8"> 与 <meta http-equiv="Content-Type">
【发布时间】：2011-06-09 10:49:13
【问题描述】：

为了定义 HTML5 Doctype 的字符集，我应该使用哪种表示法？

短：
```
<meta charset="utf-8" /> 
```

长：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

【问题讨论】：

将标记用于诸如内容类型和编码之类的内容非常具有讽刺意味，因为在不了解这些内容的情况下，您无法解析文件以获取元标记的值。跨度>
您可以将其解析为 ASCII，直到您到达为止。 HTML5 解析算法考虑到了这一点。
请注意，当页面通过网络提供时，两者都不会用于解析。相反，将使用 HTTP Content-Type 响应标头中的那个。元标记仅在从本地磁盘文件系统加载页面时使用。
元元素在特定条件下通过 HTTP 使用（包括 HTTP 标头中没有数据）
具有讽刺意味的是，它被命名为charset，而实际上它是为了指定编码。（字符集是Unicode，编码是UTF-8）

标签： html meta-tags doctype

【解决方案1】：

要在电子邮件中嵌入签名，我会使用长版本：

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

原因是没有多少电子邮件阅读器使用 HTML5，所以最好使用旧的 HTML 样式。实际上，使用表格也比使用 divs + CSS 更好。

【讨论】：

【解决方案2】：

有一些消息基于Mozilla Foundation和SitePoint：

请勿使用此值 (http-equiv=content-type)，因为它已过时。首选 meta> 元素上的 charset 属性。

【讨论】：

哦，终于有更新的东西了

【解决方案3】：

虽然不质疑其他答案，但我认为以下内容值得一提。

“长”(http-equiv) 表示法和“短”表示法是相等的。以先到者为准；
Web 服务器标头将覆盖所有 <meta> 标记；
BOM（字节顺序标记）将覆盖所有内容，并且在许多情况下它会影响 HTML 4（可能还会影响其他内容）；
如果您不声明任何编码，您可能会在浏览器中定义的“备用文本编码”中获取您的文本。在 Firefox 和 Chrome 中都不是 UTF-8；
在没有其他线索的情况下，浏览器会尝试读取您的文档，就好像它是 ASCII 格式一样来获取编码，因此您不能使用任何奇怪的编码（不过，应该使用带有 BOM 的 UTF-16）；李>
虽然规范规定编码声明必须在文档的前 512 个字节内，但大多数浏览器会尝试读取更多内容。

您可以通过运行echo 'HTTP/1.1 200 OK\r\nContent-type: text/html; charset=windows-1251\r\n\r\n\xef\xbb\xbf<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><meta charset="windows-1251"><title>привет</title></head><body>привет</body></html>' | nc -lp 4500 并将浏览器指向localhost:4500 进行测试。（当然你会想要更改或删除部件。BOM 部件是\xef\xbb\xbf。小心你的外壳编码。）

请注意，明确声明编码非常重要。让浏览器猜测可能会导致安全问题。

【讨论】：

好点，但您能详细说明您指的是哪些安全问题吗？
长符号不应该覆盖短符号——只是文档中的第一个符号应该获胜。
@Armfoot 据我所知，过去UTF-7 曾经存在问题。在网络上嗅探通常也很糟糕，例如当你上传一个被嗅探为脚本内容的图像时。
@gsnedders 在 chrome 和 firefox 中测试，你是对的。相应地编辑了答案。 Armfoot：大概是 7 位编码，不记得具体是什么了。
@CraigMcQueen 很确定浏览器后备仍然（2018 年）在西欧默认为西欧，所以我想它默认为每个地区占主导地位的任何 pre-unicode 编码。用户可以将回退设置为 utf-8，但这只是暴露了数千个网站仍然使用的所有糟糕的编码，这些网站仍然使用有故障的高字节 ascii 字符，所以它仍然不常见。更可惜的是。如果没有浏览器供应商的一点强制，看不出这种情况会如何改变，而且他们也不热衷于打破旧有的东西。

【解决方案4】：

在使用 HTML5 时，对 Web 浏览器使用 <meta charset="utf-8" />。

在使用 HTML4 或 XHTML 时使用 <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />，或者用于过时的 DOM 解析器，例如 PHP 5.3 中的 DOMDocument。

【讨论】：

【解决方案5】：

在 HTML5 中，它们是等价的。使用较短的，因为它更容易记住和输入。 Browser support is fine，因为它是为向后兼容而设计的。

【讨论】：

浏览器支持怎么样？ <meta charset='utf-8'> 可以在 IE6 中使用吗？
这里是@Šime Vidas 提到的Google Code page 的更新链接。它说，关于 IE 6、7 和 8，“在非 IE 浏览器中，您可以使用 document.characterSet。在 IE 中，您可能认为您可以使用 document.getElementsByTagName('meta')[0].charset，但这只返回你指定的字符编码，而不是 IE 实际使用的编码。"
我知道这个帖子很旧，但gtmetrix.com/specify-a-character-set-early.html 表示使用<meta> 设置字符编码会禁用IE8 中的先行下载器，这会影响您的页面加载时间。是的，是的，我知道...放弃 IE8。 @MészárosLajos 可能会在几年后回到这里，并为仍然支持 IE8 而大发雷霆。 ;-)
developer.mozilla.org/en-US/docs/Web/Guide/HTML/… 对我来说是对这个答案的一个很好的确认。
今天我遇到了一个问题，即 IE11 中没有出现韩文符号。删除短语法以支持更长的语法解决了这个问题。我不知道这是否是由于某种服务器配置造成的，或者是否是 IE11 和字符集的问题。它失败的确切符号组合是베라。

【解决方案6】：

<meta charset="utf-8"> 是随/用于 HTML5 引入的。

如文档中所述，两者都是有效的。但是，<meta charset="utf-8"> 仅适用于 HTML5（并且更易于输入/记忆）。

在适当的时候，旧样式肯定会在不久的将来被弃用。我会坚持使用新的<meta charset="utf-8">。

只有一种方法，但是向上。就科技而言，这就是淘汰旧的（真的，真的很快）

文档： HTML meta charset Attribute—W3Schools

【讨论】：

链接见meta.stackoverflow.com/questions/280478/why-not-w3schools-com

【解决方案7】：

meta charset 声明的两种形式是等效的，并且应该在浏览器中相同。但是，在将 Web 文件字符集声明为 UTF-8 时，您需要记住以下几点：

以 UTF-8 编码保存文件byte-order mark (BOM)。
使用meta charset（如上）在您的 HTML 文件中声明编码。
您的网络服务器必须为您的文件提供服务，并在 Content-Type HTTP 标头中声明 UTF-8 编码。

Apache 服务器默认配置为以 ISO-8859-1 格式提供文件，因此您需要将以下行添加到您的 .htaccess 文件中：

AddDefaultCharset UTF-8

这将配置 Apache 以提供在 Content-Type 响应标头中声明 UTF-8 编码的文件，但您的文件必须首先以 UTF-8（无 BOM）保存。

记事本无法在没有 BOM 的情况下将文件保存为 UTF-8。一个免费的编辑器可以是Notepad++。在程序菜单栏上，选择“编码 > 不带 BOM 的 UTF-8 编码”。您还可以使用“编码 > 转换为不带 BOM 的 UTF-8”打开文件并以 UTF-8 重新保存它们。

更多关于Byte Order Mark (BOM) at Wikipedia。

【讨论】：

@CodeBoy 我会修改你的答案，说“你应该保存......没有 BOM。”以下页面显示“...通常最好省略 BOM 以实现互操作性...”表示最佳实践，但不是要求：w3.org/International/questions/qa-byte-order-mark
在 IIS 中，您可以在 Web.Config 中使用设置 HTTP 标头中的字符集 - 将其添加到
据我了解，如果您使用我们的无 BOM 进行保存，则根本没有关系。
为什么说 UTF-8 HTML 应该没有 BOM。拥有 BOM 应该可以正常工作。此外，您不需要 meta 和 HTTP 标头。您只需要 BOM、meta 或 HTTP 标头之一。
Summing up: don't use BOM for UTF-8 我不能同意这一点。 UTF-8 中的 BOM 对于表示编码类型非常有用。否则我们必须猜测，或者使用这个问题所指的元标记之类的东西。 BOM 很酷的地方在于它是 Unicode 规范的一部分，因此可以用于以 Unicode 编码的所有数据，而不仅仅是 HTML。我们应该做的是在任何地方都使用 BOM，让遗留软件在其上炸毁，报告这些错误并修复它们。

【解决方案8】：

选择短的另一个原因是它与您可能在标记中指定字符集的其他实例相匹配。例如：

<script type="javascript" charset="UTF-8" src="/script.js"></script>

<p><a charset="UTF-8" href="http://example.com/">Example Site</a></p>

一致性有助于减少错误并使代码更具可读性。

请注意，charset 属性不区分大小写。您可以使用 UTF-8 或 utf-8，但 UTF-8 更清晰、更易读、更准确。

此外，绝对没有理由在元字符集属性或页眉中使用 UTF-8 以外的任何值。 UTF-8 是自 1999 年 HTML4 以来 Web 文档的默认编码，也是制作现代网页的唯一实用方法。

您也不应该在 UTF-8 中使用 HTML 实体。应直接键入版权符号等字符。您应该使用的唯一实体是 5 个保留标记字符：小于、大于、与号、素数、双素数。实体需要一个 HTML 解析器，你可能并不总是想继续使用它，它们会引入错误，降低代码的可读性，增加文件大小，并且有时在各种浏览器中解码不正确，具体取决于你使用的实体。了解如何键入/插入版权、商标、开引号、闭引号、撇号、破折号、破折号、项目符号、欧元以及您在内容中遇到的任何其他字符，并在代码中使用这些实际字符。 Mac 有一个字符查看器，您可以在键盘系统偏好设置中打开它，您可以找到并拖放您需要的字符，或者使用匹配的键盘查看器查看要键入的键。例如，商标是 Option+2。 UTF-8 包含来自每种书面人类语言的所有字符和符号。因此，没有任何借口可以使用 -- 而不是破折号。学习标点符号和排版规则也不是一个坏主意……例如，知道句点在紧引号内，而不是在外。

对内容类型和编码之类的内容使用标签非常重要具有讽刺意味的是，因为不知道这些东西，您无法解析文件获取元标记的值。

不，那不是真的。浏览器开始将文件解析为浏览器的默认编码，UTF-8 或 ISO-8859-1。由于 US-ASCII 是 ISO-8859-1 和 UTF-8 的子集，因此浏览器可以以任何一种方式读取......它是一样的。当浏览器遇到元字符集标签时，如果编码与浏览器已经使用的不同，浏览器会以指定的编码重新加载页面。这就是为什么我们把 meta charset 标签放在顶部，就在 head 标签之后，在其他任何东西之前，甚至是标题。这样您就可以在标题中使用 UTF-8 字符。

您必须以不带 BOM 的 UTF-8 编码保存文件

这并不完全正确。如果您的文档中只有 US-ASCII 字符，则可以将其另存为 US-ASCII 并将其作为 UTF-8 提供，因为它是一个子集。但是如果有 Unicode 字符，你是对的，你必须 Save as UTF-8 without BOM。

如果您想要一个可以保存文件的优秀文本编辑器在 UTF-8 中，我推荐 Notepad++。

在 Mac 上，使用 Mac App Store 中的 Bare Bones TextWrangler（免费）或 Mac App Store 中的 Bare Bones BBEdit，价格为 39.99 美元……对于这样一款出色的工具来说非常便宜。在任一应用程序中，文档窗口底部都有一个菜单，您可以在其中指定文档编码，您可以轻松选择“UTF-8 no BOM”。当然，您可以在首选项中将其设置为新文档的默认设置。

但如果您的网络服务器在 HTTP 标头中提供编码，这是推荐的，两个[元标签]都是不需要的。

这是不正确的。您当然应该在 HTTP 标头中设置编码，但您还应该在 meta charset 属性中设置它，以便用户可以将页面从浏览器中保存到本地存储中，然后稍后再次打开，在这种情况下将出现的唯一编码指示是元字符集属性。出于同样的原因，您还应该设置一个基本标记……在服务器上，基本标记是不必要的，但是当从本地存储打开时，基本标记使页面能够像在服务器上一样工作，所有资产到位等，没有损坏的链接。

AddDefaultCharset UTF-8

或者您可以像这样更改特定文件类型的编码：

AddType text/html;charset=utf-8 html

同时提供 UTF-8 和 Latin-1 (ISO-8859-1) 文件的提示是给 UTF-8 文件一个“text”扩展名和 Latin-1 文件“txt”。

AddType text/plain;charset=iso-8859-1 txt
AddType text/plain;charset=utf-8 text

最后，考虑使用 Unix 行结尾保存您的文档，而不是传统的 DOS 或（经典）Mac 行结尾，这无济于事而且可能会造成伤害，尤其是当我们离这些传统系统越来越远时。具有有效 HTML5、UTF-8 编码和 Unix 行尾的 HTML 文档是一项出色的工作。您可以在许多情况下共享、编辑、存储、读取和恢复并依赖该文档。是通用语。是电子纸。

【讨论】：

“如果您的文档中只有 ISO-8859-1 字符，您可以将其另存为 ISO-8859-1 并作为 UTF-8 提供，因为它是一个子集” - 不正确。如果您将“ISO-8859-1”更改为“US-ASCII”，那将是正确的。 US-ASCII 与 UTF-8 兼容，因为它是一个子集，而 ISO-8859-1 不是。要将 ISO-8859-1（包含非 ASCII 字符）转换为 UTF-8，您需要对非 ASCII 字符进行编码。 ISO-8859-1 的代码点确实存在于 Unicode 中，但 UTF-8 对 US-ASCII 以外的代码点进行编码与 ISO-8859-1 不同。
您关于 HTML 实体的观点很好。过去，我使用实体只是发现它们在保存在不同的系统上和/或在不同的编辑器中打开后被转换为它们的 UTF-8 字符。然而，值得注意的是，不间断空格 ( ) 可能会产生令人困惑的结果，因为您通常不会在编辑器中看到它们，因此为了清晰起见，通常最好将它们保留为实体（根据我的经验）。
"You should also set a base tag..." 应该附带here 描述的注意事项。
您可能更喜欢 HTML 实体的另一个原因是，如果您使用类似 ionicons 的东西。我宁愿看到&#xf101;，也不愿看到默认字形或一些我不认识的奇怪字符。