xml utf8 编码_用UTF-8编码XML文档

xml utf8 编码

Google的Sitemaps服务最近要求所有站点地图必须以Unicode的UTF-8编码专门发布，从而在XML社区引起了轻微的轰动。 Google甚至不允许使用Unicode的替代编码（例如UTF-16），更不允许使用非Unicode编码（例如ISO-8859-1）。 从技术上讲，这意味着Google使用的是不合格的XML解析器，因为XML建议特别要求“所有XML处理器必须接受Unicode 3.1的UTF-8和UTF-16编码”。 但是，这真的是一个大问题吗？

每个人都可以使用UTF-8

普遍性是选择UTF-8的第一个也是最令人信服的原因。 它可以处理当今星球上几乎所有正在使用的脚本。 仍然存在一些差距，但这些差距越来越模糊，现在正在填补。 通常，未发现的脚本也没有以任何其他字符集实现，即使有，也无法在XML中使用。 充其量，它们会被嫁接到像Latin-1这样的一字节字符集上的字体hack所覆盖。 对这些少数脚本的真正支持将首先出现，并且可能仅在Unicode中出现。

但是，这仅是使用Unicode的参数。 为什么选择UTF-8而不是UTF-16或其他Unicode编码？ 最简单的原因之一是广泛的工具支持。 几乎所有可能与XML一起使用的重要编辑器都可以处理UTF-8，包括JEdit，BBEdit，Eclipse，emacs甚至Notepad。 在XML和非XML工具中，没有其他Unicode编码具有如此广泛的工具支持。

在某些情况下，例如BBEdit和Eclipse，UTF-8不是默认字符集。 现在是时候更改默认值了-所有工具都应该开箱即用，将UTF-8选择为默认编码。 在这种情况发生之前，我们陷入了无法互操作的文件的混乱之中，这些文件在跨国家，平台和语言边界传输时会破裂。 但是在所有程序默认为UTF-8之前，您可以轻松更改默认值。 例如，在Eclipse中，图1所示的“ General / Editors”首选项面板允许您指定所有文件都应为UTF-8。 您会注意到Eclipse希望默认使用MacRoman。 但是，如果您允许这样做，则当文件传输到在Microsoft®Windows®或美洲和西欧以外的任何计算机上工作的程序员时，文件将不会编译。

图1.在Eclipse中更改默认字符集

当然，要使UTF-8正常工作，与您交换文件的开发人员也必须使用UTF-8。 但这不应该是一个问题。 与MacRoman不同，UTF-8不仅限于少数脚本和少数平台。 UTF-8适合所有人。 对于MacRoman，Latin-1，SJIS和其他各种国家传统字符集而言，情况并非如此。

UTF-8在不希望接收多字节数据的工具上也能更好地工作。 其他Unicode格式（例如UTF-16）往往包含许多零字节。 有许多工具将这些字节解释为文件末尾或某些其他特殊的定界符，从而产生意想不到的，无法预料的以及通常令人不快的效果。 例如，如果将UTF-16数据天真地加载到C字符串中，则该字符串可能会在第一个ASCII字符的第二个字节上被截断。 UTF-8文件仅包含真正意味着为null的null。 当然，您不会选择使用任何此类幼稚的工具来处理XML文档。 但是，文档通常会出现在旧系统中的陌生地方，没有人真正考虑或理解将新酒装入旧瓶的后果。 与UTF-16或其他Unicode编码相比，UTF-8不太可能导致不了解Unicode和XML的系统出现问题。

规格怎么说

XML是第一个全心全意地支持UTF-8的主要标准，但这仅仅是趋势的开始。 标准机构越来越多地建议使用UTF-8。 例如，包含非ASCII字符的URL长期以来一直是Web上令人困扰的问题。 包含在Mac上的非ASCII字符的URL在Mac上加载后失败，反之亦然。 万维网联盟（W3C）和互联网工程任务组（IETF）同意，所有URL都将以UTF-8进行编码，而这一问题最近得到解决。

最近，W3C和IETF都更加坚定地选择首先，最后，有时甚至仅选择UTF-8。 万维网1.0：基本原理的W3C字符模型指出：“当需要唯一的字符编码时，字符编码必须为UTF-8，UTF-16或UTF-32。US-ASCII与UTF-向上兼容。 8（US-ASCII字符串也是UTF-8字符串，请参见[RFC 3629]），因此，如果需要与US-ASCII兼容，则UTF-8是合适的。” 实际上，与US-ASCII的兼容性是如此有用，几乎是必需的。 W3C明智地解释说：“在其他情况下，例如对于API，UTF-16或UTF-32可能更合适。选择其中一种可能的原因包括内部处理的效率以及与其他进程的互操作性。”

我可以相信关于内部处理效率的争论。 例如，Java™语言的字符串内部表示形式是基于UTF-16的，这使得索引字符串的速度更快。 但是，Java代码从不将此内部表示公开给与其交换数据的程序。 相反，对于外部数据交换，使用java.io.Writer ，并明确指定字符集。 做出这样的选择时，强烈建议使用UTF-8。

IETF更加明确。 IETF字符集策略[RFC 2277]明确指出：

