SimpleLife

客户端上传工具－SWFUpload

vsky — Mon, 16 Jun 2008 00:46:24 +0800

年初在改进公司的视频文件上传体验时接触到了SWFpload，当时的版本还没有Release，功能和文档都还在完善中，遇到了IE下的刷新BUG，可把我折腾了一番。由于手头事情太杂了，当初许诺下的“等我项目结束时希望SWFUpload放出正式版和官方确定的接口文档了，到时再针对传统文件上传的各种方式和SWFUpload功能包唠叨几句”的话，我也一直都没有实现，很是惭愧。

最近由于项目中多文件上传的需求，我才发现SWFUpload已经升级到V2.1.0版了，功能和文档都已经能够满足复杂的项目需求了，因此特把我之前的许诺补上，并附上针对V2.1.0版的SWFUpload翻译。（此版本也已经修正了IE的刷新BUG，不再需要使用我之前的解决方式了。）

一、首先来比较下目前的几种的客户端上传：

1、File表单

使用标准的HTML元素提供的File表单是最原始、传统的上传方式，他的优势在于浏览器的广泛兼容性，除了服务端需要处理Files信息以外，不需要额外的处理程序即可完成文件上传。

但使用File表单上传文件会造成页面的刷新，尤其是在上传大文件的时候，在文件上传过程中，用户需要傻等在一个空白页面前，没有任何反馈信息来提示用户当前的上传进度。同时无法在客户端对文件大小做检测。

2、IFrame结合File表单

使用一个含有file表单的iframe来完成文件上传，能够避免文件上传过程中的页面刷新，在一定程度上改进了用户体验，但同样没有解决大文件上传时候缺少反馈信息的问题。相比File表单上传，此方式还需要对程序做额外的处理，同时需要JS的支持，复杂度稍微增加了一些。

3、IFrame、File表单结合AJAX

在方式2的基础上引入AJAX来实时跟服务端脚本获取当前的上传进度，实现了页面无刷新、实时更新上传进度的功能。但程序的复杂度又增加了一个级别，由于要不断跟服务端发送请求，同时也增加了服务端的压力。

4、Activex控件

使用控件方式完成的上传在功能和效率上都很不错，页面无刷新、显示上传进度、批量上传，个人认为遗憾就在于需要在浏览器上安装控件，而且只能支持IE，弹出那么个安装提示可能会吓倒多数用户，开发的复杂度也提高了。

5、Flash

Flash的FileReference类提供了文件上传功能，相对于传统的File表单而言，Flash上传能够获取客户端的文件的更多信息反馈，例如文件大小、类型、创建、修改时间等，利用这些信息可以在客户端对文件进行类型和大小等属性的一次过滤。

FileReference类提供了多文件上传功能。

Flash直接向服务端发送文件数据，因此Flash本身是可以随时知道文件上传数据而显示上传进度，而不需要使用AJAX的方式不断跟服务端发送请求增加服务端的压力。

弊端在于客户端需要Flash播放器的支持，而且在一个页面中插入一个Flash，从UI元素的统一角度来看，似乎有些别扭，如果页面需要更改风格，那么Flash还需要重新修改然后编译，而且程序开发的复杂度也提高了。

6、Flash结合JavaScript

在方式5的基础上，将Flash隐藏起来，利用JavaScript来控制Flash元素处理文件上传，Flash使用ExternalInterface来完成跟JavaScript的通信，将页面元素的控制权交给JS。这样就避免了方式5中的UI元素不统一、修改不灵活的弊端。但代价就是Flash程序开发的复杂度再次提高了，同时也需要更高的JS和XHTML开发能力。

以上列举了目前我所了解的浏览器环境下文件上传的方式，并对其优劣都做了简单的罗列，在实际开发中我们可以根据自己的应用来选择合适的方式，假如我们的需求只是用户给自己上传一个10K不到的头像，如果我们还大费周折地实现了头像上传的进度提示，那就是事倍功半了，因为在目前的绝大多数网络情况下，一个10K的文件传输是一眨眼的功夫。

(more...)

ActionScript3初体验

vsky — Wed, 07 May 2008 21:42:34 +0800

