解决 Google APP Engine JS更新元素内容时乱码问题
$("#success_info").html("嘿!是不是忘了填写哪一项啦呀!").css("color","#D9242B");
$("#success_info").html("<span>嘿!是不是忘了填写哪一项啦呀!</span>").css("color","#D9242B");
IE6下Javascript页面跳转和表单提交Bug
那么,如何解决IE6下Javascript页面跳转和表单提交Bug,需要使用setTimeout()函数延迟实现。
1,兼容各浏览器的Javascript页面跳转
- setTimeout(function(){
- window.location.href = url;
- },0);
2,兼容各浏览器的Javascript表单提交
- setTimeout(function(){
- form.submit();
- },0);
游戏游戏:钉子户大战拆迁队
过去几天,一款模仿《植物大战僵尸》的"山寨游戏"《钉子户大战拆迁队》在网上爆红,让无数网友为之折服并四处推荐。 》点击进入游戏
这款FLASH游戏中,"钉子户"为了保护一栋4层楼房用各种手段阻止"拆迁队"的持续轰击,楼房生命值为0的时候,游戏就结束了。有网友留言"游戏是娱乐的,而现实是残酷的。"
丁家六人防御"拆迁队"
该游戏是一款由FLASH技术制作的 "炮塔防御"游戏,场景、玩法和人物设置明显模仿《植物大战僵尸》。游戏共有包括"生存模式"在内的七道关卡。随着关数的增加,难度也越来越高,会不断出 现新的拆迁队。主画面是一片空荡荡的工地,一栋4层楼房孤零零矗立在屏幕最左侧,墙上写着"拆"字,周围满是高耸的楼房。
作为攻击方的"拆迁队"从右边出现,防守方是一户姓"丁"的"钉子户",有丁老爷子、丁老爸、丁老妈、丁小妹、丁小小、丁自酷六口人。
游戏设置非常简单,具体操作只有"召唤家丁"一个按钮。面对"拆迁队"的进攻,玩家需要点击"召唤家丁"按钮派出不同的人来防守他们的房子。他 们会站在不同楼层选取不同武器对"拆迁队"进行攻击。但玩家只能选择6个家丁中的4人来防守。每打倒一个"拆迁队员",玩家都会得到相应的金币奖励,家丁 的攻击力可以进行升级。
每一个关卡开始的时候,楼房都会有100点的生命值,如果在"拆迁队"持续攻击下,楼房生命值为0的时候,游戏就结束了。画面会出现"房倒,人 不倒,再接再厉"的字样;如果丁家可以守住不让小楼的生命值被攻击至0,这关就算过去了。画面上会出现"21世纪最牛钉子户英勇抗战,取得阶段性胜利。再 接再厉,抗战到底"的字样。
人物形象网络味十足
除了故事设定,这款游戏里面的人物名称、攻击方式和形象也颇受网友追捧。
该款游戏的"游戏说明"中介绍,丁家每一个人都有自己的攻击方式:丁老爷子开枪,造成"拆迁队"单人高伤害;丁老爸丢燃烧瓶,造成多人持续的小 伤害;丁老妈丢拖鞋,造成单人中等伤害;丁自酷丢哑铃,导致单人高伤害并且附带大范围群体减速,但是攻击速度慢;丁小小射弹弓,会造成单人高速小伤害;丁 小妹丢爆竹,多人中等伤害。玩家总结经验说:"每个人物最多升5级。合理搭配不同的人物出战来对付拆迁队吧,第7关会让你体验到无尽的拆迁恐怖之队。"
"钉子户"中最为网友喜爱的是"丁老妈",其穿着睡裙、烫着卷发、怒火中烧的游戏封面动作,被认为颇有周星驰《功夫》中"老板娘小龙女"的风采。
而游戏中"拆迁队"的人物命名更是充满了网络特色,第一个的名字就和网络红人一样:双刀男,双刀男的绝技是赤裸上身手举双刀拆楼,攻击力最小;接下来还有以风镐作为拆楼武器的风镐男;用铁锹拆楼的铁锹男;行动速度快、投射土炸弹的自行车男。
"游戏很娱乐,现实很残酷"
据游戏网站17173" FLASH小游戏频道"工作人员王颖介绍,这款游戏于8月22日 13:33:57在他们游戏网站上线,深得玩家喜爱。但具体制作人是谁并不清楚。
在游戏页面上,共有"囧"、"难过"、"恶心"、"不错"等六项可供玩家选择的游戏评价,截至记者发稿前,共有900名网友投票,其中815名网友投票给了"不错"选项。此外,该游戏在8月14日至9月14日的"本月排行"中,位列17173网站排行榜第三名。
"可以看出,玩家对这款游戏的评价是非常高的",王颖说,"游戏好玩,中文界面,画面效果不错,肯定会受欢迎。"
王颖总结,在他们网站上玩这款游戏的几乎都是中学生,主要集中讨论游戏怎么玩、该怎么过关,对现实问题没有多少感受。
而该款游戏的"游戏说明"中直言,"这个游戏有点恶搞的风格,玩了之后你立马会想起一部电影,还有现在的拆迁…… "
游戏风格确实引发网友有关现实的联想。如"丁老妈"的技能是丢拖鞋,而"拆迁队"有拿刀的、拿枪的,还有吊车投石块,这让网友联想到现实拆迁中,拆迁方和钉子户在对抗中的实力悬殊;游戏中孤独的小楼、大大的"拆"字,和之前曾经轰动一时的"最牛钉子户"照片相当相似;丁老爷子开枪的技能也让不少网友想到了"自制火炮对抗拆迁"的湖北"钉子户"。
记者注意到,大多数网民在微博上传播此游戏时多与现实相联系,觉得"太给力了",这一款山寨游戏"山寨得很现实"。有媒体分析,拆迁引起的纠纷 事件充斥媒体版面,该游戏介绍也迎合了网民的心理诉求;有网民表示,"游戏是娱乐的,而现实是残酷的","建议城管队员来玩一把。"
[玩家经验分享]
1.一定要注意速度问题。
2.拖鞋威力不大,但是速度快。
3.小朋友的弹弓伤害低,但是零点几秒就发出一次。所以,要折算单位时间内的伤害输出值。同时,基础伤害太低,速度快也没用。所以,杠铃还是有必要的。
4.丁小小射弹弓(优先升级) + 丁老妈丢拖鞋(次优先) + 丁自酷丢哑铃(最末) +丁小妹丢爆竹(3优先,第6关以后使用)。这个顺序绝对过前6关。
解析: 警惕 WebQQ2.0 的 Gmail 钓鱼
WebQQ 2.0 上线,腾讯又多了款重量级的应用,但是用过程中发现其 Gmail 模块存在钓鱼的嫌疑。当使用 Chrome 访问其 Gmail 模块时提示为诱骗网站。
展开这个页面的 iframe 地址,发现是在 qq.com 域下https://web2.qq.com/cgi/gmail/gmail.html
但页面的形式与 Google 的风格一致,非常能让用户混淆这就是 Google 自家的页面。


