桌面集成始于文档，而不是任何工具包或应用程序捆绑包。如果每个应用程序都可以读取和写入文件，用户就可以沟通、协作和集成。从这个意义上说，用于 Office 文档的 OASIS XML 格式有可能成为自由计算领域最意义深远的进步之一。

OASIS 代表结构化信息标准促进组织。这个非营利联盟，前身为 SGML Open，成员包括 IBM、Sun 和波音等公司，旨在为几乎任何类型的结构化信息创建开放标准。我们在此介绍的是一种基于 XML 的格式，所有类型的 Office 文件（文本、电子表格、演示文稿等）通用。

这种级别的努力旨在推广文件格式，而不是任何特定的桌面、应用程序或 Linux 内核本身，其意义不可低估。格式的自由甚至比软件的自由更重要。只有通过它们以及来自 XML 的内部结构，数据才能在新的或不同的程序之间交换，而无需任何转换器，或者在异构组或服务器之间直接编辑、索引、分析和交换数据——就像没有炒作的 Web 服务一样。数据将开始完全属于最终用户。

图 1. 切换到 OASIS 并且永不回头：OpenOffice.org 只需点击几下即可将所有封闭格式的文档转换为新标准。

OASIS Office 技术委员会于 2003 年 2 月召开了第一次会议。官方文件格式应在 2004 年 2 月进行投票表决。批准后，第二阶段将开始；其主要目标是将基本规范扩展到其他应用领域。真正的目标是转向以文档为中心的模型，独立于任何给定的程序，并且对任何程序都可用，无论其许可证如何。技术委员会决心放弃今天的假设，即每个文件规范都必须与应用程序绑定。

一些有远见的公共管理部门已经开始这样思考。瑞典公共管理署表示，“[我们] 也应该关注并尽可能支持 OASIS 中正在进行的工作……用于 Office 软件的开放文件格式对于提高互操作性非常重要”（www.openoffice.org/servlets/ReadMsg?msgId=585772&listName=discuss）。在欧盟层面，IDA（行政部门之间的数据交换）于 2003 年决定对开放文档格式以及公共管理部门如何说服软件供应商支持它们进行探索性工作。

该标准符合 W3C 关于 XML 技术的通用规范，涵盖文档使用的各个方面。例如，用户交互在 XML 模式模板中描述，其操作方式类似于传统的 API 函数。然而，即使是它们现在也独立于任何单个应用程序。

文本格式可能比同样自由但二进制的格式更大且效率更低。然而，即使性能损失会很明显，但收益也太大了，不能放弃。OASIS Office 文件本身（无论是文本、演示文稿还是电子表格）都是一个 zip 压缩包：选择的压缩格式是在效率、访问内部部件的速度和算法许可证之间的一种折衷。解压缩后，我们首先找到五个 XML 文件：styles.xml，样式、演示文稿和格式；contents.xml，实际内容；settings.xml，应用程序设置，如缩放级别和打印机；meta.xml，语言和解码元数据；以及 manifest.xml，对所有其他文件及其相对路径的解释。

其他组件（每个组件都在预定义的文件夹中，以便病毒扫描程序也能更轻松地处理）可能是宏、它们的对话框和对象，例如图表或公式。

由于标准规定所有部分都必须存在于 zip 压缩包中，因此不会丢失任何信息：内容、布局和所有其他内容始终一起传输。与同一领域的某些专有产品不同，对必须使用哪个应用程序才能充分利用文档没有限制。所见即所得的结果是可能的，并且可以在 styles.xml 文件中完全指定或替换。但与此同时，内容和演示文稿是解耦的；因此，任何应用程序都可以获得内容，并且仅获得内容，用于任何可以想象的用途。例如，kfile-plugin-ooo 提取新文件格式中嵌入的所有元数据。然后，最终用户可以直接从 KOffice 或 Konqueror 读取、按元数据搜索或修改所有这些信息。此插件也包含在最新的 KOffice 源代码树中。

