答：若是问Ajax能否跨作业系统平台，答案是Yes。

Q12：Ajax技术跨浏览器的问题该如何解决？

答：Ajax在跨浏览器遭遇的问题，在于浏览器之间的行为差异，所以开发者需要测试JavaScript程式在各种浏览器执行时的相容性，并针对差异的部分，撰写不同版本的程式。

或者，最简单的方式，就是套用YUI等Framework，透过平台解决相容性问题。

Q13：Ajax开发的应用能否平顺地在电脑、手机、PDA等不同装置上顺畅运行？

答：答案是No。随想行动科技总经理冯彦文表示：「主要原因在于手机装置对规格的支援不一，不论J2ME、Flash或Ajax都会遇到相同的问题。」

再者，每款手机的萤幕大小都不同，况且一般网页的资料量灌入手机萤幕会显得冗长。若要讲求美观，都必须针对行动装置提供特殊化的内容。例如国外知名的微型部落格网站Twitter，便针对手机平台设计特制的网站m.twitter.com。

Q14：听说用Ajax开发的网页内容，搜寻引擎可能找不到，那不就会影响网站的能见度？

答：其实是设计上的问题。这关乎一个专有名词称为SEO（Search Engine Optimization，搜寻引擎最佳化）。关于SEO的顾虑，究其原理，搜寻引擎的机器人是根据网页中的连结找到其他的网页，再找到内容，所以网页内容必须使用固定网址（Permalinks），搜寻引擎才会找得到。

若是改由JavaScript动态产生内容，那么将变成是由事件驱动（Event Driven），也就是使用者「开启」网页或「点选」连结才会产出内容，那么搜寻引擎机器人便无法找到资料。

邱继弘说：「这是网站设计的一种思维。希望增加曝光度，就要能够被搜寻引擎找到。」推推王中关于Ajax技术多半都用在视觉上，每笔资料都有独立的网址，他们绝对不破坏「Content Unique」的原则。

Q15：什么样的应用不适合采用Ajax？

答：以下几种情况不建议使用Ajax技术：

网页需要变动的范围比例很高
张嘉渊强调：「取决的关键点，就在于要搬多少资料到浏览器。」Ajax适合应用在局部、小量资料的修改，以减少网页重新载入的机会，网页中需要更新的比例很高，不如就重新载入吧！

排序
在ASP、JSP盛行之后，在网页上利用DataGrid控制项建置动态查询的报表是企业常见的应用。除了简单的查询功能，还可以任意地点选栏位变换排序的方式。此种应用便不适合采用Ajax。

尤其是在资料笔数多的情况下，张嘉渊强调：「20笔和100笔资料的排序，对网页效能的影响，绝对不只是5倍的差距。」对浏览器而言，变更排序方式就是整个DOM（Document Object Model，文件物件模型）的摧毁与重制，这类的应用反而是交给擅长资料处理的资料库比较适合。

需要换页的应用
Ajax诉求的就是实现不换页的资料更新，所以网址列没有变动，而这也就没有「上一页」、「下一页」的记录。因此有换页需求，尤其使用者有可能按「上一页」的应用，便不适合采用Ajax。

Web应用程式之所以适合采用Ajax技术的原因，也在于应用程式没有换页的概念。因此，在开发Ajax应用时，设计者也应在操作思维上，避开使用者会想按「上一页」的可能性。

Q16：若讲究高互动性，其他RIA技术例如微软的Silverlight及Adobe的Flash，可以提供更即时互动的效果，为什么选择Ajax？ Ajax会不会只是过渡性的技术？

答：这个问题必须分成以下两个层面来回答：

Silverlight或Flash的门槛更高
习惯右脑思考的程式开发者，未必能兼擅需要以左脑设计的Flash或Silverlight。当我们询问推推王的开发团队这个问题时，相关人等全部摇头晃脑地表示不喜欢Flash。其中陈冠杰以过去尝试使用Flash经验表示：「Flash的效能比较差，程式化的行为必须写在ActionScript中。」

从微软展示的Silverlight案例中，德国的女性购物网站OTTO、法国的法雅客购物网站，它们的图像化、直觉式的流畅设计确实令人目炫神迷。

假如是没有专业美工人才的网站，他们更难以面对Dreamweaver或Expression Blend，要接受以时间线（Timeline）结合图层产生动感效果的概念，开发人员需跨过的门槛更高。