查看其源代码,发现并没有提交到 Google 的痕迹。
然后我们查看其相关的 gmail.js(https://web2.qq.com/cgi/gmail/gmail.js),发现其中有段代码为
var option = {retype:3,callback:"parent.qqweb.app.gmail.getListMail"}; if (u != null && p != null) { option.u = u; // Google 帐户用户名 option.p = p; // Google 帐户密码 } formSend( GMAIL_SERVER_DOMAIN + "cgi/qqweb/gmail.do",{method : "POST", data : option} );
这段应该就是往 GMAIL_SERVER_DOMAIN POST 用户名和密码登录了,那么 GMAIL_SERVER_DOMAIN 的值是什么呢?就在本文件的第 14 行
var GMAIL_SERVER_DOMAIN = 'https://web2.qq.com/';
也就是说,你的 Gmail 用户名和密码实际上是提交到了
https://web2.qq.com/cgi/qqweb/gmail.do
这个地址。
那么,作为个技术人,我不禁想问:"腾讯,你想干什么?!" 同时建议已经使用过该模块的用户尽快更改您的 Google 帐号密码,并检查 Gmail 过滤器中有无可疑的项目。
PS,这次的 WebQQ2.0 放弃了 YUI,使用了名为 Jet 的 JavaScript 框架,对其感兴趣的可以关注。
UPDATE
- 该 URL 在 Firefox 中也已被人举报为恶意网站
- 该 Gmail 应用已经被撤下,对应的 JS 文件也已被删除
关于Web-based IM通信模式的思考
摘要:
本文从Instant Messaging 出发,讨论了Web_based IM信息通信的特殊性,并在此基础上详细分析了现有的实现方案及其各自优缺点。
引言:
Instant Messaging(读成I-M),是一种使人们能在网上识别在线用户并与他们实时交换消息的技术,现主要用于网络即时聊天软件和特殊设备的网络实时监控。该技术普遍采用C/S架构,基于TCP/UDP协议,通过服务器协作,利用防火墙穿透(代理)或基于UDP的NAT穿透技术,保持客户端之间的持续长连接,实现客户端之间信息的实时交互。但是,该类模式下的软件系统要求下载安装专用的客户端程序,导致系统部署成本高昂,系统维护困难。同时,为保证即时通信的顺利完成,一般还要求客户端防火墙开放特定端口,引起系统安全问题。因此,这种模式的IM技术在网络环境下的广泛使用还存在一些局限性。
Web-based IM,是基于HTTP协议,系统采用B/S模式,客户端通过访问特定的网页而实现的及时通信技术。这种即时通信技术以网页为载体,避免下载安装庞大的客户端程序,系统功能在服务器端统一维护,既减少了系统部署费用,也降低了维护难度。因此,Web-based IM技术将在基于Web的远程监控、网站客服等方面有重大的意义。
然而,Web-based IM在技术实现上存在难以逾越的困难:首先,Web-based IM采用HTTP作为主要的通信协议,因此,HTTP的非连接、无状态特性将导致通信状态管理非常困难;其次,HTTP访问的单向性只允许客户端(Web浏览器)主动去联系服务器,而服务端却无法主动联系特定的客户端,更不用谈多个客户端之间的互访。所以,要实现Web环境下的实时通信,必须首先要解决这个问题,即充分利用HTTP的特性,在技术实现上做出适当的调整,以适应即时通信的需要。本文将在前人的基础上,从客户端"拉"和服务器"推"的角度,总结归纳基于Web的即时通信方案,并进一步分析比较各自的优劣点。
Web IM通信实现方式
1. 客户端"拉"(Client_pull)模式
传统的HTTP请求模式为:客户端主动向服务器发送信息更新请求,服务器响应请求,客户端接收完响应之后显示更新信息,这也称为客户端"拉"。为实现客户端信息(准)实时更新,一般采用客户端轮询的方案,即实时信息通过网络发送到服务器,保存到服务器内存甚至服务器实时数据库中,客户端根据实际情况,每隔一定时间就自动向服务器重新请求页面数据,以保证客户端内容的实时性。然而,传统的做法是客户端页面整体刷新,导致大量无用信息的重复下载,不但浪费客户端、服务器以及网络资源,而且这种同步的请求方式还将致使客户端页面长时间处于等待响应阶段,而无法继续操作,严重影响客户端体验效果。因此,随着 AJAX技术的成熟,人们常使用XMLHttpRequest对象,采用异步方式访问服务器定时获取更新信息。
2. 服务器"推"(Server-push)模式
服务器"推"模式,即服务器在信息变化之后主动发送新的信息到客户端,客户端接收之后自动进行更新。但是,由于HTTP无状态的特性,服务器响应完毕客户端请求之后,二者之间的通信在默认情况下会自动断开,加上NAT、客户端防火墙等因素的影响,服务器随时向客户端发送更新信息的条件还很不成熟,除非二者之间保持实时的连接。要实现客户端与服务器的实时连接,目前存在以下两种方案值得考虑。
1)基于客户端套接字的服务器推技术
要实现客户端与服务器的实时连接,传统的方式是采用在客户端页面中嵌入ActiveX、Flash、Applet之类的插件,插件基于TCP/UDP协议,通过套接字方式,实现客户端与服务器的持久连接,保证二者信道的持续通畅,以达到服务器在获取新信息之后可以主动发送到客户端,进行更新。一般而言,在不考虑通信信息的完整性的情况下,为减轻服务器的负载,服务器可以基于UDP协议向客户端发送更新信息。由于UDP是一种不可靠的协议,所以如果需要考虑通信信息的一致性等,则必须使用具有信息完整性验证的TCP协议进行通信。
2)Comet技术
近年来,由于Ajax技术的发展和推广,一种基于HTTP长连接、无需在浏览器端下载安装插件服务器"推"技术,即Comet技术,成为新宠。其实现模型有以下两种:基于 AJAX 的长轮询(long-polling)方式和基于 Iframe 及 htmlfile 的流(streaming)方式。
长轮询的基本思想就是服务器不立即响应客户端请求,直到服务器接收到针对该客户端的新的信息的时候才响应客户端的请求。客户端一收到服务器的响应就马上发送下一个请求,这样就保证了客户端总是处于请求等待响应的状态,从而使得服务器处于"主动"的地位,当其有数据要发送时可以准确无误地找到客户端,这就类似于一个持久的TCP连接,如图所示