文本格式和内部结构使 UNIX 在处理和生成文本方面的数十年经验重新焕发活力，以驯服各种复杂的所见即所得 Office 文档。Shell 单行命令、Web 蜘蛛程序等可以直接像数据库引擎一样查询和处理单个文档或整类文档。在 mutt 或行业级内容管理系统中将附加的演示文稿视为文本变得更容易。作为概念验证，我能够通过键入以下命令，从演示文稿中获得清单 1 的（公认粗略的）轮廓：

# tr "<" "\012" < content.xml | grep ^text \
| cut '-d>' -f2, | uniq

Problems with
a lot of the bang up to date mainstream Free SW

Requires modern HW:

plenty of RAM

fast CPUs

big Hard disk drives

Unlike SW, modern HW cannot be "free as free beer"

Doesn't this sound familiar?

显然支持加密，并且任何段落都可以具有 identity 属性。通过此功能，可以根据用户的权限授予不同用户访问同一文档的不同部分的权限。默认文本编码为 UTF-8，即使可以选择其他编码。改进标准的建议可以发布到 office-comments@lists.oasis-open.org。

这种设计和实现都很好，但用户需要一些应用程序来使用它。有什么可用的？只有从头开始设计的软件或经过彻底修改以实现它的软件才能实现完全的兼容性。一般来说，现有程序及其开发人员可能不得不在标准和他们当前对完美文档的完美结构的理解之间做出妥协。例如，在某些应用程序中，边距是节或页面属性，而在其他应用程序中，边距是段落属性。

话虽如此，OpenOffice.org 的用户将最容易上手；OASIS 标准建立在当前的 OOo 格式之上，并且几乎与之相同。AbiWord 既有导入过滤器，也有不太高级的导出过滤器，但它们不是 100% 完整。非常欢迎为改进它们做出贡献。此程序还为最终用户提供了使用 OOo 作为默认文件格式的选项。KOffice 在改进 1.3 版本的过滤器后，计划开始将 OASIS 切换为未来版本的原生格式。KOffice 的主要开发人员之一 David Faure 也是技术委员会的成员，尽管 KOffice 中使用了面向框架而不是面向页面的范例，但他预计完全支持该标准没有任何真正的障碍。

图 2. KOffice 已准备好完全切换到 OASIS。内部结构已经以 XML 格式存储，包括元数据，并且可以使用外部插件进行搜索。

SIAG 通过外部应用程序提供对读取文本和电子表格文件的一些支持，但没有用于写入的支持。Emacs 肯定会迟早推出自己的 OASIS 模式，WordPerfect 在技术委员会中也有官方代表。简而言之，情况看起来不错。已经提供了选择，剩下的唯一事情是将 OASIS 设置为默认保存格式，并拒绝接收或发送专有格式的文件。

已经有很多代码可用于研究和重用，以处理 OASIS 文件格式。无论您选择什么，都不要忘记标准本身和重点——格式和应用程序应保持分离。如果您想改进前者，请按照上述说明提交提案。如果您想要更快或功能更强大的代码，请自己动手或帮助相应应用程序的开发人员，而无需触及格式或发明新的格式。

已经有几个独立的过滤器可用于在 OASIS/OOo 文件（或通用 XML）和其他格式之间来回移动。实用程序 RTF2XML、ooo2txt、SIAG、O3read、o3totxt、o3tohtml、OOo2sDbk、Writer2LaTeX 和 soffice2html（请参阅资源）共同涵盖了 RTF、(X)HTML、LaTeX、DocBook，当然还有纯文本。

CPAN 托管了几个对 OASIS 相关处理有用的 Perl 模块。OpenOffice::Parse::SXC 解析 OOo 电子表格，使每个单元格的文本值（但仅限文本值）可用于主脚本。它附带一个将 OOo 电子表格转换为 CSV 格式的实用程序。另一个 Perl 模块 XML::Excel 可以将 Excel 电子表格转换为纯 XML，如果需要，可以将它们转储到中间结构中以进行自定义处理。在服务器端，Apache::AxKit::Provider::OpenOffice 提取文本 (.sxw) 文件的内容。

