开博第一篇

      申请CSDN时间不短了，但是从来没有在这了写过文章，现在来一篇，主要涉及两个内容：GBK、GB2312等编码问题，以及在图书馆看到了一些不太了解的技术……好，现在开始了，O(∩_∩)O哈哈~

 

1. GBK和GB2312的编码问题

     GBK是一个汉字编码标准，全称《汉字内码扩展规范》,于1995 年制定。

 

     GB2312是1980年国家制定的汉字内码规范。GBK标准中收录了2万多汉字及符号，因其最早被WINDOWS采用，所以其应用范围非常广GB2312中收录了6千多汉字及符号，通常所说的一、二级汉字库就全部包含在GB2312中。虽然GB2312包含了绝大部分的常用简体汉字，但是由于中文的复杂性，所以GB2312目前已经越来越不能适应需要了，特别是因为人名、地名中包含的很多字GB2312中都没有，如朱镕基的‘镕’字，GB2312中就没有包含，这样导致很多混乱。正因为GB2312的这些问题，国家标准化委员会又制定了GB13000，GB13000制定的原则与GB2312不同，GB13000以国际化为目标， 该标准编码参照了Unicode 2.0 标准编码，与GB2312完全不兼容，因早期的计算机中的汉卡采用了GB2312，无法顺利向GB13000过渡，所以GB13000变成了一个纸面上的 标准，无法推广。

 

     有了以上经验，国家标准化委员会制定了GBK标准，他兼容GB2312标准，同时在GB2312标准的基础上扩展了GB13000包含的字，但编码修改 了，该标准一经推出，就被WINDOWS95所采用（另一种说法是微软协助制定了此标准，这也可以印证为什么GBK标准一直没有出现在官方的标准目录 中）。因有微软的支持，该标准迅速得到广泛的应用。GBK之后又有GB18030标准，因GB18030较GBK又多了几千汉字，码位不足，GB18030使用了2byte与4byte混合编码方式，这又给软件增加了难题，所以虽然GB18030推出了近5年，仍然没有得到广泛应用。(此部分为转载内容)

 

1.1GB2312

      GB2312 是基于区位码设计的，区位码把编码表分为94个区，每个区对应94个位，每个字符的区号和位号组合起来就是该汉字的区位码。区位码一般 用10进制数来表示，如1601就表示16区1位，对应的字符是“啊”。在区位码的区号和位号上分别加上0xA0就得到了GB2312编码。

