有没有理由不将HTML编码设置为UTF-8？

在日常开发中不使用UTF-8作为编码有什么好的理由吗

IE:在

…

中使用以下标记是否有任何缺点

<meta charset="utf-8">

这并不重要，因为它在大多数情况下都会被忽略，通常会使用HTTP内容类型头。我还认为，在较旧的浏览器中，它将被忽略。

这实际上取决于您在页面上显示的字符

以下是SO联合创始人Joel s的一篇好文章：

在日常开发中不使用UTF-8作为编码有什么好的理由吗

不是真的。有一些领域与UTF-8不太配合，比如旧的日本网络邮件服务，还有一些狡猾的文本编辑器仍然喜欢Windows ANSI代码页，但它们正在慢慢消失，大多数人可以忽略它们

有一些法律漏洞，比如中国软件产品必须支持陈旧的GB18030，但这并不排除UTF-8支持，也不影响我所理解的网站

尽管其他编码的效果可能比UTF-8小，但通常没有足够的差异来关注或弥补Unicode指令集其余部分的损失。UTF-16仍然可以覆盖所有内容，理论上，对于非ASCII BMP文本，UTF-16可能更小。。。但是对于HTML，它总是被所有ASCII文本的额外长度（包括标记和空格）所淹没。另外，UTF-16在网络上也不能很好地工作

在任何情况下，您都有希望提供压缩的页面，这将使即使是微小的差异也接近于无效

<meta charset="utf-8">

这是一种时髦的说法，但要想在旧浏览器中获得更广泛的支持，我还是会选择：

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

---

正如本文所提示的，您实际上所做的是假装发送了一个HTTP头，其中包含字符集。因此，您还需要确保没有真正的HTTP内容类型…字符集参数，因为真正标头的参数胜过HTML“meta”-hack。Apache

AddDefaultCharset

指令有时被不明智地用来为您提供一个您可能不想要的

charset

。

但是，为了安全起见，似乎到目前为止最好用UTF-8编码。如果该头实际包含

charset

参数，则Content-Type头仅覆盖元元素。这取决于服务器配置，但通常对于静态页面，情况并非如此。