协议必须能够对所有文本使用UTF-8字符集，该字符集由ISO 10646编码字符集和UTF-8字符编码方案（如[10646]附件R（在修订2中发布）定义）组成。

协议可以另外规定如何对ISO 10646使用其他字符集或其他字符编码方案，例如UTF-16，但是缺乏使用UTF-8的能力则违反了该政策。 这种违规将需要在协议规范文档中加入或推进标准流程之前，在协议规范文档中有明确而明确的理由的差异程序（[BCP9]第9节）。

对于现有协议或从现有数据存储中移动数据的协议，可能需要支持其他字符集，甚至使用UTF-8以外的默认字符集。 这是可以接受的，但必须支持UTF-8。

底线：对旧版协议和文件的支持可能需要一段时间才能接受UTF-8以外的字符集和编码-但是如果需要的话，我会保持警惕。 每个新协议，应用程序和文档都应使用UTF-8。

中文，日文和韩文

一个常见的误解是UTF-8是一种压缩格式。 不是。 ASCII范围内的字符仅占UTF-8中其他字符（特别是UTF-16）的一半。 但是，某些字符需要最多50％的空间才能用UTF-8进行编码-特别是中文，日文和韩文（CJK）表意文字。

但是，即使您使用UTF-8编码CJK XML，与UTF-16相比，实际的大小增加也不算太大。 例如，一个中文XML文档包含许多ASCII字符，例如<，>，＆，=，“，”和空格。在UTF-8中，这些字符都比在UTF-16中都小。确切的收缩或扩展因子会有所不同从一个文档到下一个文档，但是无论哪种方式，差异都不大。

最后，值得注意的是，与拉丁字母和西里尔字母字母的脚本相比，象中文和日语的表意文字往往与字符同等。 这些字符的绝对数量很大，每个字符需要三个或更多字节才能完全表示这些脚本。 这意味着相同的单词和句子可以用少于英语和俄语等语言的字符来表达。 例如，日本人对树的表意文字是æ??¨。 （它看起来有点像一棵树。）在UTF-8中占据了三个字节，而英语单词“ tree”则由四个字母和四个字节组成。 日本格罗夫的表意文字是æ???? （两棵树彼此相邻）。 它在UTF-8中仍占据三个字节，而英语单词“ grove”则需要五个字母并需要五个字节。 日本表意文字（三棵树）仍然只占三个字节。 但是，等效的英语单词“ forest”需要六个。

如果确实要进行压缩，请对XML进行zip或gzip压缩。 压缩后的UTF-8大小可能会接近压缩后的UTF-16，无论初始大小如何不同。 最初以较大者为准，它将具有更多冗余以减少压缩算法。

坚固性

真正的缺点是，从设计上讲，UTF-8是一种比之前或之后设计的任何其他文本编码更健壮和易于解释的格式。 首先，与UTF-16不同，UTF-8没有字节顺序问题。 大端和小端UTF-8是相同的，因为UTF-8是根据8位字节而不是16位字定义的。 UTF-8对于必须使用字节顺序标记或其他启发式解析的字节顺序没有任何歧义。

UTF-8的一个更重要的特征是无状态。 UTF-8流或序列的每个字节都是明确的。 在UTF-8中，您始终知道自己的位置-也就是说，给定一个字节，您可以立即确定它是单字节字符，两个字节字符的第一个字节，还是两个字节的第二个字节字符，或三字节或四字节字符的第二，第三或第四字节。 （这不是所有的可能性，但是您明白了。）在UTF-16中，您并不总是知道字节“ 0x41”是否为字母“ A”。 有时是，有时不是。 您必须跟踪足够的状态才能知道您在流中的位置。 如果丢失单个字节，则从该点开始的所有数据都将被破坏。 在UTF-8中，丢失或损坏的字节很明显，并且不会破坏其余数据。

UTF-8并非在所有情况下都是理想的。 当使用固定宽度的编码（例如UCS2或UTF-32）时，需要随机访问文档中特定索引的应用程序可以更快地运行。 （一旦考虑了代理对，UTF-16是可变宽度的字符编码。）但是，XML处理并不是这样的应用程序。 XML规范实际上要求解析器从XML文档的第一个字节开始，然后继续解析直到结束，并且所有现有的解析器都像这样运行。 更快的随机访问不会以任何有意义的方式帮助XML处理。 因此，尽管这可能是在数据库或其他系统中使用其他编码的一个很好的理由，但它不适用于XML。

摘要

在日益国际化的世界中，语言和政治边界每天变得越来越模糊，依赖于语言环境的字符集不再可行。 Unicode是唯一可以在地球上的许多区域进行互操作的字符集。 UTF-8是Unicode的正确编码：

• 它提供了广泛的工具支持，包括与传统ASCII系统的最佳兼容性。
• 它是直接且高效的处理。
• 它可以抵抗腐败。
• 它是平台无关的。

现在是时候停止争论字符集和编码了-选择UTF-8并完成讨论。

---

翻译自: https://www.ibm.com/developerworks/xml/library/x-utf8/index.html

xml utf8 编码