　　当我意识到AS3是革命性的时候，我对Flash的热情一下又被点燃了，立马以公司项目中的FLV播放器入手开始了AS3的体验实战之路。这半个月来多亏同事的支持，项目中他们分担了很多工作，让我能够有更多时间来潜心重写FLV播放器，今天终于发布了一个具备基本功能的Demo，实现了基本的视频控制、自适应容器尺寸、全屏播放，但真正要使用到项目中来，还有一些细节工作需要去做，例如外部数据接口的预定义，对广告和RSS的支持。

　　此版播放器的重写最重要的目标是要将UI和程序完全分离开，以满足项目中播放器样式频繁更改的需求。在开发过程中，我也更深刻体会到了AS3在OOP上的巨大变革，相对于AS2而言，新的体系更加严谨，起初我也有点不习惯，例如以前常用的类和对象都不见了；现在的显示对象复杂的继承关系似乎难以记忆了；严格的编译检测让自己很受挫；新加入的运行时检测也让人很恼火等等。但当我遇到越来越多问题，解决越来越多问题的时候，我对AS3的整个体系的认识也更清晰了，AS3还是很值得称赞的，随后我会发布一些自己遇到和解决的问题的心得(PS:我把本地的WIKI也同步到网上一份了，这里有一些零散的笔记，可能对你有一些帮助)。

ActionScript3.0是革命性的

vsky — Sun, 13 Apr 2008 23:54:59 +0800

　　上个周末去书店时碰巧看到了AS3 CookeBook，我记得在apollo的alpha版快出来的时候，7yue就推荐过这个小册子，只不过我已经习惯了AS1和AS2，对于一个新技术的学习还是持保守态度，加上这一年以来项目需求中更多的是DHTML＋AJAX的工作，也无暇去了解AS3，一直都以为它只是对AS2的一个扩充，是Adobe换汤不换药的商业行为。可当我翻看了下CookeBook的目录，然后又针对性地看了几节以后，心里顿时有了一种很激动、兴奋的感觉，AS3并不是对AS2的补充，而是颠覆性的，它对Flash的发展是革命性的。

　　上周开始抽空研究AS3，目前我还一直都处于兴奋状态，恨不得能够不睡觉地把Help文档通读一遍，就我目前的认识对AS3的重大转变先写个引子，希望对AS2开发者给个友好提示，如果你不抵触学习新技术，那么还是尽快转到AS3来吧（PS：目前接触时间有限，文中有理解不当或者错误之处望谅解、指出，随后的学习中会我也会继续发布一些体会）。

　　一、全新的“显示对象”架构
　　FlashPlayer9中加入了一套新的AS虚拟机器（AVM2），它提供了一套新的显示API，相对于之前的版本执行和渲染效率提高了不少。在AS3以前FLASH中的可编程的显示对象只有MovieClip和TextField，架构很简洁，他们都是直接从Object类继承的。在AS2的面向对象体系引入以后，一个MC类的属性和方法加起来近百个，目的就是为了让AS对MC的控制能够“随叫随到”，但是以牺牲效率为代价的。例如我们动态复制了几个MC到特定的坐标，而没有任何交互需求，但这些新的MC实例却依然具有了很多我们并不需要的属性和方法，因此很多编程人员都会抱怨MC是一个笨重的类。
　　
　　FP9中新的显示架构彻底颠覆了“MovieClip是灵魂”的设计（AS2那套东西已不再沿用了），这个重大的更新主要体现在对显示对象的抽象更细致、清晰了。简单说来从概念上划分为了显示对象、容器对象、可交互对象，在这个基础上提供了更便捷地遍历显示列表的方法，添加、删除可视元素的方法、自动化地深度管理等。
　　

　　从功能上详细提供了15个可视对象类，这就让我们能够根据实际需要选择合适的对象来实例化，而避免无用消耗。对这些显示对象的具体特性可查阅帮助文档，这是AS3显示编程的灵魂。

　　
　　二、清晰的事件机制
　　从AS2中就引入了事件侦听模型，但由于AS1和AS2编程的随意性以及AS开发人员更多的是设计转行的，很多人还是习惯使用_mc.onRelese = function(){}，甚至是on(release){}，这些不同实现的优劣这里就不再重复讨论了，很多文档都有详细地对比说明。正是因为事件侦听模型的巨大优势，所以在AS3中有且只有只一种事件模型，它是支持了W3C DOM3事件规范的标准，对于它提供的各种广播事件也需要熟记于心。
　　在新的事件模型中，this对象能够自动找到它的原始对象实例，而不用再使用Delegate这种和怪异地方式来指定事件处理函数的上下文引用了。
　　更多细节需要参阅文档，熟悉这个新的事件模型是很有必要的，对于交互编程而言，这个是重点之一。