每一种语言的不同的编码页，增加了那些需要支持不同语言的软件的复杂度。因而人们制定了一个世界标准，叫做unicode。unicode为每个字符提供 了唯一的特定数值，不论在什么平台上、不论在什么软件中，也不论什么语言。也就是说，它世界上使用的所有字符都列出来，并给每一个字符一个唯一特定数值。
      Unicode的最初目标，是用1个16位的编码来为超过65000字符提供映射。但这还不够，它不能覆盖全部历史上的文字，也不能解决传输的问题 (implantation head-ache's)，尤其在那些基于网络的应用中。已有的软件必须做大量的工作来程序16位的数据。
      因此，Unicode用一些基本的保留字符制定了三套编码方式。它们分别是UTF-8,UTF-16和UTF-32。正如名字所示，在UTF－8中，字符是 以8位序列来编码的，用一个或几个字节来表示一个字符。这种方式的最大好处，是UTF－8保留了ASCII字符的编码做为它的一部分，例如，在UTF－8 和ASCII中，“A”的编码都是0x41.
      UTF－16和UTF－32分别是Unicode的16位和32位编码方式。考虑到最初的目的，通常说的Unicode就是指UTF-16。在讨论Unicode时，搞清楚哪种编码方式非常重要。

 

      区位码中01-09区是符号、数字区，16-87区是汉字区，10-15和88-94是未定义的空白区。它将收录的汉字分成两级：第一级是常用汉字计 3755个，置于16-55区，按汉语拼音字母/笔形顺序排列；第二级汉字是次常用汉字计3008个，置于56-87区，按部首/笔画顺序排列。一级汉字 是按照拼音排序的，这个就可以得到某个拼音在一级汉字区位中的范围，很多根据汉字可以得到拼音的程序就是根据这个原理编写的。

 

      GB2312字符集中除常用简体汉字字符外还包括希腊字母、日文平假名及片假名字母、俄语西里尔字母等字符，未收录繁体中文汉字和一些生僻字。可以用繁体汉字测试某些系统是不是只支持GB2312编码。

 

      GB2312的编码范围是0xA1A1-0x7E7E，去掉未定义的区域之后可以理解为实际编码范围是0xA1A1-0xF7FE。

      EUC-CN可以理解为GB2312的别名，和GB2312完全相同。

 

      区位码更应该认为是字符集的定义，定义了所收录的字符和字符位置，而GB2312及EUC-CN是实际计算机环境中支持这种字符集的编码。HZ和ISO-2022-CN是对应区位码字符集的另外两种编码，都是用7位编码空间来支持汉字。区位码和GB2312编码的关系有点像 Unicode和UTF-8。

 

1.2 GBK

      GBK 编码是GB2312编码的超集，向下完全兼容GB2312，同时GBK收录了Unicode基本多文种平面中的所有CJK汉字。同 GB2312一样，GBK也支持希腊字母、日文假名字母、俄语字母等字符，但不支持韩语中的表音字符（非汉字字符）。GBK还收录了GB2312不包含的 汉字部首符号、竖排标点符号等字符。

 

      GBK的整体编码范围是为0x8140-0xFEFE，不包括低字节是0×7F的组合。高字节范围是0×81-0xFE，低字节范围是0x40-7E和0x80-0xFE。

 

      低字节是0x40-0x7E的GBK字符有一定特殊性，因为这些字符占用了ASCII码的位置，这样会给一些系统带来麻烦。

      有些系统中用0x40-0x7E中的字符（如“|”）做特殊符号，在定位这些符号时又没有判断这些符号是不是属于某个 GBK字符的低字节，这样就会造成错误判断。在支持GB2312的环境下就不存在这个问题。需要注意的是支持GBK的环境中小于0x80的某个字节未必就 是ASCII符号；另外就是最好选用小于0×40的ASCII符号做一些特殊符号，这样就可以快速定位，且不用担心是某个汉字的另一半。Big5编码中也 存在相应问题。

 

       CP936和GBK的有些许差别，绝大多数情况下可以把CP936当作GBK的别名。

 

1.3  GB18030

      GB18030编码向下兼容GBK和GB2312，兼容的含义是不仅字符兼容，而且相同字符的编码也相同。GB18030收录了所有Unicode3.1中的字符，包括中国少数民族字符，GBK不支持的韩文字符等等，也可以说是世界大多民族的文字符号都被收录在内。

 

      GBK和GB2312都是双字节等宽编码，如果算上和ASCII兼容所支持的单字节，也可以理解为是单字节和双字节混合的变长编码。GB18030编码是变长编码，有单字节、双字节和四字节三种方式。

GB18030 的单字节编码范围是0x00-0x7F，完全等同与ASCII；双字节编码的范围和GBK相同，高字节是0x81-0xFE，低字节的编码范围是0x40 -0x7E和0x80-FE；四字节编码中第一、三字节的编码范围是0x81-0xFE，二、四字节是0x30-0x39。

 

      Windows 中CP936代码页使用0x80来表示欧元符号，而在GB18030编码中没有使用0x80编码位，用其他位置来表示欧元符号。这可以理解为是 GB18030向下兼容性上的一点小问题；也可以理解为0x80是CP936对GBK的扩展，而GB18030只是和GBK兼容良好。

2. UTF编码

 

 

 

 

2.1 UTF-8

    UTF-8就是以8位为单元对UCS进行编码。从UCS-2到UTF-8的编码方式如下：

UCS-2编码(16进制) UTF-8 字节流(二进制)
0000 - 007F 0xxxxxxx
0080 - 07FF 110xxxxx 10xxxxxx
0800 - FFFF 1110xxxx 10xxxxxx 10xxxxxx

     例如“汉”字的Unicode编码是6C49。6C49在0800-FFFF之间，所以肯定要用3字节模板了：1110xxxx 10xxxxxx 10xxxxxx。将6C49写成二进制是：0110 110001 001001，用这个比特流依次代替模板中的x，得到：11100110 10110001 10001001，即E6 B1 89。

     读者可以用记事本测试一下我们的编码是否正确。需要注意，UltraEdit在打开utf-8编码的文本文件时会自动转换为UTF-16，可能产生混淆。你可以在设置中关掉这个选项。更好的工具是Hex Workshop。

2.2 UTF-16

     UTF-8以字节为编码单元，没有字节序的问题。UTF-16以两个字节为编码单元，在解释一个UTF-16文本前，首先要弄清楚每个编码单元的字节序。例如“奎”的Unicode编码是594E，“乙”的Unicode编码是4E59。如果我们收到UTF-16字节流“594E”，那么这是“奎”还是“乙”？

     UTF-16以16位为单元对UCS进行编码。对于小于0x10000的UCS码，UTF-16编码就等于UCS码对应的16位无符号整数。对于不小于0x10000的UCS码，定义了一个算法。不过由于实际使用的UCS2，或者UCS4的BMP必然小于0x10000，所以就目前而言，可以认为UTF-16和UCS-2基本相同。但UCS-2只是一个编码方案，UTF-16却要用于实际的传输，所以就不得不考虑字节序的问题。

2.3 UTF的字节序和BOM

 

     Unicode规范中推荐的标记字节顺序的方法是BOM。BOM不是“Bill Of Material”的BOM表，而是Byte order Mark。BOM是一个有点小聪明的想法：

     在UCS编码中有一个叫做"ZERO WIDTH NO-BREAK SPACE"的字符，它的编码是FEFF。而FFFE在UCS中是不存在的字符，所以不应该出现在实际传输中。UCS规范建议我们在传输字节流前，先传输字符"ZERO WIDTH NO-BREAK SPACE"。

     这样如果接收者收到FEFF，就表明这个字节流是Big-Endian的；如果收到FFFE，就表明这个字节流是Little-Endian的。因此字符"ZERO WIDTH NO-BREAK SPACE"又被称作BOM。

     UTF-8不需要BOM来表明字节顺序，但可以用BOM来表明编码方式。字符"ZERO WIDTH NO-BREAK SPACE"的UTF-8编码是EF BB BF（读者可以用我们前面介绍的编码方法验证一下）。所以如果接收者收到以EF BB BF开头的字节流，就知道这是UTF-8编码了。

Windows就是使用BOM来标记文本文件的编码方式的。

 

3. 几个不太了解的技术

3.1 Erlang

      Erlang并非一门新语言，它出现于1987年，只是当时对并发、分布式需求还没有今天这么普遍，当时可谓英雄无用武之地。Erlang语言创始人Joe Armstrong当年在爱立信做电话网络方面的开发，他使用Smalltalk，可惜那个时候Smalltalk太慢，不能满足电话网络的高性能要求。但Joe实在喜欢Smalltalk，于是定购了一台Tektronix Smalltak机器。但机器要两个月时间才到，Joe在等待中百无聊赖，就开始使用Prolog，结果等Tektronix到来的时候，他已经对Prolog更感兴趣，Joe当然不满足于精通Prolog，经过一段时间的试验，Joe给Prolog加上了并发处理和错误恢复，于是Erlang就诞生了。这也是为什么Erlang的语法和Prolog有不少相似之处，比如它们的List表达都是[Head | Tail]。

　　1987年Erlang测试版推出，并在用户实际应用中不断完善，于1991年向用户推出第一个版本，带有了编译器和图形接口等更多功能。1992年，Erlang迎来更多用户，如RACE项目等。同期Erlang被移植到VxWorks、PC和 Macintosh等多种平台，两个使用Erlang的产品项目也开始启动。1993爱立信公司内部独立的组织开始维护和支持Erlang实现和Erlang工具。

　　目前，随着网络应用的兴起，对高并发、分布部署、持续服务的需求增多，Erlang的特性刚好满足这些需求，于是Erlang开始得到更多人的关注

　　Erlang是一个结构化，动态类型编程语言，内建并行计算支持。最初是由爱立信专门为通信应用设计的，比如控制交换机或者变换协议等，因此非常适合于构建分布式，实时软并行计算系统。

　　使用Erlang编写出的应用运行时通常由成千上万个轻量级进程组成，并通过消息传递相互通讯。进程间上下文切换对于Erlang来说仅仅只是一两个环节，比起C程序的线程切换要高效得多得多了。

　　使用Erlang来编写分布式应用要简单的多，因为它的分布式机制是透明的：对于程序来说并不知道自己是在分布式运行。

　　Erlang运行时环境是一个虚拟机，有点像Java虚拟机，这样代码一经编译，同样可以随处运行。它的运行时系统甚至允许代码在不被中断的情况下更新。另外如果你需要更高效的话，字节代码也可以编译成本地代码运行。

　　Erlang特性：

　　● 并发性 - Erlang支持超大量级的并发线程，并且不需要操作系统具有并发机制。

　　● 分布式 - 一个分布式Erlang系统是多个Erlang节点组成的网络（通常每个处理器被作为一个节点）

　　● 健壮性 - Erlang具有多种基本的错误检测能力，它们能够用于构建容错系统。

　　● 软实时性- Erlang支持可编程的“软”实时系统，使用了递增式垃圾收集技术。

　　● 热代码升级-Erlang允许程序代码在运行系统中被修改。旧代码能被逐步淘汰而后被新代码替换。在此过渡期间，新旧代码是共存的。

　　●递增式代码装载-用户能够控制代码如何被装载的细节。

　　●外部接口-Erlang进程与外部世界之间的通讯使用和在Erlang进程之间相同的消息传送机制。

　　《Erlang 程序设计》主要涵盖顺序型编程、异常处理、编译和运行代码、并发编程、并发编程中的错误处理、分布式编程、多核编程等内容。本书将帮助读者在消息传递的基础上构建分布式的并发系统，免去锁与互斥技术的羁绊，使程序在多核CPU 上高效运行。本书讲述的各种设计方法和行为将成为为设计容错与分布式系统中的利器。（载自百度百科）

3.2 JRuby

      JRuby是一个纯Java实现的Ruby解释器。通过JRuby，你可以在JVM上直接运行Ruby程序，调用Java的类库。很多Java编写的Ruby IDE都是使用JRuby来解释语法的。 2006年，SUN雇佣了两名JRuby团队的两名核心成员Charles Nutter和Thomas Enebo全职开发JRuby，后来ThoughtWorks也雇佣了一名JRuby项目的核心成员全职开发JRuby。

　　自此JRuby发展非常迅速，立刻推出一个50%性能提升的版本。最近又发布了0.9.8版，正式宣布官方支持Rails，单元测试有98%成功通过（也是因此称作0.9.8版？），现在开发小组全力修复剩下的2%，将会很快发布100%支持Rails的JRuby 1.0。但是目前JRuby的主要精力集中在功能实现上，性能还不如理想，1.0发布之后应该就会全力解决性能问题。

　　JRuby 1.0已经来了，可以在JVM上面运行Rails，你还等什么。（载自百度百科）

 

3.3 jQuery

jQuery由美国人John Resig创建，至今已吸引了来自世界各地的众多javascript高手加入其team，包括来自德国的Jörn Zaefferer，罗马尼亚的Stefan Petre等等。

　　jQuery是继prototype之后又一个优秀的Javascrīpt框架。其宗旨是——WRITE LESS,DO MORE,写更少的代码,做更多的事情。

　　它是轻量级的js库(压缩后只有21k) ，这是其它的js库所不及的，它兼容CSS3，还兼容各种浏览器 （IE 6.0+, FF 1.5+, Safari 2.0+, Opera 9.0+）。

　　jQuery是一个快速的，简洁的javaScript库，使用户能更方便地处理HTML documents、events、实现动画效果，并且方便地为网站提供AJAX交互。

　　jQuery还有一个比较大的优势是，它的文档说明很全，而且各种应用也说得很详细，同时还有许多成熟的插件可供选择。

　　jQuery能够使用户的html页保持代码和html内容分离，也就是说，不用再在html里面插入一堆js来调用命令了，只需定义id即可。

　　Jquery是继prototype之后又一个优秀的Javascrīpt框架。对prototype我使用不多，简单了解过。但使用上jquery之后，马上被她的优雅吸引住了。有人使用这样的一比喻来比较prototype和jquery：prototype就像Java，而jquery就像ruby.实际上我比较喜欢java（少接触Ruby 罢了）但是jquery的简单的实用的确有相当大的吸引力啊！在项目里我把jquery作为自己唯一的框架类包。使用其间也有一点点心得，其实这些心得，在jquery的文档上面也可能有讲，不过还是记下来，以备忘罢。

 

3.4 AJAX

读音：[e:j^ks] 。AJAX即“Asynchronous JavaScript and XML”（异步JavaScript和XML)，AJAX并非缩写词，而是由Jesse James Gaiiett创造的名词，是指一种创建交互式网页应用的网页开发技术。 国内通常的读音为“阿贾克斯”和阿贾克斯足球队读音一样。Web应用的交互如Flickr, Backpack和Google在这方面已经有质的飞跃。这个术语源自描述从基于网页的Web应用到基于数据的应用的转换。在基于数据的应用中，用户需求的数据如联系人列表，可以从独立于实际网页的服务端取得并且可以被动态地写入网页中，给缓慢的Web应用体验着色使之像桌面应用一样。 虽然大部分开发人员在过去使用过XMLHttp或者使用Iframe来加载数据，但仅到现在我们才看到传统的开发人员和公司开始采用这些技术。就像新的编程语言或模型伴随着更多的痛苦，开发人员需要学习新的技巧及如何最好利用这些新技术。