如果在双方规定的时间内,在两个方向上都没有反应(如客户端没有需要更新的信息,而连接即将超时的情况),则服务器可以用一个没有数据的空响应来进行响应。这个响应将立即触发一个新的客户端请求,这样就可以保证在网络连接不正常的情况下双方都可以在一个合理的时间内知道。为了避免传统HTTP请求导致页面整体刷新的情况,客户端请求一般采用AJAX技术,利用XMLHttpRequest对象向服务器发送异步请求以更新数据。
流(streaming)方式的基本思想是:在 HTML 页面里嵌入一个隐蔵帧,然后将这个隐藏帧的 SRC 属性设为对一个长连接的请求,服务器端就能源源不断地往客户端输入数据。然而,iframe服务器端并不返回直接显示在页面的数据,而是返回对客户端 Javascript 函数的调用,如"<script type="text/javascript">js_func("data from server ")</script>"。服务器端将返回的数据作为客户端 JavaScript 函数的参数传递;客户端浏览器的 Javascript 引擎在收到服务器返回的 JavaScript 调用时就会去执行代码。

从上图可以看到,每次数据传送不会关闭连接,连接只会在通信出现错误时,或是连接重建时关闭(一些防火墙常被设置为丢弃过长的连接,服务器端可以设置一个超时时间,超时后通知客户端重新建立连接,并关闭原来的连接)。
实现方式比较
采用纯粹的HTTP+AJAX技术实现网页的实时通信,技术简单,成本低,但是存在一些不足:第一,所有客户端的更新消息通过服务器进行"被动"地中转,客户端通过对服务器进行轮询,实现客户与客户之间的消息交互,因此客户端获取的信息是"伪实时"的。第二,轮询的时间间隔的设定异常困难:如果时间间隔过短,就会产生大量的无用请求,加重网络的负担;如果时间间隔过长,又不能保证客户端及时获取更新信息。由此可见,该方案的成功实现必须解决低响应等待时间和低网络带宽之间的矛盾问题。倘若服务器仅在数据发生变化之后,才向客户端发送更新信息,那么这一切问题都能得到妥善处理。
Comet技术可以解决低响应等待时间和低网络带宽之间的矛盾问题,并且在信息实时性方面有所改善,但是仍然存在一些问题需要注意:首先,该模式会仍然导致部分无用信息的下载;其次,对于某些对信息实时性要求很高的应用,它也表现出心有余而力不足;再者,基于HTTP1.1规范,同一客户端不能同时使用超过2个的HTTP长连接;最后,由于Web 服务器会为每个连接创建一个线程,如果在大型的商业应用中使用 Comet,服务器端需要维护大量并发的长连接,因此在这种应用背景下,服务器端需要考虑负载均衡和集群技术,或是在服务器端为长连接作一些改进。
基于插件的解决方案利用Socket连接服务器的确可以保证客户端信息的实时更新,但一些因素值得考虑:首先,部分页面插件需要客户端下载安装(如ActiveX),因此在特定客户端环境下可能因为插件安装失败而导致实时通信无法使用;其次,页面插件使用套接字接口,需要服务器开放一个通信端口,在实现过程中甚至可能需要程序员解决防火墙穿透问题;再次,页面插件在接收到服务器返回的信息之后,可能无法通过脚本语言(如JavaScript)去更新HTML页面(如Applet);最后,客户端连接数量增多会加重网络负担和服务器负载,直接影响客户端并发访问数量。
展望:
以上几种解决方案虽然都存在一定的不足,但在特定的情况下却具有一定的优势。因此,在实际的工作中,可以针对特定网络状况、服务器性能、信息有效期限等现实情况从有效信息率(单位时间系统内产生的有效信息的数量)、客户端并发数量、数据一致性、信息实时性、服务器负载等方面考察各种方案。
参考文献:
1. Comet:基于 HTTP 长连接的"服务器推"技术
2. B_S模式下基于Jabber的IM系统的构建方法
3. IM:聊天进化谱
4. 基于Ajax的即时消息系统的设计与实现
5. 基于P2P技术实现即时通信系统的研究
6. 基于Web的远程实时监控系统研究及应用
7. 即时通信研究综述
8. 即时消息
9. 网页即时通信的研究及应用
10. Ajax技术在基于Web的实时监控系统中的应用研究
11. Ajax技术在实时WEB监测中的应用研究
12. Flash在基于Web的远程实时监控系统中的应用研究
13. 动态Web技术在实时监测系统中的实现
14. 基于B_S的海洋平台远程监控系统设计
15. 基于Web的告警实时显示系统的设计与实现
16. 基于Web的工业信息实时监控系统研究
17. 基于WEB的工业远程监控系统研究与实现
18. 基于Web的实时控制系统的研究与设计
19. 基于服务器推送和事件流处理技术的实时Web系统研究
20. Anil Bhatt 张凯峰(译)Ajax推送与拉取方式的比较
21. JerryQu WebIM开发之通讯模式介绍
22. 赵宏华 基于WEB的IM实现考虑
23. 及时通讯原理
24. WebIM开发之多页面数据同步
免费版Chilkat FTP 使用例子
| Sample Chilkat FTP script The following is a Sample script for the Chilkat FTP component. <% '## Create object Set objConnect = Server.CreateObject("Chilkatftp.ChilkatFTP") '## Get hostname objConnect.HostName = ("Host address") '## Get FTP username objConnect.Username = ("user") '## Get FTP password objConnect.Password = ("pass") '## Connect to server objConnect.Connect() '## Get connect status If objConnect.IsConnected = 1 Then '## Change dir objConnect.ChangeRemoteDir("Directory") If objConnect.CreateRemoteDir ("Directory") = 1 Then Response.Write "It Worked!" Else Response.Write objConnect.ErrorLogHtml End If Else Response.Write "Failed to connect to the server!" End If '## Disconnect objConnect.Disconnect() %> |