　　AS2是不支持事件流的，现在你不用再为此头疼了，因为支持事件流是AS3的事件机制的又一重大更新，对于事件流的捕获、目标、冒泡这三个过程你需要很清楚，每当你初始化一个交互元素时，你就需要在脑海中迅速地按顺序触发这些过程，这是交互编程的重点之二。

　　三、更为便捷的库元件绑定和文档类绑定
　　在AS2中我们如果需要重新初始化一个目标MC的实例，通常会采用duplicateMovieClip或者attachMovie来实现，但这两个实现都存在弊端和不便，局限性比较大。AS3提供了一种更便捷的方式来实例化一个目标元素的实例。在AS2的组件开发中我们通常都会使用库元件的类绑定，但在UI和程序协同、构造函数传参方面还是不太方便。而AS3中我们完全可以用AS自由控制库元素实例化到舞台上，例如：

//在库中将目标MC的导出类设置为FileUpLoad
//如果只是想显示库中元素，那么你没有必要额外建立FileUpload文件，编译器会帮你自动搞定
//在AS中实例化一个图片上传UI
var picUpload_mc = new FileUpload();
//添加到舞台上显示
stage.addChild(picUpload_mc);

　　对于库绑定的细节需要详细了解，其中还涉及到一些实际问题的实现方式，例如如何在类中访问绑定库元件中的元素等。但我个人认为利用AS3提供的这一新功能，能够更好得设计程序的架构，更符合MVC的开发原则，具体实现还需要在以后的研究中来探索，也希望和大家一起交流。

　　如果你接触过Flex开发，那么文档类的绑定就很熟悉了，这是FLASH开发环境所不提供的，但在FLASH CS3中提供了这一功能，目的还是规范开发。

　　四、丰富的功能包支持
　　就FLASH CS3开发而言，Adobe沿用了Flash之前版本的一些类库，主要都在fl.*包中，在这个基础上有更新了一些顶级包，同时又提供了一些新的包，主要都在adobe.utils中。除此以外，你还可以使用Flex作为开发平台，Flex提供了更为丰富的功能包和组件。

　　五、语法特性
　　AS3语法特性上也有一些变化变化，目前我针对下面几个做过测试：
　　1、在Number类型的基础上，新增了int和uint类型。
　　2、类型检测方面增加了is和as两个运算符，AS3提供了运行时的类型检测，在这之前只是提供编译检测。
　　3、各种数据类型的值在undefined时，现在都会给一个特定的默认值（编程中需要格外小心）。　
　　4、对于函数的执行，需要严格匹配参数个数，并提供了一种...(rest) 形式的参数来支持任意多参数的调用。
　　5、面向对象体系更细致了，增加了包的概念，增加了inernal和final的两个修饰符，对于类中public、private、proteced的访问权限也都有变化，对于重写超类的方法需要利用override关键字做申明。　　

　　六、其他特性
　　上面的五点是我目前接触到的，同时也是个人认为最重要、最有进步的变革，除此之外还有一些重要的变化特性，例如在二进制、socket通信、E4X、正则表达式、文本显示、全屏模式等方面也都有一定的改进，有待于在实际操作中来熟悉。

　　PS：虽然近一年没有怎么系统地做Flash的东西了，但从WEB前端的发展动态来看，Flash的交互性越来越被重视了，就目前应用而言，除了在WEB上的RIA以外，在PC桌面应用上，依托于apllo或者yahoo Widget这样的运行时环境，Flash的应用应该会更有前景，界面丰富、交互灵活、相对较低的开发门槛，这些都是他的优势所在。（手机开发没有接触，这个平台对FlashPlayer的支持版本不太清楚，但我相信只要有利益存在，技术自然会被商业驱动起来的。）

年轻的我们都需要沉淀

vsky — Tue, 25 Mar 2008 22:50:29 +0800

　　人是如此容易受环境的影响，在遇到一些人、发生一些事以后，心态就逐渐发生变化了，曾经认为自己的心态已经够平和了，但经历了这个“混乱”的时期后发现自己的平和还不够彻底。因为年轻而过于理想，因为年轻而过于浮躁。