　　AJAX模式

　　许多重要的技术和AJAX开发模式可以从现有的知识中获取。例如，在一个发送请求到服务端的应用中，必须包含请求顺序、优先级、超时响应、错误处理及回调，其中许多元素已经在Web服务中包含了，就像现在的SOA。AJAX开发人员拥有一个完整的系统架构知识。同时，随着技术的成熟还会有许多地方需要改进，特别是UI部分的易用性。

　　AJAX开发与传统的CS开发有很大的不同。这些不同引入了新的编程问题，最大的问题在于易用性。由于AJAX依赖浏览器的JavaScript和XML，浏览器的兼容性和支持的标准也变得和JavaScript的运行时性能一样重要了。这些问题中的大部分来源于浏览器、服务器和技术的组合，因此必须理解如何才能最好的使用这些技术。

　　综合各种变化的技术和强耦合的客户服务端环境，AJAX提出了一种新的开发方式。AJAX开发人员必须理解传统的MVC架构，这限制了应用层次之间的边界。同时，开发人员还需要考虑CS环境的外部和使用AJAX技术来重定型MVC边界。最重要的是，AJAX开发人员必须禁止以页面集合的方式来考虑Web应用而需要将其认为是单个页面。一旦UI设计与服务架构之间的范围被严格区分开来后，开发人员就需要更新和变化的技术集合了。

