ajax 代表 asynchronous javascript and xml，其思想是：利用具有高可靠性的现代 web 浏览器，可以在使用 web 应用程序的同时，通过服务器连接来回传递数据

　　ajax 代表 asynchronous javascript and xml，其思想是：利用具有高可靠性的现代 web 浏览器，可以在使用 web 应用程序的同时，通过服务器连接来回传递数据。标准的 web 技术会沿着链接前进，导致整个页面重新装载，而 ajax 突破了这个限制。基于 ajax 开发的许多方面需要不同于传统 web 页面的设计决策：如何管理返回按钮、如何显示更新的数据、以什么频率发送更新等等。本文只关注其中一个问题：应该以什么格式交换数据?

　　选择很多。ajax 中的 x 代表 xml，但是 xml 并非一种语言，它是一种用来构建语言的工具。所以，您要做的第一项决定是：是使用一种现有的语言，还是构建自己的语言?这要涉及几方面的权衡。必须考虑是否有一种现有的语言能够满足自己的需要，或者您是否能够设计一种更适合需要的语言?是否有处理这种语言的工具，还是必须自己构建工具?如果您要与别人交流(如果不需要与别人交流，那为什么要构建 web 应用程序呢?)，那么别人也熟悉这种语言吗?其他应用程序能顺利访问和使用您的数据吗?

　　可以从以下格式中进行选择：(x)html(包括微格式子集)、svg 或 x3d(用于图形数据)、atom(用于随时间变化的数据片段)、opml(用于简单的大纲)和 rdf(用于语义性图表)。在极端情况下，可以发送 docbook、dita 或 openoffice 格式的数据，这些格式非常复杂、具有语义性而且功能全面。(关于这些格式的更多信息参见 参考资料。)

　　在另一个极端，可以不理会 xml，转而发送任何类型的数据。可以发送二进制数据、图像、电影或 pdf 文件;但这是一种倒退，这些数据很难在浏览器中用 javascript 进行操作。更易于为人接受的方法是，发送比 xml 简单的文本格式：由制表符或逗号分隔的列表、markdown 或其他结构化程度较低的文本、yaml 或 json。即使不使用完整的 xml，您也有几十种选择，xml alternatives 站点对这些技术做了全面介绍。总之，选择的范围非常广，从最丰富也最复杂的，到没那么丰富更为简单的。而且，即使对于下面列表的一种格式，也可以找到多种数据编码方法，所以这个分类是有争议的，只能算是一种粗略的分类。