Flash、Silverlight与Ajax可以并用
就微软开发平台而言，企业若需要比Ajax更酷炫的视觉效果，可利用Expression Studio设计网页、图像及动画等视觉元素，而逻辑运算的部分，则仍然是透过Visual Studio工具开发Ajax应用，所以两者并不冲突。

而Flash的应用，程式化采用的稿本语言是ActionScript，它的语法非常类似JavaScript，但仍可能令开发者感到排斥。 Adobe现已提出解决的方案，为了强化Flash与Ajax的互动，Adobe推出Flex-Ajax Bridge，让JavaScript与ActionScript可以相互沟通，那么Ajax与Flash元件就可以并存。

安全性

Q17：使用Ajax，是否让网站曝露在更高的风险中？

答：所谓Ajax，最狭义的说法是指非同步传输的沟通方式，也就是使用XMLHttpRequest这个浏览器物件来处理用户端与伺服器端资料交换的过程。就通用说法而言，Ajax进一步包含了使用JavaScript操作CSS与DOM（文件物件模型），以呈现丰富的视觉效果。因此Ajax的技术早已存在，它就是JavaScript，而Ajax只是一种应用的观念。

JavaScript本身是用户端的程式语言，是在网站使用者的电脑中执行，不像伺服器端的脚本程式，因此对网站本身造成威胁的机会极低。

有些人认为Ajax程式能够透过检视程式码的方式看到它的程式逻辑与变数使用方式，而增加对网站的攻击面，不像伺服器端的程式，能隐藏程式语法。

事实上，一个安全的网站，原本就必须在前端资料传递到后端时，做好过滤与把关的工作，不要相信前端传来的东西，这是一个网站开发人员必须牢记在心的金科玉律。如果伺服器端程式在设计时能谨守本份，重视程式的安全规画，那么无论前端是由使用者输入资料传来的，或是由JavaScript程式传递而来，都一样安全。

反而是由伺服器端发展出来的Ajax解决方案，例如DWR，能让使用者能从前端程式使用后端Java语法，即可能有潜在的安全威胁。

Q18：使用XMLHttp Request进行非同步传输时，难道没有潜在风险？

答：事实上，浏览器在设计这个物件之初，就已经考量到安全性的问题，因而限制XMLHttpRequest请求的资源与呼叫的脚本程式，两者必须在同一个网域内，不能存取网域外的资源，借此降低风险。这可避免恶意程式任意抓取资料，或是上传具危险性的程式给其他伺服器执行。

不过Web 2.0盛行的混搭（Mashup）方式，透过开放API进行资料交换，而这种方式的确就是绕过同一网域的限制，会产生一定的风险。设计这类API时，必须特别注意它的存取限制，以免让骇客有机可趁。

Q19：Ajax会向伺服器频繁要求资讯，是否会对网站形成阻断式攻击（Denial of Service）的效应？

答：就Ajax的设计模式而言，的确向伺服器发出要求的次数将会增加，往往一点异动，就会与网页伺服器或资料库互动，尤其互动效果越多，更是如此。

就拿Google搜寻时会采用自动完成的功能，列出可能的搜寻关键字，或是雅虎奇摩的字典查询服务，也有相似设计，只要输入文字，便会向伺服器要求待选字。

这个安全性问题应该就两个层面来看。首先应用这类Ajax语法时，原本就必须做好效能考量与测试，例如善用快取功能，记录反覆查询高的关键字，反而能降低伺服器的负担。

其次，如果骇客打算使用DoS对一个网站发动攻击时，事实上无论是不是采用Ajax都一样，而且利用Ajax发动DoS，不见得是有效率的作法。

Q20：如果Ajax对伺服器端的危害有限，那么对用户端呢？

答：虽然采用Ajax进行非同步传输时会受到本地端的限制，提供了一定的安全性，然而由于采用JavaScript，便会让使用者遭到跨站脚本攻击（Cross-Site Scripting，XSS）的机会增加，而让骇客可以趁机窃取使用者的帐号资讯或殖入恶意程式到使用者的电脑中。

过去使用者还可以透过关掉JavaScript方式，以降低浏览网站时的风险，不进入Ajax网站关掉JavaScript，形同使用者拒绝进入该网站，因为基本功能都无法使用。

由这观点来看，的确Ajax盛行，让骇客更有机会透过XSS的手法侵害使用者，不过XSS之所以能成功，通常是网站本身已经存在资安防线上的漏洞，例如没有检查使用者上传的资料，或是应用程式、系统本身有漏洞，如果能做好这些资安防护，那么即使采用再多的Ajax功能，使用者一样安全无虞。