XML 数据的编码方式

Chris Lovett
Microsoft Corporation
2000 年 3 月

目录

摘要：本文介绍了字符编码的工作原理，特别是在 XML 和 MSXML DOM 中的工作原理。

近来很多人问我，如何使 XML 文件在不同的平台间正确地传递数据。他们创建了 XML 文档，键入了数据，粘上了几个标记，调整了标记的格式，甚至放入了 <?xml version=1.0?> 声明，作为额外增添。然后他们试着装载它，可得到的却是意想不到的出错消息，Microsoft(R) XML Parser (MSXML) 报告说数据有问题。对初编 XML 者来说，这真令人沮丧。难道它竟不能正常工作吗？

当然不是。当从 MSXML 收到意想不到的出错消息时，很可能是因为接收数据的平台将其存储到了与发送数据不同的平台上，结果导致了字符编码问题。

跨平台数据格式

自从计算机软件和硬件从业人员设法将两台计算机连接到一起以来，他们就一直向着创建跨平台技术并使不同的平台能够共享数据的领域而努力奋斗。很早以来，由于不同类型的计算机的数量、连接方式、希望共享的数据种类的急剧增加，事态也就变得越来越复杂。

经过几十年关于跨平台编程技术的研究，当今（而且可能在未来的很长一段时期内）唯一的真正跨平台解决方案是通过简单的标准数据格式得到的。Web 的成功正是建立在这种格式上的。在 Web 服务器和 Web 浏览器之间传递的主要内容是 HTTP 标题和 HTML 页，两者都是标准的文本格式。

在以下几节中，我将讨论字符编码和标准字符集、Unicode、HTML Content-Type 标题、HTML Content-Type 元标记和字符实体。如果您熟悉上述概念，可跳过这些内容去读 encoding XML data for the XML Document Object Model (DOM) programmer（针对 XML 文档对象模型 (DOM) 编程人员的编码 XML 数据）的提示和技巧。有关详细信息，请参阅 XML and Character Encoding（XML 和字符编码）。

关于字符编码

标准文本格式是建立在标准字符集之上的。要记住，所有的计算机均将文本存储为数字。然而，不同的系统也可以用不同的数字存储相同的文本。下表显示了一组字节是如何被存储的，第一个是使用默认代码页 1252、运行 Microsoft Windows(R) 的典型计算机，第二个是使用 Macintosh Roman 代码页的典型 Apple(R) Macintosh(R) 计算机。

比方说，如果您的祖母从 http://www.barnesandnoble.com/（英文）订购了一本新书，她不会想到她的 Macintosh 计算机存储字符的方式，并不同于运行 www.barnesandnoble.com（英文）的新 Windows 2000 Web 服务器。在往 Internet 订购单的发货栏中输入瑞典家中的地址时，她相信 Internet 会正确地传递字符 å（在其 Macintosh 上的字节值是 140），并没想到接收和处理她发送消息的计算机会将字节值 140 转换为字母 Œ。

Unicode

Unicode Consortium（统一码协会）确信（用双字节而不是单字节表示每个字符）定义一个通用的代码页是个好主意，该代码页适用于全世界所有的语言，从而不同代码页之间的映射问题将不复存在。

既然如此，如果 Unicode 解决了跨平台的字符编码问题，那为何它却未成为唯一的标准呢？第一个问题是，转换到 Unicode 有时意味着使所有的文件大小加倍 — 这样做在网络世界中是不可想象的。因此有人仍乐于使用老的、单字节的字符集，如 ISO-8859-1 到 ISO-8859-15、Shift-JIS、EUC-KR 等等。

第二个问题是，仍存在许多并非基于 Unicode 的系统，这就意味着在网络上，某些组成 Unicode 字符的字节值可能会给那些更旧的系统造成严重问题。因此定义了“Unicode 转换格式 (UTF)”；它们运用位转换技术对 Unicode 字符进行编码，使其成为在老系统上“透明的”（或可安全通过）的字节值。

此类字符编码中最普及的是 UTF-8。UTF-8 采用 Unicode 标准的前 127 个字符（它们恰好是基本的拉丁文字符：A-Z、a-z 和 0-9，以及几个标点字符），并直接将其映射到单字节值。然后采用位转换技术，用字节的高位来编码 Unicode 字符的其余部分。这样做的结果是，小瑞典字符 å (0xE5) 变成了下列双字节乱码：Ã¥ (0xC3 0xA5)。所以，除非您能够在脑海里进行位转换，否则，在UTF-8 中编码的数据是无法被人读懂的。

Content-Type 标题

因为更旧的单字节字符集仍被使用，所以只有当指定了数据所在的实际字符集之后，传输数据的问题才能得以解决。认识到这一点后，Internet 电子邮件和 HTTP 协议小组定义了一种标准方法，用以在消息标题 Content-Type 属性中指定字符集。该属性从注册的字符集名称列表中指定一个字符集，该字符集名称是由 Internet Assigned Numbers Authority (IANA)定义的。典型的 HTTP 标题都可能包含下列文本：

HTTP/1.1 200 OKContent-Length: 15327Content-Type: text/html; charset:ISO-8859-1;Server: Microsoft-IIS/5.0Content-Location: http://www.microsoft.com/Default.htmDate: Wed, 08 Dec 1999 00:55:26 GMTLast-Modified: Mon, 06 Dec 1999 22:56:30 GMT