　　在经历了这样一段混乱的时期之后，很感谢那位跟我聊了很多切身感受的同事，那次的聊天让我清醒了很多，原来自己在不知不觉中已经忘记了当初选择这个Team的原因，忘记了自己坚持的东西。幸好现在又清醒了，再回过头思考下这个经历，也体会到了一点点社会的复杂，年轻的我们需要经验和心态的沉淀。

　　看着一起奋斗过的同事一个个离去，心里确实很难受。上次有这种感觉还是在我实习离开1906的时候，虽然隽辰说公司的人员流动是很正常的，但从我个人而言，情感上始终过意不去，觉得自己有负于团队，有负于大家对我的关照。但我现在能够很理性地看待同事的离职了。每个人的都有自己的选择，因为生活压力，抑或是因为自己的梦想，甚至是因为自己的浮躁。如果无法认可这个团队，那么最好的选择就是大家好聚好散。既然大家都选择了创业团队，那么就需要有创业的勇气和激情，就需要考虑到了创业的艰辛和风险，而不是遇到了困难就犹豫了。恰好，年轻的我们总是会不自觉地理想地看待问题，很小的麻烦可能会被我们放大，然后愈演愈烈，最终影响到了团队的士气，让大家都很沮丧。

　　大浪淘沙，年轻的我们需要懂得坚持，因为我们太需要沉淀了，只要我们用心、务实地做好自己的事情，坚持下来，那就没有绝对的失败。上帝在关闭一扇门的时候，定会为我们打开另一扇门。

生命在于运动

vsky — Mon, 17 Mar 2008 00:04:19 +0800

　　我一直都不习惯北方的干燥，但却很喜欢北方天空的晴朗。有风的日子里，蓝蓝的天会被扫得一丝云都没有，除了蓝还是蓝，越发让我感觉天地之间是如此开阔。如此好的天气不出去运动就太浪费了。

　　周五公司组织了一次春游，早上9点我们就乘大巴往蟒山公家森林公园出发了，遗憾的是有几个同事临时有事情没有参加。按照抽签决定的分组开始爬山比赛，规则是一个组全体成员到达山顶才记入小组成绩，这就需要团队合作了。海拔不过500米，但路线比较陡峭，所以没用多少时间就爬到山顶了，比起香山和紫金山，感觉爬蟒山也就是个热身吧，沿路的山桃都仅仅是花苞而已，也没有秀丽山景可言。不过值得高兴的是，我们组居然得了个第一名，哈哈，当时确实是个意外的惊喜啊，后来才知道比我们早上山的同事并不是一个组的。

　　中午大家找了个地方吃饭稍做休整，下午又去了航天博物馆，还被卖票的当作学生给卖了半票，汗啊！早先听说过北方很多山体都被挖空用作军事工事，这天算是第一次亲身感受到了。当我从博物馆展厅走了一圈以后才发现，原来外面看到的几个连续的山体都已经被挖通了。里面陈列的多数是模型和一些型号较久远的真机，我没有太大兴趣。在展厅最后意外的发现居然有AH-64阿帕奇，这个确实让我很惊讶，后来仔细一看介绍，这是一个以色列的复制品。不过终究是个阿帕奇啊，哈哈，还是合个影了。

　　从航空博物馆出来都已经快4点了，由于周六约好有一个山地骑行活动，所以又和同事匆忙赶往车行取车，半个月前订的车子，终于在DC的多次催促下，老板才“千辛万苦”给调了三俩灰银的Merida公爵，装车、试车过后又弄了些基本配件，快八点的时候才往家赶，虽然提前在地图上看好了路线，不过还是犯了个错误，到家都已经9点多了，一看码表都快30KM了。匆匆洗了个澡就睡了，心里还在担心第二天的100KM骑行了。

　　第二天起床小腿果然酸痛，不过想到大家都已经约定好时间了，还是咬咬牙出门了，8点我们A队在上地KFC集合往B点出发，然后和B队碰头以后赶往C点和C队碰头，最后一行9个人开始了我们的黑山寨吃驴肉之行。

　　很久没有这么大量运动了，在公路上巡航速度就有些跟不上队伍了，同行的有经验的队友都挺照顾的，不然后来的20KM盘山路自己可能真放弃了。虽然速度慢点，不过最终还是坚持到了山顶，也顺利吃到了驴肉，用奶牛的话说是吃了驴肉有驴劲，哈哈，回来的时候速度确实快了不少　:)　回来又回味了一番，虽然此行对我而言很累，不过确实有意义，第一次的挑战成功，也认识了这么些热心的朋友，很不错啦～

