UTF8、ISO-8859-x 或 7 位 ASCII 和实体答案

【问题标题】：UTF8, ISO-8859-x or 7-bit ASCII and entitiesUTF8、ISO-8859-x 或 7 位 ASCII 和实体
【发布时间】：2009-03-21 13:51:07
【问题描述】：

您对在 XHTML 和 XML 中编码重音字符和特殊字符有何看法。

您是否将每个非 US-ASCII 字符都转换为命名实体？
您使用 ISO-8859-x 或 Win-125x 并将其他任何内容编码为实体？
还是直接用 UTF-8 编写所有内容，而不用关心实体？

请详细说明是什么以及为什么。

【问题讨论】：

我喜欢这听起来像一个考试问题......不是

标签： xml xhtml

【解决方案1】：

我无法确切告诉您为什么会发生这种情况，但在我为每个网页使用 UTF-8 的 5 年经验中（我主要使用西里尔文和波罗的海符号），我还没有看到任何字符显示不正确。

【讨论】：

【解决方案2】：

UTF-8。

它的设计完全是为了解决 kdgregory 提到的 UTF-16 出现的问题，它做得非常好。今天几乎所有的编辑器（包括记事本）都支持 UTF-8，它也是 XML 的默认编码。

【讨论】：

【解决方案3】：

不要打扰命名实体。当您需要手动编辑 HTML 文件并希望能够读取字符并且没有 UTF-8 编辑器时，它们非常适合。但除此之外，UTF-8 是要走的路。

【讨论】：

【解决方案4】：

我总是直接用 utf8 写。在此期间我遇到的唯一问题是服务器强制对标头进行 iso 编码。

【讨论】：

【解决方案5】：

始终为您的网站使用 UTF-8

现代框架和数据库服务器在支持 UTF-8 方面没有异议/问题。
当有人以与预期不同的语言输入文本时，您将避免出现问题，您会得到 ??????而不是一些 unicode 符号，甚至在页面模板没有被渲染时甚至更糟。
即使您的网站被标记为一种语言，但没有多语言界面（将来也会），有人可能会在您的网站上发布材料，并从他的朋友那里获得他们自己语言的 cmets。

问候，帕维尔

【讨论】：

【解决方案6】：

从美国人的角度讲：几乎所有文本都是 US-ASCII，带有一些符号和重音字符，我强烈建议使用数字或命名实体。

原因很简单：少了一件需要担心的事情。您无需确保您的网络服务器设置为宣传与您的内容相同的编码。因为迟早会有人在 Windows 上编辑页面，使用 Cp1252 编码，而其他人在 Linux 上使用 ISO-8859 工作，虽然两者很接近，但它们并不相同。如果网络服务器配置为 UTF-8，它们都会损坏。

也就是说，我给 Sergej +1 了，因为如果您正在处理主要不是 ASCII 的文本，您不想要大量的实体。

【讨论】：

+1 有一些东西。默认情况下，我有所有 UTF-8 的 Linux，但网页设计师对所有 ISO-8859-1 进行编码。但是编辑器中的“自动检测编码”选项很方便:-)
唯一可行的方法是，如果您正在构建静态网页，并且您与所有相关人员都有直接联系。即便如此，您仍然必须与不转换为实体的人打交道，这与如何以 UTF8 保存文件一样令人头疼。对于常规的 Web 应用程序，这种态度是危险的，因为您最终可能会在链中得到一个不知道编码的链接，从而使所有用户数据永久损坏，无法挽回。无论您是否选择使用实体，您都需要正确编码，否则您将陷入痛苦的世界。
让开发团队工作的一部分是沟通。但是，在团队内部进行沟通通常比在团队内部更容易，而且在许多公司中，部署与开发是分开管理的。至于通过网络应用程序堆栈管理编码：如果您的平台不为您执行此操作，那么您将处于一个受伤的时期。但是，嘿，谢谢你迟到的投票。

【解决方案7】：

我个人总是使用 UTF-8。它得到了很好的支持，并且每种语言、操作系统和浏览器都以某种方式支持它。实体很容易显示，但编辑起来很麻烦。命名实体可以引用很多字符，但只会涵盖西方字符集。对于亚洲语言，您将不得不回到十六进制实体，这并不漂亮。无论如何，十六进制实体也必须使用 Unicode 表进行解码或编码，因此您可能希望首先使用 unicode 风格对文本进行编码。

如果您的主要受众是英语，您可能会认为您可以使用 ISO-8859-1 或 cp1252，但这是错误的。迟早有人会写重音或其他外来字符，当这种情况发生时，修复您的编码为时已晚：某些文本已经搞砸了。

这里有一堆进一步阅读，让我在玩 charsets 时省了很多麻烦：

Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)是joelonsoftware.com对字符集及其用法和区别的详细介绍。那里的信息很笼统，但有助于确定选择哪种编码。

Character sets from Browser to Database 是来自 SUN 的一篇非常实用和务实的文章，其中涵盖了很多关于您必须验证您的编码没有被转换为其他内容的各个地方。

What Is UTF-8 And Why Is It Important? 是 SUN 的另一篇文章，深入探讨了 UTF-8 的本质，在阅读了前 2 篇文章后，应该允许您回答有关 UTF-8 细节的任何问题。

【讨论】：

【解决方案8】：

如果我主要在 ASCII 空间（英语，大多数浪漫语言）中工作，我会将所有非 ASCII 的内容转换为命名或编号的实体。这使我或其他没有适当字体的人可以使用它。这似乎不太可能，但总有一天你会在 SSH 上使用一些不支持 UTF-8 的被遗忘的终端，即使它支持，主机系统也不会安装正确的字体。

如果我编写的文本大多不是 ASCII，我将使用 UTF-8。如果文本是所有与 Unicode 替换框一样不可读的实体。

【讨论】：

【解决方案9】：

Unicode 的前 128 个字符与 ASCII 兼容。用这 128 个字符编写的文本既是有效的 ASCII 文件，又是 UTF-8 文件。 Unicode 是一个标准，每个人都应该使用。说英语的人不会看到差异，但不会说英语的人会。就我个人而言，如果它无法正确存储和显示我的姓氏，我对该软件及其创建者感到非常失望。

我还必须注意到，字符编码只是有关内部化的一系列问题中的第一个。尤其是在那些设计用于处理各种非英语语法问题的小型软件中尤为明显。

【讨论】：