　　时刻想着用户

　　AJAX的最大机遇在于用户体验。在使应用更快响应和创新的过程中，定义Web应用的规则正在被重写;因此开发人员必须更注重用户。现在用户已经逐渐习惯如何使用Web应用了。例如用户通常希望每一次按钮点击会导致几秒的延迟和屏幕刷新，但AJAX正在打破这种长时间的状况。因此用户需要重新体验按钮点击的响应了。

　　可用性是AJAX令人激动的地方而且已经产生了几种新颖的技术。其中最引人注目的是一种称为“黄色隐出”的技术，他在数据更新之前时将用户界面变为黄色，更新完成后立刻恢复原来的颜色。AJAX开发人员将用户从Web应用的负载中解放出来;小心地利用AJAX提供的丰富接口，不久桌面开发人员会发现AJAX是他们的方向。

　　几种工具和技术

　　随着AJAX迅速地引人注目起来，我想开发人员对这种技术的期待也迅速地增加。就像任何新技术，AJAX的兴旺也需要一整个开发工具/编程语言及相关技术系统来支撑。

　　JavaScript

　　如名字所示AJAX的概念中最重要而最被忽视的是他也是一种JavaScript编程语言。JavaScript是一种粘合剂使AJAX应用的各部分集成在一起。在大部分时间，JavaScript通常被服务端开发人员认为是一种企业级应用不需要使用的东西应该尽力避免。这种观点来来自以前编写JavaScript代码的经历:繁杂而又易出错的语言。类似的，他也被认为将应用逻辑任意地散布在服务端和客户端中，这使得问题很难被发现而且代码很难重用。在AJAX中JavaScript主要被用来传递用户界面上的数据到服务端并返回结果。XMLHttpRequest对象用来响应通过HTTP传递的数据，一旦数据返回到客户端就可以立刻使用DOM将数据放到网面上。