• 　　openoffice spreadsheet
• 　　dita(darwin information typing architecture)
• 　　docbook
• 　　rdf-xml
• 　　xhtml
• 　　microformat
• 　　atom
• 　　opml(outline processor markup language)
• 　　custom xml
• 　　markdown / textile / restructured text
• 　　yaml(yaml ain't markup language)
• 　　json(javascript object notation)
• 　　由逗号或制表符分隔的文本

　　应该衡量哪些因素?

　　面对如此之多的选择，如何做出合理的决定呢?出于如下几个原因，上面的列表无法严格地按照复杂性的次序排列。

• 　　首先，大多数格式都可以按照简单方式或复杂方式使用。
• 　　其次，必须区分复杂性表现在哪些方面：创建、读取、解析还是处理?xml 本身是相当复杂的，但是现有的工具比较成熟，例如浏览器中已经存在的解析器会使解析步骤简化。
• 　　第三，复杂性在很大程度上依赖于要处理的数据类型。数据是否具有非常严格的结构，比如电子表格或数据库?数据的结构是否非常松散，比如字处理文档或 blog 文章?数据是大文档(比如飞机的操作手册)，还是小的数据片段(比如响应编码)?如果数据集非常大，那么是必须同时发送完整的数据集，还是可以根据需要发送它的片段?将大数据集分割为小片段是否很困难?为了在另一端将小片段正确地重新组装起来，必须添加多少额外信息?

　　那么，最关键的因素是什么?它们包括：

• 　　详细程度/带宽(不像您想象得那么重要，只是有时候很重要)
• 　　可读性(以及可写性和可维护性)
• 　　解析的简便性(客户端和服务器端)
• 　　解析的速度(本机还是通过脚本)
• 　　信息丢失(比如，有序对 -> 词典 -> 集)
• 　　灵活性(有时候，灵活性低反而更好，这样更容易预测会发生的情况)
• 　　语言可移植性(可以用多少种语言操作这种格式?)
• 　　正确性(是否能够轻松地检查和确保数据符合格式?)
• 　　往复转换(即 markdown -> xhtml -> markdown，在这个过程中会丢失多少数据?)

　　在大多数情况下，优化的目标并不是速度、带宽利用率或者其他效率指标，而是更模糊的目标：用户满意度。即使有轻微的网络延迟，如果能够将延迟掩盖起来，让更新显得 很及时，那么这点延迟就不是问题了。毕竟，让用户更满意就是 ajax 比生成完整的新 web 页面更先进的原因。

　　经验性规则

　　在这里，我先给出一些经验性规则，然后用一些示例证明它们。根据下面的示例和我自己构建 web 应用程序的经验，我总结出了下面这些规则，在使用 ajax 时可以依据这些规则选择数据格式。

　　对于数据，使用 json：如果您拥有结构化或半结构化的数据，那么选择 json。浏览器中至少内置了三种解析器(html、xml 和 javascript)，速度最快的是 javascript。另外，如果用 javascript 操作数据，而数据已经存在于 javascript 中，就不需要进行复杂的 dom 操作。如果数据不直接用于显示，或者需要先做修改，或者将显示在 web 页面的不同部分中，或者具有不同的格式，那么 json 可能是不错的选择。如果数据适合关系数据库，那么 json 也是合适的选择。大多数编程语言都有很好的 json 库，所以不只能够用 javascript 进行操作。

　　对于混合型内容(文档)，使用 xml：如果需要使用元数据(比如 url)或标记和文本的各种混合形式，比如字处理文档和 blog 文章，那么就使用 xml。如果数据将在一个位置直接显示，就可以在服务器上对它进行格式化，然后使用 ajax 检索它并将它直接插入文档(这种技术有时候称为客户端包含)。正如 david 在他的 mochikit 文章中指出的(参见 参考资料)，可以将 xml 提供给现代浏览器并用 css 对它进行格式化，也可以提供 html 并选择是否应用样式。关于应该使用哪种 xml，我无法提供太多建议;但是，如果某种标准格式(比如 xhtml、svg 或 x3d)能够很好地 适应您的数据，就可以选用它。这样就可以使用这种格式的一个小子集，使数据具有更强的可互操作性，而且其他程序员也更熟悉这些标准格式，它们的文档也更完善。有时候，创建自己的 xml 格式是有好处，但是这会降低可互操作性，所以必须在某些基本方面能够获得很大的 改进，才值得这么做。如果不确定的话，就采用 html，这是 web 的通用语言。

　　为了联合，使用 atom：我这里所说的联合的含义非常广泛。如果您的数据将定期更新，那么可以将它放在 atom 中。如果数据应该加上时间戳，也可以使用 atom。基本上，对于任何随时间变化的数据流，都可以将 atom 格式作为标准的包装。这样，就可以使用许多现有的工具，通过聚合器、新闻阅读器和脚本库跟踪和重用数据。可以以这种方式将数据插入 web 页面，而且只需稍做努力，就可以将它转换为联合 feed。

　　选择的悖论

　　现在，看看对于同样的示例数据使用不同格式的情况，以及如何使用这些格式。以前的两篇专栏文章使用简单的示例以便将重点放在机制上，但是这一次要使用取自真实环境的数据。我的妻子 daniela 是一位诗人，她总是仔细地记录她向杂志、比赛和其他活动的投稿。她需要记录每篇诗稿处于什么阶段、哪些被接受了、哪些被拒绝了、每篇诗稿获得了多少稿费、她为每次活动花费了多少以及其他信息。清单 1 给出了一部分数据：

……