　　合理规划自己的时间，生命在于运动，在于折腾。

春节随想

vsky — Sat, 16 Feb 2008 17:53:38 +0800

　　春节回家呆了十天，感觉还没缓过神儿，除夕早上的鞭炮就劈里啪啦闹起来了，然后一家团圆吃年夜饭，亲戚家串门拜年，遇到我们家这样亲戚比较多的，喜庆倒是喜庆，就是感觉太累了，拜年和吃饭全都算下来，每年到了正月十五还结束不了，原来想回来歇歇、陪陪父母这也成了奢望。父母默默付出了这么多心血培养、教育了我，我却不能在自己身边照顾他们，这一直都是我心中的愧疚。

关于父母

　　现在回想下，我的初中和高中阶段更多的时间是在学校度过的，上大学又选择了另外一个城市，家里呆的时间就更少了，而且那个时候无知，体会不到父母的辛苦，而这两三年自己更多地思考了这些问题，随着时间的流逝，父母在不知不觉中老去，我心中的愧疚感也越来越深，虽然每周都给家里打电话，但始终觉得自己欠父母的太多太多。我只能在电话里叮嘱他们注意身体、在心里祝福他们每天都舒心，同时自己努力工作、提高自己，希望早一天回报父母，至少在物质上不能让他们再为我担心。我告诉父母他们的健康就是对我事业最大的支持，我不清楚他们是否能够体会我的用心。

关于教育

　　春节回家见到了几个小学、初中同学，他们都是初中毕业就上了技校或者没有继续读书了，然后有在当地工厂上班的，有在店里做销售的，跟他们聊过以后更令我吃惊的是，有同学结婚的，甚至有的连孩子都有了。仔细算算初中毕业到现在已经过了七年多了，七年过后我们的差别太惊人，基本上很难聊到一个话题上了，彼此都很尴尬，这让我更加深刻地认识到环境对人的影响，同时让我想起前两年我对大学教育的一个思考。

　　我一直很偏执地认为在目前的教育制度下，大学教育浪费时间，有能力的人懂得自己学习，甚至断言以后绝对不会把自己孩子送到学校。但现在看来，目前这种教育方式从大局讲是最“保险”的。至少它给予了很多人更开阔的眼界和更灵活的思维方式。在如今教育的大环境下，能够利用提供的现成资源更大程度地充实、提高自己就是能力了。

关于工作

　　回家自然有亲戚朋友问到工作的事情，互联网对于他们很多人来说都是一个不太了解的东西，尽管他们的孩子天天在家上网。在我的认识里，互联网是一个信息交换的平台，如果在这个平台上提供的服务让信息交换够便捷、实用、高效，那么这个平台将给我们的生活和工作带来巨大的变化。但我不能这么给他们解释，中国网民目前还是低端用户居多这是事实。这再次让我产生疑惑，在这样一个大环境下，我们费尽心思地来策划众多互联网产品，又费尽心思来构建，憧憬着我们的产品被雪崩一样的用户来使用，而现实一次次打击大家的积极性，究竟问题是在哪儿了？是产品策划出了问题？还是系统的可用性、易用性不够？是产品市场推广不得力？抑或是目前网民太低端？为什么不能一起把这些信息收集起来分析，寻找答案呢？

　　一直站在外面是无法获得答案的，08年也是一个开始，需要开始尝试了。

URL编码“陷阱”

vsky — Tue, 29 Jan 2008 22:36:13 +0800

　　上次谈到客户端和服务端的编码“陷阱”，其中对url编码只是提及带过，并没有做深入讨论，事实上由于浏览器环境的复杂和不一致性，我们也很容易掉进url编码“陷阱”。首先看一个demo，我的测试是在FF和IE6上进行的。

　　在FF下表现正常，而在IE6下当点击第一个链接的时候，服务端给我们返回的id变量值竟然出现了怪异，和我们传递过去的“实验室”不一致，这看起来似乎很怪异。整个过程中我对get过来的参数id除了做输出，没有做任何额外处理，上面的怪异现象实际上是浏览器造成的。
　　
　　一、URL编码需要指定被编码字符的字符集