　　XMLHttpRequest

　　XMLHttpRequest对象在大部分浏览器上已经实现而且拥有一个简单的接口允许数据从客户端传递到服务端，但并不会打断用户当前的操作。使用XMLHttpRequest传送的数据可以是任何格式，虽然从名字上建议是XML格式的数据。

　　开发人员应该已经熟悉了许多其他XML相关的技术。XPath可以访问XML文档中的数据，但理解XML DOM是必须的。类似的，XSLT是最简单而快速的从XML数据生成HTML或XML的方式。许多开发人员已经熟悉Xpath和XSLT，因此AJAX选择XML作为数据交换格式有意义的。XSLT可以被用在客户端和服务端，他能够减少大量的用JavaScript编写的应用逻辑。

　　CSS

　　为了正确的浏览AJAX应用，CSS是一种AJAX开发人员所需要的重要武器。CSS提供了从内容中分离应用样式和设计的机制。虽然CSS在AJAX应用中扮演至关重要的角色，但他也是构建创建跨浏览器应用的一大阻碍，因为不同的浏览器厂商支持各种不同的CSS级别。

　　服务器端

　　但不像在客户端，在服务端AJAX应用还是使用建立在如Java,.Net和PHP语言基础上机制;并没有改变这个领域中的主要方式。

