第 1 页 Ajax 简介
Ajax 由 HTML、JavaScript™ 技术、DHTML 和 DOM 组成，这一杰出的方法可以将笨拙的 Web 界面转化成交互性的 Ajax 应用程序。本文的作者是一位 Ajax 专家，他演示了这些技术如何协同工作 —— 从总体概述到细节的讨论 —— 使高效的 Web 开发成为现实。他还揭开了 Ajax 核心概念的神秘面纱，包括 XMLHttpRequest 对象。
五年前，如果不知道 XML，您就是一只无人重视的丑小鸭。十八个月前，Ruby 成了关注的中心，不知道 Ruby 的程序员只能坐冷板凳了。今天，如果想跟上最新的技术时尚，那您的目标就是 Ajax。
但是，Ajax 不仅仅 是一种时尚，它是一种构建网站的强大方法，而且不像学习一种全新的语言那样困难。
但在详细探讨 Ajax 是什么之前，先让我们花几分钟了解 Ajax 做 什么。目前，编写应用程序时有两种基本的选择：
·桌面应用程序
·Web 应用程序
两者是类似的，桌面应用程序通常以 CD 为介质（有时候可从网站下载）并完全安装到您的计算机上。桌面应用程序可能使用互联网下载更新，但运行这些应用程序的代码在桌面计算机上。Web 应用程序运行在某处的 Web 服务器上 —— 毫不奇怪，要通过 Web 浏览器访问这种应用程序。
不过，比这些应用程序的运行代码放在何处更重要的是，应用程序如何运转以及如何与其进行交互。桌面应用程序一般很快（就在您的计算机上运行，不用等待互联网连接），具有漂亮的用户界面（通常和操作系统有关）和非凡的动态性。可以单击、选择、输入、打开菜单和子菜单、到处巡游，基本上不需要等待。
另一方面，Web 应用程序是最新的潮流，它们提供了在桌面上不能实现的服务（比如 Amazon.com 和 eBay）。但是，伴随着 Web 的强大而出现的是等待，等待服务器响应，等待屏幕刷新，等待请求返回和生成新的页面。
显然这样说过于简略了，但基本的概念就是如此。您可能已经猜到，Ajax 尝试建立桌面应用程序的功能和交互性，与不断更新的 Web 应用程序之间的桥梁。可以使用像桌面应用程序中常见的动态用户界面和漂亮的控件，不过是在 Web 应用程序中。
还等什么呢？我们来看看 Ajax 如何将笨拙的 Web 界面转化成能迅速响应的 Ajax 应用程序吧。
老技术，新技巧
在谈到 Ajax 时，实际上涉及到多种技术，要灵活地运用它必须深入了解这些不同的技术（本系列的头几篇文章将分别讨论这些技术）。好消息是您可能已经非常熟悉其中的大部分技术，更好的是这些技术都很容易学习，并不像完整的编程语言（如 Java 或 Ruby）那样困难。
下面是 Ajax 应用程序所用到的基本技术：
·HTML 用于建立 Web 表单并确定应用程序其他部分使用的字段。
·JavaScript 代码是运行 Ajax 应用程序的核心代码，帮助改进与服务器应用程序的通信。
·DHTML 或 Dynamic HTML，用于动态更新表单。我们将使用 div、span 和其他动态 HTML 元素来标记 HTML。
·文档对象模型 DOM 用于（通过 JavaScript 代码）处理 HTML 结构和（某些情况下）服务器返回的 XML。
Ajax 的定义
顺便说一下，Ajax 是 Asynchronous JavaScript and XML（以及 DHTML 等）的缩写。这个短语是 Adaptive Path 的 Jesse James Garrett 发明的（请参阅 参考资料），按照 Jesse 的解释，这不是 个首字母缩写词。
我们来进一步分析这些技术的职责。以后的文章中我将深入讨论这些技术，目前只要熟悉这些组件和技术就可以了。对这些代码越熟悉，就越容易从对这些技术的零散了解转变到真正把握这些技术（同时也真正打开了 Web 应用程序开发的大门）。
XMLHttpRequest 对象
要了解的一个对象可能对您来说也是最陌生的，即 XMLHttpRequest。这是一个 JavaScript 对象，创建该对象很简单，如清单 1 所示。
清单 1. 创建新的 XMLHttpRequest 对象
<script language="javascript" type="text/javascript">
var xmlHttp = new XMLHttpRequest();
</script>
下一期文章中将进一步讨论这个对象，现在要知道这是处理所有服务器通信的对象。继续阅读之前，先停下来想一想：通过 XMLHttpRequest 对象与服务器进行对话的是 JavaScript 技术。这不是一般的应用程序流，这恰恰是 Ajax 的强大功能的来源。
在一般的 Web 应用程序中，用户填写表单字段并单击 Submit 按钮。然后整个表单发送到服务器，服务器将它转发给处理表单的脚本（通常是 PHP 或 Java，也可能是 CGI 进程或者类似的东西），脚本执行完成后再发送回全新的页面。该页面可能是带有已经填充某些数据的新表单的 HTML，也可能是确认页面，或者是具有根据原来表单中输入数据选择的某些选项的页面。当然，在服务器上的脚本或程序处理和返回新表单时用户必须等待。屏幕变成一片空白，等到服务器返回数据后再重新绘制。这就是交互性差的原因，用户得不到立即反馈，因此感觉不同于桌面应用程序。
Ajax 基本上就是把 JavaScript 技术和 XMLHttpRequest 对象放在 Web 表单和服务器之间。当用户填写表单时，数据发送给一些 JavaScript 代码而不是 直接发送给服务器。相反，JavaScript 代码捕获表单数据并向服务器发送请求。同时用户屏幕上的表单也不会闪烁、消失或延迟。换句话说，JavaScript 代码在幕后发送请求，用户甚至不知道请求的发出。更好的是，请求是异步发送的，就是说 JavaScript 代码（和用户）不用等待服务器的响应。因此用户可以继续输入数据、滚动屏幕和使用应用程序。
然后，服务器将数据返回 JavaScript 代码（仍然在 Web 表单中），后者决定如何处理这些数据。它可以迅速更新表单数据，让人感觉应用程序是立即完成的，表单没有提交或刷新而用户得到了新数据。JavaScript 代码甚至可以对收到的数据执行某种计算，再发送另一个请求，完全不需要用户干预！这就是 XMLHttpRequest 的强大之处。它可以根据需要自行与服务器进行交互，用户甚至可以完全不知道幕后发生的一切。结果就是类似于桌面应用程序的动态、快速响应、高交互性的体验，但是背后又拥有互联网的全部强大力量。
加入一些 JavaScript
得到 XMLHttpRequest 的句柄后，其他的 JavaScript 代码就非常简单了。事实上，我们将使用 JavaScript 代码完成非常基本的任务：
·获取表单数据：JavaScript 代码很容易从 HTML 表单中抽取数据并发送到服务器。
·修改表单上的数据：更新表单也很简单，从设置字段值到迅速替换图像。
·解析 HTML 和 XML：使用 JavaScript 代码操纵 DOM（请参阅 下一节），处理 HTML 表单服务器返回的 XML 数据的结构。
对于前两点，需要非常熟悉 getElementById() 方法，如 清单 2 所示。
清单 2. 用 JavaScript 代码捕获和设置字段值
// Get the value of the "phone" field and stuff it in a variable called phone
var phone = document.getElementById("phone").value;
// Set some values on a form using an array called response
document.getElementById("order").value = response[0];
document.getElementById("address").value = response[1];
这里没有特别需要注意的地方，真是好极了！您应该认识到这里并没有非常复杂的东西。只要掌握了 XMLHttpRequest，Ajax 应用程序的其他部分就是如 清单 2 所示的简单 JavaScript 代码了，混合有少量的 HTML。同时，还要用一点儿 DOM，我们就来看看吧。
以 DOM 结束
最后还有 DOM，即文档对象模型。可能对有些读者来说 DOM 有点儿令人生畏，HTML 设计者很少使用它，即使 JavaScript 程序员也不大用到它，除非要完成某项高端编程任务。大量使用 DOM 的是 复杂的 Java 和 C/C++ 程序，这可能就是 DOM 被认为难以学习的原因。
幸运的是，在 JavaScript 技术中使用 DOM 很容易，也非常直观。现在，按照常规也许应该说明如何使用 DOM，或者至少要给出一些示例代码，但这样做也可能误导您。即使不理会 DOM，仍然能深入地探讨 Ajax，这也是我准备采用的方法。以后的文章将再次讨论 DOM，现在只要知道可能需要 DOM 就可以了。当需要在 JavaScript 代码和服务器之间传递 XML 和改变 HTML 表单的时候，我们再深入研究 DOM。没有它也能做一些有趣的工作，因此现在就把 DOM 放到一边吧。
获取 Request 对象
有了上面的基础知识后，我们来看看一些具体的例子。XMLHttpRequest 是 Ajax 应用程序的核心，而且对很多读者来说可能还比较陌生，我们就从这里开始吧。从 清单 1 可以看出，创建和使用这个对象非常简单，不是吗？等一等。
还记得几年前的那些讨厌的浏览器战争吗？没有一样东西在不同的浏览器上得到同样的结果。不管您是否相信，这些战争仍然在继续，虽然规模较小。但令人奇怪的是，XMLHttpRequest 成了这场战争的牺牲品之一。因此获得 XMLHttpRequest 对象可能需要采用不同的方法。下面我将详细地进行解释。
使用 Microsoft 浏览器
Microsoft 浏览器 Internet Explorer 使用 MSXML 解析器处理 XML（可以通过 参考资料 进一步了解 MSXML）。因此如果编写的 Ajax 应用程序要和 Internet Explorer 打交道，那么必须用一种特殊的方式创建对象。
但并不是这么简单。根据 Internet Explorer 中安装的 JavaScript 技术版本不同，MSXML 实际上有两种不同的版本，因此必须对这两种情况分别编写代码。请参阅 清单 3，其中的代码在 Microsoft 浏览器上创建了一个 XMLHttpRequest。
清单 3. 在 Microsoft 浏览器上创建 XMLHttpRequest 对象
var xmlHttp = false;
try {
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e2) {
xmlHttp = false;
}
}
您对这些代码可能还不完全理解，但没有关系。当本系列文章结束的时候，您将对 JavaScript 编程、错误处理、条件编译等有更深的了解。现在只要牢牢记住其中的两行代码：
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
和
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");。
这两行代码基本上就是尝试使用一个版本的 MSXML 创建对象，如果失败则使用另一个版本创建该对象。不错吧？如果都不成功，则将 xmlHttp 变量设为 false，告诉您的代码出现了问题。如果出现这种情况，可能是因为安装了非 Microsoft 浏览器，需要使用不同的代码。
处理 Mozilla 和非 Microsoft 浏览器
如果选择的浏览器不是 Internet Explorer，或者为非 Microsoft 浏览器编写代码，就需要使用不同的代码。事实上就是 清单 1 所示的一行简单代码：
var xmlHttp = new XMLHttpRequest object;。
这行简单得多的代码在 Mozilla、Firefox、Safari、Opera 以及基本上所有以任何形式或方式支持 Ajax 的非 Microsoft 浏览器中，创建了 XMLHttpRequest 对象。
结合起来
关键是要支持所有 浏览器。谁愿意编写一个只能用于 Internet Explorer 或者非 Microsoft 浏览器的应用程序呢？或者更糟，要编写一个应用程序两次？当然不！因此代码要同时支持 Internet Explorer 和非 Microsoft 浏览器。清单 4 显示了这样的代码。
清单 4. 以支持多种浏览器的方式创建 XMLHttpRequest 对象
/* Create a new XMLHttpRequest object to talk to the Web server */
var xmlHttp = false;
/*@cc_on @*/
/*@if (@_jscript_version >= 5)
try {
xmlHttp = new ActiveXObject("Msxml2.XMLHTTP");
} catch (e) {
try {
xmlHttp = new ActiveXObject("Microsoft.XMLHTTP");
} catch (e2) {
xmlHttp = false;
}
}
@end @*/
if (!xmlHttp && typeof XMLHttpRequest != 'undefined') {
xmlHttp = new XMLHttpRequest();
}
现在先不管那些注释掉的奇怪符号，如 @cc_on，这是特殊的 JavaScript 编译器命令，将在下一期针对 XMLHttpRequest 的文章中详细讨论。这段代码的核心分为三步：
如果感觉这像是一段相当普通的代码，那就对了，正是如此！当用户在 city 或 state 字段中输入新的值时，callServer() 方法就被触发，于是 Ajax 开始运行了。有点儿明白怎么回事了吧？好，就是如此！
结束语
现在您可能已经准备开始编写第一个 Ajax 应用程序了，至少也希望认真读一下 参考资料 中的那些文章了吧？但可以首先从这些应用程序如何工作的基本概念开始，对 XMLHttpRequest 对象有基本的了解。在下一期文章中，您将掌握这个对象，学会如何处理 JavaScript 和服务器的通信、如何使用 HTML 表单以及如何获得 DOM 句柄。
现在先花点儿时间考虑考虑 Ajax 应用程序有多么强大。设想一下，当单击按钮、输入一个字段、从组合框中选择一个选项或者用鼠标在屏幕上拖动时，Web 表单能够立刻作出响应会是什么情形。想一想异步 究竟意味着什么，想一想 JavaScript 代码运行而且不等待 服务器对它的请求作出响应。会遇到什么样的问题？会进入什么样的领域？考虑到这种新的方法，编程的时候应如何改变表单的设计？
如果在这些问题上花一点儿时间，与简单地剪切/粘贴某些代码到您根本不理解的应用程序中相比，收益会更多。在下一期文章中，我们将把这些概念付诸实践，详细介绍使应用程序按照这种方式工作所需要的代码。因此，现在先享受一下 Ajax 所带来的可能性吧。
显然有什么地方不对劲，而 Internet Explorer 很难说是一种过时的浏览器，因为全世界有 70% 在使用 Internet Explorer。换句话说，如果不支持 Microsoft 和 Internet Explorer 就不会受到 Web 世界的欢迎！因此我们需要采用不同的方法处理 Microsoft 浏览器。
经验证发现 Microsoft 支持 Ajax，但是其 XMLHttpRequest 版本有不同的称呼。事实上，它将其称为几种 不同的东西。如果使用较新版本的 Internet Explorer，则需要使用对象 Msxml2.XMLHTTP，而较老版本的 Internet Explorer 则使用 Microsoft.XMLHTTP。我们需要支持这两种对象类型（同时还要支持非 Microsoft 浏览器）。请看看 清单 4，它在前述代码的基础上增加了对 Microsoft 的支持。
Microsoft 参与了吗？
关于 Ajax 和 Microsoft 对该领域不断增长的兴趣和参与已经有很多文章进行了介绍。事实上，据说 Microsoft 最新版本的 Internet Explorer —— version 7.0，将在 2006 年下半年推出 —— 将开始直接支持 XMLHttpRequest，让您使用 new 关键字代替所有的 Msxml2.XMLHTTP 创建代码。但不要太激动，仍然需要支持旧的浏览器，因此跨浏览器代码不会很快消失。
</script>
这里没有难懂的地方。首先，代码创建了一个新变量 phone，并把 ID 为 “phone” 的表单字段的值赋给它。清单 8 展示了这个表单的 XHTML，其中可以看到 phone 字段及其 id 属性。
}
指定回调方法
现在我们所做的只有很少一点是新的、革命性的或异步的。必须承认，open() 方法中 “true” 这个小小的关键字建立了异步请求。但是除此之外，这些代码与用 Java servlet 及 JSP、PHP 或 Perl 编程没有什么两样。那么 Ajax 和 Web 2.0 最大的秘密是什么呢？秘密就在于 XMLHttpRequest 的一个简单属性 onreadystatechange。
首先一定要理解这些代码中的流程（如果需要请回顾 清单 10）。建立其请求然后发出请求。此外，因为是异步请求，所以 JavaScript 方法（例子中的 getCustomerInfo()）不会等待服务器。因此代码将继续执行，就是说，将退出该方法而把控制返回给表单。用户可以继续输入信息，应用程序不会等待服务器。
这就提出了一个有趣的问题：服务器完成了请求之后会发生什么？答案是什么也不发生，至少对现在的代码而言如此！显然这样不行，因此服务器在完成通过 XMLHttpRequest 发送给它的请求处理之后需要某种指示说明怎么做。
在 JavaScript 中引用函数：
JavaScript 是一种弱类型的语言，可以用变量引用任何东西。因此如果声明了一个函数 updatePage()，JavaScript 也将该函数名看作是一个变量。换句话说，可用变量名 updatePage 在代码中引用函数。
结束本文之前，我还要介绍 XMLHttpRequest 的另一个重要属性 responseXML。如果服务器选择使用 XML 响应则该属性包含（也许您已经猜到）XML 响应。处理 XML 响应和处理普通文本有很大不同，涉及到解析、文档对象模型（DOM）和其他一些问题。后面的文章中将进一步介绍 XML。但是因为 responseXML 通常和 responseText 一起讨论，这里有必要提一提。对于很多简单的 Ajax 应用程序 responseText 就够了，但是您很快就会看到通过 Ajax 应用程序也能很好地处理 XML。
结束语
您可能对 XMLHttpRequest 感到有点厌倦了，我很少看到一整篇文章讨论一个对象，特别是这种简单的对象。但是您将在使用 Ajax 编写的每个页面和应用程序中反复使用该对象。坦白地说，关于 XMLHttpRequest 还真有一些可说的内容。下一期文章中将介绍如何在请求中使用 POST 及 GET，来设置请求中的内容头部和从服务器响应读取内容头部，理解如何在请求/响应模型中编码请求和处理 XML。
再往后我们将介绍常见 Ajax 工具箱。这些工具箱实际上隐藏了本文所述的很多细节，使得 Ajax 编程更容易。您也许会想，既然有这么多工具箱为何还要对底层的细节编码。答案是，如果不知道应用程序在做什么，就很难发现应用程序中的问题。
因此不要忽略这些细节或者简单地浏览一下，如果便捷华丽的工具箱出现了错误，您就不必挠头或者发送邮件请求支持了。如果了解如何直接使用 XMLHttpRequest，就会发现很容易调试和解决最奇怪的问题。只有让其解决您的问题，工具箱才是好东西。
因此请熟悉 XMLHttpRequest 吧。事实上，如果您有使用工具箱的 Ajax 代码，可以尝试使用 XMLHttpRequest 对象及其属性和方法重新改写。这是一种不错的练习，可以帮助您更好地理解其中的原理。
下一期文章中将进一步讨论该对象，探讨它的一些更有趣的属性（如 responseXML），以及如何使用 POST 请求和以不同的格式发送数据。请开始编写代码吧，一个月后我们再继续讨论。
对于很多 Web 开发人员来说，只需要生成简单的请求并接收简单的响应即可；但是对于希望掌握 Ajax 的开发人员来说，必须要全面理解 HTTP 状态代码、就绪状态和 XMLHttpRequest 对象。在本文中，Brett McLaughlin 将向您介绍各种状态代码，并展示浏览器如何对其进行处理，本文还给出了在 Ajax 中使用的比较少见的 HTTP 请求。
在本系列的 上篇文章 中，我们将详细介绍 XMLHttpRequest 对象，它是 Ajax 应用程序的中心，负责处理服务器端应用程序和脚本的请求，并处理从服务器端组件返回的数据。由于所有的 Ajax 应用程序都要使用 XMLHttpRequest 对象，因此您可能会希望熟悉这个对象，从而能够让 Ajax 执行得更好。
在本文中，我将在上一篇文章的基础上重点介绍这个请求对象的 3 个关键部分的内容：
·HTTP 就绪状态
·HTTP 状态代码
·可以生成的请求类型
这三部分内容都是在构造一个请求时所要考虑的因素；但是介绍这些主题的内容太少了。然而，如果您不仅仅是想了解 Ajax 编程的常识，而是希望了解更多内容，就需要熟悉就绪状态、状态代码和请求本身的内容。当应用程序出现问题时 —— 这种问题总是存在 —— 那么如果能够正确理解就绪状态、如何生成一个 HEAD 请求或者 400 的状态代码的确切含义，就可以在 5 分钟内调试出问题，而不是在各种挫折和困惑中度过 5 个小时。
下面让我们首先来看一下 HTTP 就绪状态。
深入了解 HTTP 就绪状态
您应该还记得在上一篇文章中 XMLHttpRequest 对象有一个名为 readyState 的属性。这个属性确保服务器已经完成了一个请求，通常会使用一个回调函数从服务器中读出数据来更新 Web 表单或页面的内容。清单 1 给出了一个简单的例子（这也是本系列的上一篇文章中的一个例子 —— 请参见 参考资料）。
XMLHttpRequest 或 XMLHttp：换名玫瑰
Microsoft™ 和 Internet Explorer 使用了一个名为 XMLHttp 的对象，而不是 XMLHttpRequest 对象，而 Mozilla、Opera、Safari 和 大部分非 Microsoft 浏览器都使用的是后者。为了简单性起见，我将这两个对象都简单地称为 XMLHttpRequest。这既符合我们在 Web 上看到的情况，又符合 Microsoft 在 Internet Explorer 7.0 中使用 XMLHttpRequest 作为请求对象的意图。（有关这个问题的更多内容，请参见 第 2 部分。）
清单 1. 在回调函数中处理服务器的响应
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
var response = request.responseText.split("|");
document.getElementById("order").value = response[0];
document.getElementById("address").innerHTML =
response[1].replace(/\n/g, "<br />");
} else
alert("status is " + request.status);
}
}
这显然是就绪状态最常见（也是最简单）的用法。正如您从数字 "4" 中可以看出的一样，还有其他几个就绪状态（您在上一篇文章中也看到过这个清单 —— 请参见 参考资料）：
·0：请求未初始化（还没有调用 open()）。
·1：请求已经建立，但是还没有发送（还没有调用 send()）。
·2：请求已发送，正在处理中（通常现在可以从响应中获取内容头）。
·3：请求在处理中；通常响应中已有部分数据可用了，但是服务器还没有完成响应的生成。
·4：响应已完成；您可以获取并使用服务器的响应了。
如果您希望不仅仅是了解 Ajax 编程的基本知识，那么就不但需要知道这些状态，了解这些状态是何时出现的，以及如何来使用这些状态。首先，您需要学习在每种就绪状态下可能碰到的是哪种请求状态。不幸的是，这一点并不直观，而且会涉及几种特殊的情况。
隐秘就绪状态
第一种就绪状态的特点是 readyState 属性为 0（readyState == 0），表示未初始化状态。一旦对请求对象调用 open() 之后，这个属性就被设置为 1。由于您通常都是在一对请求进行初始化之后就立即调用 open()，因此很少会看到 readyState == 0 的状态。另外，未初始化的就绪状态在实际的应用程序中是没有真正的用处的。
不过为了满足我们的兴趣，请参见 清单 2 的内容，其中显示了如何在 readyState 被设置为 0 时来获取这种就绪状态。
清单 2. 获取 0 就绪状态
function getSalesData() {
// Create a request object
createRequest();
alert("Ready state is: " + request.readyState);
// Setup (initialize) the request
var url = "/boards/servlet/UpdateBoardSales";
request.open("GET", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}
在这个简单的例子中，getSalesData() 是 Web 页面调用来启动请求（例如点击一个按钮时）所使用的函数。注意您必须在调用 open()之前 来查看就绪状态。图 1 给出了运行这个应用程序的结果。
图 1. 就绪状态 0
显然，这并不能为您带来多少好处；需要确保 尚未 调用 open() 函数的情况很少。在大部分 Ajax 编程的真实情况中，这种就绪状态的唯一用法就是使用相同的 XMLHttpRequest 对象在多个函数之间生成多个请求。在这种（不常见的）情况中，您可能会在生成新请求之前希望确保请求对象是处于未初始化状态（readyState == 0）。这实际上是要确保另外一个函数没有同时使用这个对象。
查看正在处理的请求的就绪状态
除了 0 就绪状态之外，请求对象还需要依次经历典型的请求和响应的其他几种就绪状态，最后才以就绪状态 4 的形式结束。这就是为什么您在大部分回调函数中都可以看到 if (request.readyState == 4) 这行代码；它确保服务器已经完成对请求的处理，现在可以安全地更新 Web 页面或根据从服务器返回来的数据来进行操作了。
要查看这种状态发生的过程非常简单。如果就绪状态为 4，我们不仅要运行回调函数中的代码，而且还要在每次调用回调函数时都输出就绪状态。 清单 3 给出了一个实现这种功能的例子。
当 0 等于 4 时
在多个 JavaScript 函数都使用相同的请求对象时，您需要检查就绪状态 0 来确保这个请求对象没有正在使用，这种机制会产生问题。由于 readyState == 4 表示一个已完成的请求，因此您经常会发现那些目前没在使用的处于就绪状态的请求对象仍然被设置成了 4 —— 这是因为从服务器返回来的数据已经使用过了，但是从它们被设置为就绪状态之后就没有进行任何变化。有一个函数 abort() 会重新设置请求对象，但是这个函数却不是真正为了这个目的而使用的。如果您 必须 使用多个函数，最好是为每个函数都创建并使用一个函数，而不是在多个函数之间共享相同的对象。
您会看到就绪状态为 3 的响应在每个脚本、每个服务器甚至每个浏览器上都是不一样的。不过，这在调试应用程序中依然是非常有用的。
获取安全数据
所有的文档和规范都强调，只有在就绪状态为 4 时数据才可以安全使用。相信我，当就绪状态为 3 时，您很少能找到无法从 responseText 属性获取数据的情况。然而，在应用程序中将自己的逻辑依赖于就绪状态 3 可不是什么好主意 —— 一旦您编写了依赖于就绪状态 3 的完整数据的的代码，几乎就要自己来负责当时的数据不完整问题了。
比较好的做法是向用户提供一些反馈，说明在处于就绪状态 3 时，很快就会有响应了。尽管使用 alert() 之类的函数显然不是什么好主意 —— 使用 Ajax 然后使用一个警告对话框来阻塞用户显然是错误的 —— 不过您可以在就绪状态发生变化时更新表单或页面中的域。例如，对于就绪状态 1 来说要将进度指示器的宽度设置为 25%，对于就绪状态 2 来说要将进度指示器的宽度设置为 50%，对于就绪状态 3 来说要将进度指示器的宽度设置为 75%，当就绪状态为 4 时将进度指示器的宽度设置为 100%（完成）。
当然，正如您已经看到的一样，这种方法非常聪明，但它是依赖于浏览器的。在 Opera 上，您永远都不会看到前两个就绪状态，而在 Safari 上则没有第一个（1）。由于这个原因，我将这段代码留作练习，而没有在本文中包括进来。
现在应该来看一下状态代码了。
深入了解 HTTP 状态代码
有了就绪状态和您在 Ajax 编程技术中学习到的服务器的响应，您就可以为 Ajax 应用程序添加另外一级复杂性了 —— 这要使用 HTTP 状态代码。这些代码对于 Ajax 来说并没有什么新鲜。从 Web 出现以来，它们就已经存在了。在 Web 浏览器中您可能已经看到过几个状态代码：
·401：未经授权
·403：禁止
·404：没找到
您可以找到更多的状态代码（完整清单请参见 参考资料）。要为 Ajax 应用程序另外添加一层控制和响应（以及更为健壮的错误处理）机制，您需要适当地查看请求和响应中的状态代码。
200：一切正常
在很多 Ajax 应用程序中，您将看到一个回调函数，它负责检查就绪状态，然后继续利用从服务器响应中返回的数据，如 清单 6 所示。
清单 9. 使用 Ajax 生成一个 HEAD 请求
function getSalesData() {
createRequest();
var url = "/boards/servlet/UpdateBoardSales";
request.open("HEAD", url, true);
request.onreadystatechange = updatePage;
request.send(null);
}
当您这样生成一个 HEAD 请求时，服务器并不会像对 GET 或 POST 请求一样返回一个真正的响应。相反，服务器只会返回资源的 头（header），这包括响应中内容最后修改的时间、请求资源是否存在和很多其他有用信息。您可以在服务器处理并返回资源之前使用这些信息来了解有关资源的信息。
对于这种请求您可以做的最简单的事情就是简单地输出所有的响应头的内容。这可以让您了解通过 HEAD 请求可以使用什么。清单 10 提供了一个简单的回调函数，用来输出从 HEAD 请求中获得的响应头的内容。
清单 10. 输出从 HEAD 请求中获得的响应头的内容
function updatePage() {
if (request.readyState == 4) {
alert(request.getAllResponseHeaders());
}
}
请参见 图 7，其中显示了从一个向服务器发出的 HEAD 请求的简单 Ajax 应用程序返回的响应头。
您可以单独使用这些头（从服务器类型到内容类型）在 Ajax 应用程序中提供其他信息或功能。
检查 URL
您已经看到了当 URL 不存在时应该如何检查 404 错误。如果这变成一个常见的问题 —— 可能是缺少了一个特定的脚本或 servlet —— 那么您就可能会希望在生成完整的 GET 或 POST 请求之前来检查这个 URL。要实现这种功能，生成一个 HEAD 请求，然后在回调函数中检查 404 错误；清单 11 给出了一个简单的回调函数。
清单 11. 检查某个 URL 是否存在
function updatePage() {
if (request.readyState == 4) {
if (request.status == 200) {
alert("URL exists");
} else if (request.status == 404) {
alert("URL does not exist.");
} else {
alert("Status is: " + request.status);
}
}
}
诚实地说，这段代码的价值并不太大。服务器必须对请求进行响应，并构造一个响应来填充内容长度的响应头，因此并不能节省任何处理时间。另外，这花费的时间与生成请求并使用 HEAD 请求来查看 URL 是否存在所需要的时间一样多，因为它要生成使用 GET 或 POST 的请求，而不仅仅是如 清单 7 所示一样来处理错误代码。不过，有时确切地了解目前什么可用也是非常有用的；您永远不会知道何时创造力就会迸发或者何时需要 HEAD 请求！
有用的 HEAD 请求
您会发现 HEAD 请求非常有用的一个领域是用来查看内容的长度或内容的类型。这样可以确定是否需要发回大量数据来处理请求，和服务器是否试图返回二进制数据，而不是 HTML、文本或 XML（在 JavaScript 中，这 3 种类型的数据都比二进制数据更容易处理）。
在这些情况中，您只使用了适当的头名，并将其传递给 XMLHttpRequest 对象的 getResponseHeader() 方法。因此要获取响应的长度，只需要调用 request.getResponseHeader("Content-Length");。要获取内容类型，请使用 request.getResponseHeader("Content-Type");。
在很多应用程序中，生成 HEAD 请求并没有增加任何功能，甚至可能会导致请求速度变慢（通过强制生成一个 HEAD 请求来获取有关响应的数据，然后在使用一个 GET 或 POST 请求来真正获取响应）。然而，在出现您不确定有关脚本或服务器端组件的情况时，使用 HEAD 请求可以获取一些基本的数据，而不需要对响应数据真正进行处理，也不需要大量的带宽来发送响应。
结束语
对于很多 Ajax 和 Web 程序员来说，本文中介绍的内容似乎是太高级了。生成 HEAD 请求的价值是什么呢？到底在什么情况下需要在 JavaScript 中显式地处理重定向状态代码呢？这些都是很好的问题；对于简单的应用程序来说，答案是这些高级技术的价值并不是非常大。
然而，Web 已经不再是只需实现简单应用程序的地方了；用户已经变得更加高级，客户期望能够获得更好的稳定性、更高级的错误报告，如果应用程序有 1% 的时间停机，那么经理就可能会因此而被解雇。
因此您的工作就不能仅仅局限于简单的应用程序了，而是需要更深入理解 XMLHttpRequest。
·如果您可以考虑各种就绪状态 —— 并且理解了这些就绪状态在不同浏览器之间的区别 —— 就可以快速调试应用程序了。您甚至可以基于就绪状态而开发一些创造性的功能，并向用户和客户回报请求的状态。
·如果您要对状态代码进行控制，就可以设置应用程序来处理脚本错误、非预期的响应以及边缘情况。结果是应用程序在所有的时间都可以正常工作，而不仅仅是只能一切都正常的情况下才能运行。
·增加这种生成 HEAD 请求的能力，检查某个 URL 是否存在，以及确认某个文件是否被修改过，这样就可以确保用户可以获得有效的页面，用户所看到的信息都是最新的，（最重要的是）让他们惊讶这个应用程序是如何健壮和通用。
本文的目的并非是要让您的应用程序显得十分华丽，而是帮助您去掉黄色聚光灯后重点昭显文字的美丽，或者外观更像桌面一样。尽管这些都是 Ajax 的功能（在后续几篇文章中就会介绍），不过它们却像是蛋糕表面的一层奶油。如果您可以使用 Ajax 来构建一个坚实的基础，让应用程序可以很好地处理错误和问题，用户就会返回您的站点和应用程序。在接下来的文章中，我们将添加这种直观的技巧，这会让客户兴奋得发抖。
程序员（使用后端应用程序）和 Web 程序员（编写 HTML、CSS 和 JavaScript）之间的分水岭是长久存在的。但是，Document Object Model (DOM) 弥补了这个裂缝，使得在后端使用 XML 同时在前端使用 HTML 切实可行，并成为极其有效的工具。在本文中，Brett McLaughlin 介绍了 Document Object Model，解释它在 Web 页面中的应用，并开始挖掘其在 JavaScript 中的用途。
与许多 Web 程序员一样，您可能使用过 HTML。HTML 是程序员开始与 Web 页面打交道的方式；HTML 通常是他们完成应用程序或站点前的最后一步——调整一些布局、颜色或样式。不过，虽然经常使用 HTML，但对于 HTML 转到浏览器呈现在屏幕上时到底发生了什么，人们普遍存在误解。在我分析您认为可能发生的事情及其可能错误的原因之前，我希望您对设计和服务 Web 页面时涉及的过程一清二楚：
1、一些人（通常是您！）在文本编辑器或 IDE 中创建 HTML。
2、然后您将 HTML 上载到 Web 服务器，例如 Apache HTTPD，并将其公开在 Internet 或 intranet 上。
3、用户用 Firefox 或 SafariA 等浏览器请求您的 Web 页面。
4、用户的浏览器向您的服务器请求 HTML。
5、浏览器将从服务器接收到的页面以图形和文本方式呈现；用户看到并激活 Web 页面。
这看起来非常基础，但事情很快会变得有趣起来。事实上，步骤 4 和步骤 5 之间发生的巨大数量的 “填充物（stuff）” 就是本文的焦点。术语 “填充物” 也十分适用，因为多数程序员从来没有真正考虑过当用户浏览器请求显示标记时到底在标记身上发生了什么。
·是否浏览器只是读取 HTML 中的文本并将其显示？
·CSS 呢？尤其是当 CSS 位于外部文件时。
·JavaScript 呢？它也通常位于外部文件中。
·浏览器如何处理这些项，如果将事件处理程序、函数和样式映射到该文本标记？
实践证明，所有这些问题的答案都是 Document Object Model。因此，废话少说，直接研究 DOM。
Web 程序员和标记
对于多数程序员，当 Web 浏览器开始时他们的工作就结束了。也就是说，将一个 HTML 文件放入 Web 浏览器的目录上后，您通常就认为它已经“完成”，而且（满怀希望地）认为再也不会考虑它！说到编写干净、组织良好的页面时，这也是一个伟大的目标；希望您的标记跨浏览器、用各种版本的 CSS 和 JavaScript 显示它应该显示的内容，一点错都没有。
问题是这种方法限制了程序员对浏览器中真正发生的事情的理解。更重要的是，它限制了您用客户端 JavaScript 动态更新、更改和重构 Web 页面的能力。摆脱这种限制，让您的 Web 站点拥有更大的交互性和创造性。
程序员做什么
作为典型的 Web 程序员，您可能启动文本编辑和 IDE 后就开始输入 HTML、CSS 甚至 JavaScript。很容易认为这些标记、选择器和属性只是使站点正确显示而做的小小的任务。但是，在这一点上您需要拓展您的思路，要意识到您是在组织您的内容。不要担心；我保证这不会变成关于标记美观、您必须如何认识到 Web 页面的真正潜力或其他任何元物质的讲座。您需要了解的是您在 Web 开发中到底是什么角色。
说到页面的外观，顶多您只能提提建议。您提供 CSS 样式表时，用户可以覆盖您的样式选择。您提供字体大小时，用户浏览器可以为视障者更改这些大小，或者在大显示器（具有同等大的分辨率）上按比例缩小。甚至您选择的颜色和字体也受制于用户显示器和用户在其系统上安装的字体。虽然尽您所能来设计页面样式很不错，但这绝不是 您对 Web 页面的最大影响。
您绝对控制的是 Web 页面的结构。您的标记不可更改，用户就不能乱弄；他们的浏览器只能从您的 Web 服务器检索标记并显示它（虽然样式更符合用户的品味而不是您自己的品味）。但页面组织，不管是在该段落内还是在其他分区，都只由您单独决定。要是想实际更改您的页面（这是大多数 Ajax 应用程序所关注的），您操作的是页面的结构。尽管很容易更改一段文本的颜色，但在现有页面上添加文本或整个区段要难得多。不管用户如何设计该区段的样式，都是由您控制页面本身的组织。
标记做什么
一旦意识到您的标记是真正与组织相关的，您就会对它另眼相看了。不会认为 h1 导致文本是大字号、黑色、粗体的，而会认为 h1 是标题。用户如何看待这个问题以及他们是使用您的 CSS、他们自己的 CSS 还是这两者的组合，这是次要的考虑事项。相反，要意识到只有标记才能提供这种级别的组织；p 指明文本在段落内，img 表示图像，div 将页面分成区段，等等。
还应该清楚，样式和行为（事件处理程序和 JavaScript）是在事后 应用于该组织的。标记就绪以后才能对其进行操作或设计样式。所以，正如您可以将 CSS 保存在 HTML 的外部文件中一样，标记的组织与其样式、格式和行为是分离的。虽然您肯定可以用 JavaScript 更改元素或文本的样式，但实际更改您的标记所布置的组织却更加有趣。
只要牢记您的标记只为您的页面提供组织、框架，您就能立于不败之地。再前进一小步，您就会明白浏览器是如何接受所有的文本组织并将其转变为超级有趣的一些东西的，即一组对象，其中每个对象都可被更改、添加或删除。
文本标记的优点
在讨论 Web 浏览器之前，值得考虑一下为什么纯文本绝对 是存储 HTML 的最佳选择（有关详细信息，请参阅 有关标记的一些其他想法）。不考虑优缺点，只是回忆一下在每次查看页面时 HTML 是通过网络发送到 Web 浏览器的（为了简洁，不考虑高速缓存等）。真是再没有比传递文本再有效的方法了。二进制对象、页面图形表示、重新组织的标记块等等，所有这一切都比纯文本文件通过网络传递要更困难。
此外，浏览器也为此增光添彩。今天的浏览器允许用户更改文本大小、按比例伸缩图像、下载页面的 CSS 或 JavaScript（大多数情况），甚至更多，这完全排除了将任何类型的页面图形表示发送到浏览器上。但是，浏览器需要原 HTML，这样它才能在浏览器中对页面应用任何处理，而不是信任浏览器去处理该任务。同样地，将 CSS 从 JavaScript 分离和将 CSS 从 HTML 标记分离要求一种容易分离的格式。文本文件又一次成为该任务的最好方法。
最后但同样重要的一点是，记住，新标准（比如 HTML 4.01 与 XHTML 1.0 和 1.1）承诺将内容（页面中的数据）与表示和样式（通常由 CSS 应用）分离。如果程序员要将 HTML 与 CSS 分离，然后强制浏览器检索粘结页面各部分的一些页面表示，这会失去这些标准的多数优点。保持这些部分到达浏览器时都一直分离使得浏览器在从服务器获取 HTML 时有了前所未有的灵活性。
关于标记的其他想法
纯文本编辑：是对是错？
纯文本是存储标记的理想选择，但是不适合编辑 标记。大行其道的是使用 IDE，比如 Macromedia DreamWeaver 或更强势点的 Microsoft® FrontPage®，来操作 Web 页面标记。这些环境通常提供快捷方式和帮助来创建 Web 页面，尤其是在使用 CSS 和 JavaScript 时，二者都来自实际页面标记以外的文件。许多人仍偏爱好用古老的记事本或 vi（我承认我也是其中一员），这并不要紧。不管怎样，最终结果都是充满标记的文本文件。
网络上的文本：好东西
</div>
</body>
</html>