　　首先我们要明确的是在对ASCII码以外的字符做URL编码时，你要清楚的知道被编码的字符的字符集，这点很重要。例如我们要对“汉字”这两个字符做URL编码，你可能得到的是“%E6%B1%89%E5%AD%97”，也可能是“%BA%BA%D7%D6”。为何会有两个了？事实上还有更多。前者是UTF8下“汉字”的URL编码，后者是GB2312下“汉字”的URL编码。如果客户端是针对字符集A做的URL编码，而服务端默认是以字符集B处理，那显然就掉进陷阱了。（PS:随后有一个测试可以看到）
　　
　　1、页面中的字符编码

　　当服务端将页面代码发送给客户端并显示在浏览器里时，该页面中的字符编码就已经确定了，它可能是服务端在header中直接指定的，也可能是在页面的meta信息中设置了charset，具体见客户端和服务端的编码“陷阱”中的第一和第二点分析。以上面那个怪异的demo为例，页面的字符集是utf-8，当点击第一个“实验室”链接时，IE6地址栏是“http://www.v-sky.com/demo/urlencode.php?id=实验室”，而FF下是“http://www.v-sky.com/demo/urlencode.php?id=%E5%AE%9E%E9%AA%8C%E5%AE%A4”，对比可知，对于链接中的非ASCII码IE是“不会”做处理的（PS:事实上IE的编码过程是在背后进行的，没有在地址栏展现给浏览者而已），而FF会根据字符本身的字符集做URL编码（PS：你可以将此页面字符集设置为GB2312以后测试，FF下的地址栏会变成GB2312对应的URL编码）

　　2、URL地址栏中的字符编码
　　
　　同样在针对上面的怪异demo，刚才我们都是通过点击链接请求一个新的URL来传递参数，现在我们直接在地址栏中给id输入参数“实验室”，然后回车察看结果。你会发现无论是IE还是FF，服务端输出的变量都是乱码，在FF的地址栏中我们可以看到这里是针对GB2312字符集的“实验室”做的URL编码，而服务端是以UTF8编码处理的，这就造成了输出乱码，前面提到的陷阱出现了。
　　
　　简单来说就是浏览器中输入字符的编码是根据浏览器和用户在浏览器上的个人设置来确定的，这里有一个详细的说明，我没有对各种情况都做测试，因为首先我不会用非ASCII码命名文件，其次非ASCII码的传参随后有更好的解决方案。

　　二、对ASCII码以外的特殊字符统一编码
　　
　　实际项目中很少会出现包含非ASCII码的链接，能够避免这种情况最好，尤其是希望用户容易访问的地址更应当考虑易用性。但如果你真的因为某些原因无法避免，那么你只有主动对这些特殊URL进行统一的URL编码，避免IE这样的浏览器来捣乱，就跟demo中的第二个链接的做法一样。

　　对于接受用户输入而构造出来的URL请求，例如搜索引擎入口，至少会GET传递一个关键字参数。如果对你的项目而言这是一个很重要的功能，那么你可能需要将各种情况都考虑进来，这个功能www.google.cn考虑的就很不错，页面编码本身是utf-8的，如果从搜索框搜索的，那么URL中是针对UTF8的关键字做的URL编码，如果是用户从地址栏输入，也就是针对GB2312的字符集做的URL编码，这里google在服务端应该是做了字符编码的判断，同样能够准确得到搜索结果，可用性不错，嘿嘿。

　　(PS:这里我自己也有一个疑问，目前没有找到直接的资料说明。对于包含非ASCII码的链接，IE会在背后做编码处理，只是没有像FF那样直接在地址栏反应出来，这点在HTTP通信中有资料说明。针对上面的demo，我尝试将“实验室”更换为其他字符测试，例如“你好”、“奥运”等，IE下并为出现demo中的怪异情况，这就说明PHP在接收GET过来的参数时，对于ASCII码以外的某些特殊字符并没有正确接收，问题是出在哪儿了？如果哪位知道原因希望告知。)

四个小时的SWFUpload debug之旅

vsky — Mon, 07 Jan 2008 01:52:49 +0800