该标题向应用程序表明，跟在标题后面的内容位于 ISO-8859-1 字符集中。

Content-Type 元标记

Content-Type 属性是可选项，在有些应用程序中，HTTP 标题的信息被去掉了，而只有 HTML 本身通过。为了补救这一点，HTML 标准小组定义了一种可选的元标记方法，用于指定 HTML 文档本身的字符集，使 HTML 文档字符集是自描述的。

<META HTTP-EQUIV=Content-Type CONTENT=text/html; charset=ISO-8859-1>

在这种情况下，字符集 ISO-8859-1 说明在此特定的 HTML 页中，字节值 229 表示 å。现在该页对任何系统来说，都是完全清楚的，数据不会被曲解。遗憾的是，由于此元标记是可选的，所以它给错误留下了空子。

字符实体

不是所有的系统支持所有的注册字符集。例如，我并不认为很多平台实际上可支持称为 EBCDIC 的 IBM 主机字符集。Windows NT 是支持的，但许多其他系统很可能不支持 — 这大概就是 http://www.ibm.com（英文）主页为什么生成 ASCII 的原因。

作为备选方案，HTML 允许通过指定确切的 Unicode 字符值，对该页中的单个字符进行编码。然后将这些字符实体进行脱离字符集的分析，即可确切地确定其 Unicode 值。它的语法是 ?amp;#229;?or ?amp;#xE5;?。

XML 和字符编码

XML 从 HTML 那里借鉴了这些思想，并使之更进一步，定义了一个彻底明确的算法，以确定编码使用的字符集。在 XML 中，由 XML 声明中的可选编码属性定义字符编码。下列算法确定默认的编码：

如果文件以 Unicode 字节次序标志 [0xFF 0xFE] 或 [0xFE 0xFF] 开头，则认为该文档是在 UTF-16 编码中。否则，它在 UTF-8 中。

以下是所有正确和等效的 XML 文档：

字符集和 MSXML DOM

现在，讨论过不同的字符编码方法之后，让我们来看看如何在 MSXML DOM 中加载 XML 文档，以及当碰到模糊编码的字符时，可能收到的出错消息的类型。加载 XML DOM 文档的两个主要方法是 LoadXML 方法和 Load 方法。

LoadXML 方法总是采用只在 UCS-2 或 UTF-16 中编码的 Unicode BSTR。如果将非有效的 Unicode BSTR 的内容传递给 LoadXML，则加载会失败。

Load 方法可将以下内容当作 VARIANT：

Load 方法实现以下算法，用于确定 XML 的字符编码或字符集。

• 如果 Content-Type HTTP 标题定义了字符集，该字符集则替代 XML 文档本身的所有内容。因为没有 HTTP 标题，所以这显然不适用于 SAFEARRAY 和 IStream 机制。
  
  
• 如果有双字节 Unicode 字节次序标志，则它假设编码是 UTF-16。它既可处理大 endian，也可处理小 endian。
  
  
• 如果有四字节 Unicode 字节次序标志 (0xFF 0xFE 0xFF 0xFE)，则它假设编码是 UTF-32。它既可处理大 endian，也可处理小 endian。
  
  
• 否则，它假设编码是 UTF-8，除非它用指定其他一些字符集的编码属性（如 ISO-8859-1、Windows-1252、Shift-JIS 等），找到 XML 声明。

您将看到两个从 XML DOM 返回的指出编码问题的出错消息。第一个通常指出文档中的字符与 XML 文档的编码不匹配：

在文本内容中发现了一个无效字符。

ParseError 对象可告诉您这个捣乱字符在某一行的确切位置，以便使您解决该问题。

第二个出错消息指出您一开始用的是 Unicode 字节次序标志（或调用了 LoadXML 方法），然后编码属性指定了不是双字节编码的编码（如 UTF-8 或 Windows-1250）：

不支持从当前编码转换到指定的编码。

另外，您可能调用了 Load 方法，并在一开始使用了单字节编码（没有字节次序标志），但是它随后发现了指定双字节或四字节编码（如 UTF-16 或 UCS-4）的编码属性。

基本原则是不能利用 XML 声明的编码属性，在多字节字符集如 UTF-8、Shift-JIS 或 Windows-1250，与 Unicode 字符编码如 UTF-16、UCS-2 或 UCS-4 之间进行转换，这是因为声明本身必须对每个字符都使用与文档其余部分相同数量的字节。

最后，IXMLHttpRequest 接口提供如下方法，用以访问下载的数据：

var xmldoc = new ActiveXObject(Microsoft.XMLDOM)var e = xmldoc.createElement(test);e.text = å;xmldoc.appendChild(e);xmldoc.save(foo.xml);

<test>Ã¥</test>

var xmldoc = new ActiveXObject(Microsoft.XMLDOM)xmldoc.load(foo.xml);if (xmldoc.documentElement.text.charCodeAt(0) == 229){    WSc ript.echo(Yippee - it worked !!);}

var pi = xmldoc.createProcessingInstruction(xml,                          version=1.0 encoding=ISO-8859-1);xmldoc.appendChild(pi);

<?xml version=1.0 encoding=ISO-8859-1?><test>ålt;/test>

<?xml version=1.0?><test>ålt;/test>