　　既然如此，我们对Ruby o n Rails框架的兴趣也就迅速增加了。在一年多前，Ruby o n Rails已经吸引了大量开发人员基于其强大功能来构建Web和AJAX应用。虽然目前还有很多快速应用开发工具存在，Ruby o n Rails看起来已经储备了简化构建AJAX应用的能力。

　　开发工具

　　在实际构建AJAX应用中，你需要的不只是文本编辑器。既然是JavaScript非编译的，他可以容易地编写和运行在浏览器中;然而，许多工具提供了有用的扩展如语法高亮和智能完成。

　　不同的IDE提供了对JavaScript支持的不同等级。来自JetBrains的IntelliJ IDEA是一个用来JavaScript开发的更好的IDE，虽然许多开发人员也喜欢Microsoft’s Visual Studio产品(允诺会在最新的版本中改善对AJAX的支持)。Eclipse包含了两个免费的JavaScript编辑器插件和一个商业的来自ActiveStat的Komodo IDE。

　　另一个JavaScript和AJAX开发中的问题是调试困难。不同的浏览器提供不同的通常是隐藏的运行时错误信息，而JavaScript的缺陷如双重变量赋值(通常是由于缺少数据类型)使得调试更加困难。在AJAX的开发中，调试就更复杂了，因为其需要标识究竟是客户端还是服务端产生的错误。在过去，JavaScript调试的方法是删除所有代码然后一行行的增加直到错误出现。现在，更多开发人员回到为IE准备的Microsoft Script Debugger和为Mozilla浏览器准备的Venkman。

　　浏览器兼容性

　　JavaScript编程的最大问题来自不同的浏览器对各种技术和标准的支持。构建一个运行在不同浏览器(如IE和火狐)是一个困难的任务。因此几种AJAX JavaScript框架或者生成基于服务端逻辑或标记库的JavaScript，或者提供符合跨浏览器AJAX开发的客户端JavaScript库。一些流行的框架包括:AJAX.Net, Backbase, Bitkraft, Django, DOJO, DWR, MochiKit, Prototype, Rico, Sajax, Sarissa, and Script.aculo.us.

　　这些框架给开发人员更多的空间使得他们不需要担心跨浏览器的问题。虽然这些框架提升了开发人员构建应用的能力，但由于厂商已经开发了更细节的用户界面的打包组件解决方案，因此在AJAX组件市场中需要考虑一些其他因素。例如提供通用用户界面的组件如组合框和数据栅格的几个厂商，都可以被用来在应用中创建良好的通过类似电子数据表方式来查看和编辑数据的体验。但这些组件不仅是封装了组件的用户界面而且包括与服务端数据的通讯方式，这些组件通常使用基于标记方式来实现如ASP.Net或JSF控件。

　　展望

　　最近IE和火狐之间的浏览器之争变得火热起来，因此AJAX开发人员需要足够敏捷的作出反应。关键点在一些问题如CSS或XML，虽然各种浏览器形成采用最新标准的不同阵营(如Mozilla拥抱SVG和E4X标准及在最新火狐BETA版本中使用XUL，而微软使用自己的XAML技术)。所有这些技术代表当前AJAX主流JavaScript和XML的市场方向改变。

　　总的来说，AJAX开发人员必须尽快地跟进最新的技术并利用高产的工具集。成功的AJAX开发人员还需要留心他们的使用者以避免将任何问题扩大化。并且AJAX开发人员还需要持续地创新来创建增强Web应用易用性的新方法。