Tcl 具有 linters、DOM 和 XSLT 接口，以及允许切换到不同解析器的 API，而无需更改应用程序代码。在没有其他可用程序时，将使用本机 Tcl 解析器；否则，开发人员可以利用 Expat 和 Libxml（见下文）。

PDA 开发人员有一个专门的项目，与 OASIS 直接相关，称为 XMerge，目前正在 Java 中为 Palm 和 Pocket PC 开发。其目的是允许使用 PDA 本机应用程序编辑 OOo 文档（可能先前已转换为更有限的格式），以便可以将任何更改合并回原始格式，而不会丢失样式、格式等。

在较低级别，在通常使用 C 或 C++ 作为源语言且必须最大化性能的较大型应用程序中管理 OASIS 文件需要什么？首先，程序必须包含适当的库来压缩和解压缩 zip 文件。这不是 OASIS 特有的问题，因此我们将不再赘述。

一旦单个 XML 文件可用，就必须以理解并使内部结构（即，几个元素之间的关系）可访问的方式加载它们。执行此步骤后，可以以任何方式转换或处理数据。已经存在许多用于此目的的工具。其中一些工具旨在支持通用 XML 而不是 OASIS，但差异比人们预期的要小得多。这种情况预计在标准发布后不久就会得到改善。

Expat 是一个流行的 XML 解析器，用 C 语言编写，是基本的，缺乏验证功能，但仍然是目前最快的解析器之一。它还具有几乎每种语言的前端。Libxml 是一个功能更强大的库，支持 DTD 验证，并且专门为 GNOME 设计。与 Expat 一样，Libxml 用 C 语言编写，是可移植的，并且可以在许多语言中使用。Java 中的 Xerces 解析器也可以生成和验证 XML 文档。

在 Qt/KDE 领域，开发人员除了已经提到的 OOo 插件外，还可以使用相关的 Qt 类和 DOM 实现 (QDom) 来编写或解析 XML，以及 KOffice DTD。在撰写本文时，这些工具仍然针对 KOffice XML 格式，但预计它们将收敛于 OASIS 标准。

对于注重安全的开发人员来说，最简单的起点是基于 LibXML2 的 C XML 安全库 (XMLsec)，它支持 XML 材料的签名和加密。SAXEcho 是一个（主要是）Java 程序，它将自身附加到正在运行的 OpenOffice.org 文档，以显示当前文档的 XML 树表示。它还验证或修改直接在 XML 节点上操作的文档，以及其他一些巧妙的功能。

上面描述的解析器构建了文档的内部树表示。在开发必须处理大型文档的应用程序时，应该怎么做？请记住，这里的大型是指太大而无法放入内存，如果这种格式甚至必须适用于低端桌面应用程序，那么内存就不是那么大了。

此领域的当前解决方案遵循所谓的 SAX（XML 简单 API）方法：不是一次性构建文档的整个树并将其保存在那里以供进一步处理，而是逐步进行。SAX 解析器读取文档，并且不将其全部保存在内存中，而是在每次找到有价值的东西时生成一个事件。然后，解析器将事件传递给与应用程序交互的事件处理程序。有价值的东西可以是 XML 文档类型定义、错误或实际内容的元素。SAX 项目是基于 SAX 的编程的良好起点。Java 中的 JAXP 和 Perl 中的 Orchard 项目已经支持 SAX2，Orchard 项目非常稳定，更不用说就 SAX 和 XML 处理而言速度快且轻量级。

为本文所做的所有研究证实了我的最初印象之一：到目前为止，自由软件/开源软件保证信息交换的方法一直是开发跨平台应用程序，这些应用程序难以维护和针对每个目标环境进行优化。现在看来我们开始做正确的事情了，那就是定义真正自由、标准、独立于工具包、跨平台的格式，让每个人都可以自由创建任何可能的前端来读取和写入它们。

首先感谢 Gary Edwards 和 David Faure 提供的所有材料和解释。Pierre Souchay (kfile-plugin-ooo) 和 AbiWord 开发人员也提供了很大帮助。