　　由于项目需要，这两天研究了一下SWFUpload，一个JS和AS结合实现的上传“功能包”，简单来说原理就是利用flash的FileReference类在客户端完成文件信息的过滤，包括类型、大小，以及上传的实时进度信息，然后利用externalInterface来跟客户端的JS通信，提供了一系列属性、方法和事件触发时的回调函数接口，将UI的主动权完全由FLASH转交给了JS来操作。(PS:目前版本还没有Release，有些功能和文档还不全，疑惑之处可直接翻代码看看。等我项目结束时希望SWFUpload放出正式版和官方确定的接口文档了，到时再针对传统文件上传的各种方式和SWFUpload功能包唠叨几句。）这里只唠叨一下目前这个版本存在的一个BUG，在IE6内核的多标签浏览器中（例如GreenBrowser和Maxthon），一旦页面刷新过后，SWFUpload的功能就不正常了，或许你也正为这个发愁了，可以先跳到这里察看临时解决方案。

　　最初用SWFUpload做demo的时候就发现了目前存在一个小BUG：我机器上的浏览器环境是GreenBrowser(IE6内核)，打开上传页面，一切功能都正常，此时如果刷新或者强刷一下页面，那么当点击文件浏览按钮时(触发selectFile事件)，debug信息中就会提示“Could not find Flash element”，而在FF、IE7下面功能很正常，更奇怪的是在我随后的debug过程中我发现在单独的IE6，也就是系统提供的那个单窗口的IE6下居然功能也很正常。后来又在ie6内核下测试了maxthon同样存在和GreenBrowser一样的问题，难道这个跟多标签浏览器也有关系？第一反应是我的demo有问题。于是去SWFUpload的官方demo验证了下，发现居然也存在这个问题。哎～又是IE惹的祸。开始Debug之旅吧。

(more...)

客户端和服务端的编码“陷阱”

vsky — Fri, 21 Dec 2007 12:00:00 +0800

　　为什么页面出现乱码？为什么数据库里出现乱码？为什么这些乱码的出现几率飘忽不定了？诸如此类的乱码问题困扰了很多WEB开发人员。假如不将这背后的细节扫扫清楚，那么我们的确不知道什么时候乱码又出现了，如果你确实没有时间关心这些细节，那么你可以直接看文章最后的总结。

　　我们所遇到的乱码多数情况是发生在有中文字符的时候，这是由于计算机各种编码的标准不同而造成的，首先我们有必要了解一下计算机编码的发展史，ASCII码、GB2312、GBK、GB18030、UNICODE、UTF-8、UTF-16、ISO-8859-1…，简而言之它们都是为了满足不同时期，不同对象的需求，以自己的一套标准尽可能多地表示所需要的符号信息，如果你需要了解得更深入，可以google一下相关资料。（PS:计算机领域的很多技术发展都是很有意思的）正是因为有这么多不同标准的编码存在，稍不留神我们就走入了编码“陷阱”，如何避免这些“陷阱”了？

　　一、注意文件编码和字符编码

　　用记事本建立一个新的文件，默认是ASCII码，我们另存为其他编码类型，例如unicode，如果用UtraEdit或者Emeditor编辑，你会发现编码类型的选择范围更大。试想一下如果在编码A类型的文件中存在了编码B的字符会有什么现象了？多数情况下会出现乱码。例如我们在一个文件编码为GB2312的网页文件中写入了UTF-8的字符，那么这个网页浏览的时候就出现了乱码，而我们在浏览器中再自己设定一下编码为UTF-8，页面就恢复正常了。当然也有例外情况，如果这两种编码是扩展关系，其中的部分字符编码是相同的，这个时候当然不会出现乱码了，例如GBK就兼容了BG2312的所有字符。（PS：这里有个有趣的现象，新建一个记事本，然后输入“联通”两个字，保存再打开，你会发现它变成了乱码。具体原因你可以google一下，简单说来是记事本错误地识别了字符编码。）

　　第一条原则：保持文件编码和字符编码的一致性。（PS：尤其是在客户端使用编辑器更改文件的编码类型时更要注意，有些编辑器只改变了文件编码，而没有将内部的字符编码同样做转换。）

　　二、指定网页编码

　　目前，主流浏览器都遵循RFC标准，他们会优先考虑服务端对Header中的content-type属性的设置，无论你是在server层做的全局设置，还是你的服务端脚本临时设置，你都需要清楚地知道网页否指定了你预定的编码。

　　如果服务端对Header没有做处理，那么浏览器会识别Meta信息中的content-type，例如，这个网页的编码就指定了是UTF-8，如果其中存在GB的字符，那么乱码就出现了。
　　
　　第二条原则：清楚地为网页指定我们预定的编码，最便捷的方式是在服务端指定。

(more...)