验证 XML 代码并对其字符进行编码

　　使用 XML 文档的主要困难在于检查其内部有效性(文档逻辑的内聚性)。需要执行语法检查以了解是否所有的标记和定义都是正确的并且被正确地调用。只有语法检查通过之后，才能确认 XML 文档格式良好并可以解析文档的逻辑结构。XML 文档由 XML 解析器验证。

　　所有以下描述的 Eclipse XML 插件都能够执行 XML 验证，指出代码中的警告和错误。如果试图打开一个 XML 文档，XML 解析器可能会生成一个错误。可以检索精确的错误代码、错误文本甚至导致错误的那一行。可以在需要时验证 XML 文档，或在保存文档时自动验证。可以将验证错误任务作为一组进行清除。XMLBuddy 插件使用系统范围的 XML 解析器，不过，请记住 Eclipse 平台带有最好的 XML 解析器之一:Xerces(XML4J)。但并不限于 Xerces 或系统解析器，因为可使用 Run => External Tools => Configure 指向其它 XML 解析器。

　　另一个重要的 XMLBuddy 功能是支持不同的字符编码。这迟早会有用，例如，当需要使用以不同语言(如波兰语和英语)编写的 XML 可移植文档时。这不是一项简单的任务，因为编码波兰语字符主要有三种方法:其一是由 Windows 9x/2000 使用的 Windows Latin-2(CP1250);其二是在因特网中使用以及由 UNIX 与类 UNIX 系统(如 Linux)使用的 ISO Latin-2(ISO8859-2);其三是 MacOS 和 MacOS X，它们对波兰语使用不同的字符编码标准。

　　通常，XMLBuddy 为字符编码提供两种解决方案:根据文件内容自动检测 XML 文档编码，或将其设置为缺省的编码。缺省的编码可以在工作空间范围，也可特定于资源。要打开 XML 编码首选项，可选择 Window => Preferences => XML => Encoding。

　　这些针对字符编码的解决方案的问题在于:对 XML 而言，一种编码(每个工作台一种)不能适应全部情况。XML 文档可能来自世界各地任意数量的来源。在许多情况下，用户不能控制其他人对文档的编码，而且可能没有办法按编码界限划分工作。同一编码首选项将很难同时适合(比方说) Java 源文件和 XML 文档。当一组全局首选项不能满足需要时，XMLBuddy 为每个文档提供属性。指定项目中每个文件的属性是一项繁重的任务。但是，当要处理的某一文档使用了不常用的编码(不能自动检测该编码，并且没有在文档中指定)时，则属性是唯一的解决方案。要打开特定文件的编码属性，可在文件上单击鼠标右键并选择 Properties = > XML => Encoding。

　　DTD vs. XML Schema

　　XML Schema 指定 XML Schema 定义语言，该语言提供了描述 XML 1.0 文档结构和限制其内容的工具，其中包括那些利用 XML Namespace 的工具。模式语言自身用 XML 1.0 表示并使用名称空间，它在很大程度上重构了 XML 1.0 DTD 具有的能力，并在一定程度上扩展了这些能力。请记住 DTD 有许多局限:

　　□ 对于复杂需求通常很难使用内容模型。

　　□ 不支持名称空间。

　　□ 对模块化和重用的支持非常有限。

　　□ 不支持对声明扩展或继承。

　　□ 编写、维护和读取大型 DTD 以及定义系列相关模式都很困难。

　　□ 没有嵌入式、结构化自我文档编制(self-documentation)(只有 可用)。

　　□ 内容和属性声明不能依靠属性或元素上下文(许多 XML 语言用到这一点，但它们的 DTD 必须“允许过多东西”)。

　　□ 只能使用一个简单的标识属性机制(换句话说，没有唯一性作用域)。

　　XML Schema 也有不足:

　　□ XML Schema 比较复杂;只需要偶尔使用 XML 的程序员可能觉得它难得有些过头。

　　□ XML Schema 不能请求特定的根元素(因此，即使验证最简单的文档也要求额外的信息)。