日志一览

Css Reset即是对浏览器的默认Css规则进行初始化，保证不同浏览器下Css的一致性。

目前有很多现成的Css Reset方案，不过都存在一定差异。毕竟Css Reset要经过大量不同浏览器的实地验证才能获得结论，所以对时下的这些Css Reset方案，也无法简单的判定好坏，只是列举出来对比如下。

考察对象是使用率比较高的三个：

• YUI
• Erik Meyer’s CSS Reset
• Condensed Meyer Reset

可以看得出Erik方案是不管三七二十一，对差不多所有的Html元素都做了重置，YUI则相对有选择性一些，Condensed方案比较折中。而对于几个独有的重置，则最好抱着宁可信其有的归纳整理比较好。

放上自己最后整理使用的版本

/**
* CSS Reset
* by YUI http://developer.yahoo.com/yui/reset/ and Erik Meyer http://meyerweb.com/eric/tools/css/reset/index.html
* Pack up by AlloVince http://allo.ave7.net/css_reset
**/
body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,form,fieldset,input,textarea,p,blockquote,th,td { 
	margin:0;
	padding:0;
	outline: 0;
	vertical-align: baseline;
	background: transparent;
}
body {
	line-height: 1;
}
h1,h2,h3,h4,h5,h6,address,caption,cite,code,dfn,em,strong,th,var {
	font-style:normal;
	font-size:100%;
	font-weight:normal;
}
table {
	border-collapse:collapse;
	border-spacing:0;
}
ol,ul {
	list-style:none;
}
:focus {
	outline: 0;
}
blockquote:before, blockquote:after,q:before, q:after {
	content: '';
	content: none;
}
fieldset,img,abbr,acronym { 
	border:0;
}
ins {
	text-decoration: none;
}
del {
	text-decoration: line-through;
}
caption,th {
	text-align:left;
}

◎　信用卡的问题已经解决，原因是某无良的空间商的擅自扣款，招行的应对态度还是比较令人满意的，能专门打国际长途过来询问，也承诺对款项进行调查，调查期间暂缓扣款。但从结果上来说，因为存在被扣掉的款项即使得到退款仍然需要全额还款这种NC规定，这次意外所带来的麻烦并没有因为客服的良好应对得到丝毫减少。只能自认倒霉了。

△　北妹DS一周目无烧毛通关之后，忽然没了多周目下去的动力。

果然像VP这样以独特的战斗爽快感取胜的游戏，结合SLG的后果就是将两方的优点都抹杀掉了。

战斗:VP从来都是4人编制才能打出一局理想的战斗，放在SLG里就已经产生了许多为了专门凑齐4人阵型而进行的无意义走位，偏偏还有众多需要救人的关卡，拼命赶路更是将VP的战斗美破坏殚尽。

仲間：原本以为战场上可以出现4人以上的战斗人员，那样就会有随机根据地形走位产生各种各样的组合，但这也只是单纯的YY。4人的固定编制，注定战场的规模不能太大，敌人也始终徘徊在10～20之间，更不要说SLG独有的防守，偷袭，援军等等全局性的战略。VPDS作为SLG的表现只能用4个字评价：小家子气。

系统：Karma的收集将Over Attack后的战斗收益最大化，也是本次VPDS我唯一觉得深得我心的地方。其他的系统则有些乏善可陈，装备没有损坏度，技能只能从商店获得，隐蔽宝箱可有可无……最让人无法忍受的是连敌人的移动范围都不能查看，战棋的棋字从何而来。

剧情：王位之争，战争叛乱，复仇主角，时有时无的语音……除了烧毛是相当腹黑的设定之外，全局的故事并没有特别出彩的地方，完全没有VP1中エインフェリア在生死间徘徊的震撼，即使选择不同分支从不同角度将剧情看个通透，仍显得如此单薄。

好吧，吐槽这么多也是于事无补，还是期待正统续作VP3的表现吧

□　近期电视剧总结

• 美剧编
  • PB : 果然没有危机感了就拿健康状况来说事么，还是快点完结吧
  • Heroes : 真怀疑编剧也不知道自己想要写什么，剧情的轴心在摇摆不定，Peter已经完全没有身为主角的存在感了，话说剧本的张力不是靠硬生生造出来的悬念就能撑得起来的。
  • Merlin : 能把魔幻剧拍的有单元肥皂剧的感觉，看Merlin实在很有喜感。不过依照目前的发展节奏，我怎么觉得看到了好深好深的一个坑……
  • Legend of the Seeker : 名著改编不好说什么，中规中矩的开头，不过面对其他众多如狼似虎的竞争对手，不应该早点把真家伙亮出来么
  • Crusoe : 谁来告诉我除了名字相同，这剧和鲁滨逊漂流记有什么关系……
• 日剧编
  • Bloody Monday : 除了用VNC入侵服务器很好很强大之外，暂时没有留下特别深的印象。
  • 夢をかなえるゾウ : 操着关西腔的无良神様倒是很有意思
  • OLニッポン : 其实这是一部主旋律片……
  • 流星の絆 : 詐欺はこんな簡単なものなんだ
  • ギラギラ : 为什么牛郎片总要拍的这么热血阳气呢

×　虽说迟了点，还是要补完TGS的下半部，内容主要是Cosplay。

日本的Cos给我的最大感受就是认真，明明已经站了好几个小时，但只要还有相机在，Coser仍然会专注的摆好每一个POSE。

不过与之相对的，对无断摄影非常反感，未经过Coser同意就在一旁偷拍是非常不礼貌的。所以人气的Coser面前往往是长长的队列……

好吧，闲话不多说，有图有真相-_,-

更多真相在此，为什么我感觉到杀气了呢×_×b

PS,宫崎骏美术馆计划泡汤，2008年内的票已经售空……

前情提要：基于ActionScript3的Flash Mp3 Player做成记录

这个连载很久没开了，不是没有做，而是因为写代码远远快过写记录，返回头去再写记录时反而不知从何说起。所以本次不如将目前的成果简单展示一下，也好更清楚的说明我到底想要做什么样的东西。

Demo如下，点击下面的链接即可实现播放暂停以及歌词同步展示。而在Html页面中仅仅提供了一个MP3链接，一个放置歌词的pre容器，整个页面即使失去了Flash和Javascript的支持，仍然不失良好的表意功能，并且能通过W3C Strict。

• Remi - 明日天気に．．．

[ti:明日天気に．．．]
[ar:Remi]
[00:01.59]明日天気に．．．
[00:05.87]作词：志倉千代丸 
[00:08.67]作曲：志倉千代丸 
[00:11.39]編曲：吉原かつみ 
[00:13.64]コーラス：中澤 里実
[00:15.67]演唱：Remi
[00:17.14]
[00:29.06]一緒にいたんだよね？（I feel your love）  
[00:38.42]気持ちも一つだよね？（dream come true it forever） 
[00:47.63]音もなくいつか
[00:52.35]穏やかなページに 
[00:56.54]聞き分けのない
[00:58.77]ノイズが溢れ出す 
[01:05.22]目の前に降り注ぐ
[01:09.86]この雨は天気雨 
[01:14.49]上がるように　おまじない 
[01:19.10]願いは叶うのかな？ 
[01:26.78]「サヨナラ」想い出の日
[01:32.56]出逢いも、あの場所も 
[01:37.32]離れて行くんだね　もっともっと 
[01:45.17]最後のその言葉を　聞こえないフリして 
[01:55.61]失って気付いた　あなたの声
[02:04.12]大きくなるよ 
[02:08.43]
[02:31.47]例えば沈黙とか（I feel your love） 
[02:40.60]それさえ気まずいよね（dream come true it forever） 
[02:49.94]他の誰よりも
[02:54.46]特別な存在 
[02:58.80]その瞳には　誰を映しているの？ 
[03:07.45]あても無く待ちわびる
[03:12.14]果たされぬ約束が 
[03:16.77]この胸を　揺らしてる 
[03:21.31]いつかは叶うのかな？ 
[03:29.10]天使がくれた季節
[03:34.89]想い出の詰まった 
[03:39.44]いつかまた笑顔になれるのかな 
[03:47.53]記憶に手をふっても
[03:53.32]離れてくれなくて 
[03:57.94]全ての繋がりが　切れたままで
[04:06.38]乱れているよ
[04:10.61]

完整的项目公开在Google Code里:

AvPlayer Google 项目页

规划和目标如下

• 编译后Swf文件控制在10KB以内
• 简单的页面嵌入(1行Js代码)
• 丰富的Javascript API，可以实现完全基于Html页面的操作控制.
• 可以作为Mini播放器单独嵌入
• 支持Json/xml等多种格式的播放列表
• 基于Javascript的歌词LRC实现
• 页面通过W3C Strict验证

有兴趣的同学不妨在Issues里提出意见或者功能需求。

◎　信用卡帐号上突然莫名其妙多了一笔Dot5Hosting的100多美刀的账单，看着半年多没动过的招行信用卡不禁苦笑。被盗？木马？外星人？心灵感应？虽然我不介意给别人买一次单，但希望可以等到招行给我一个合理的解释。

△　RP的美剧大爆发，PB是死人变活人，Heroes是好人变坏人，编剧已经急功近利到用抽自己耳光的方式来制造悬念了么。比较期待的Merlin还在不温不火的引导勇者穿越。剩下的鲁滨逊又能翻出什么样的花样呢？

□　七街新版发布终于在某L的不懈努力下终于要提上日程了，而自己只能抽空补完一下AVplayer。想法很多，时间很少，偶尔在睡梦中怀念一下大学时代那猪一般的生活，这就是现实吧。。。

×　论坛上有同学提到「コインのウラオモテ」，就顺手翻译了Vol.43的志方の呟き。说起来没去上周的M3还是有点遗憾的，恩，等明年吧。

以下是译文，原文由于无断转载禁止，所以自行订阅获得吧。

夏天已经过去了，已经变成了带着秋意的季节了呢。
晚上有点冷，这里是忍不住用被子把自己包起来，像结草虫(*注1)一样工作着的志方。
今年的夏天也是，一直关上房门工作着，季节好像从春天直接跳到了秋天，感觉很奇妙。

说起来最近的志方，对便利店里卖的"手まりすあま"(*注2)非常着迷。
本来是不怎么喜欢带馅儿的食物的人，又很喜欢馒头呀大福的皮什么的，
所以就非常喜欢这种甜而不腻的"手まりすあま"。
而且，看起来也很小，圆圆的，粉红色很可爱的样子，
还有吃的时候那种软软的口感，简直像被治愈了一样。
每天在休息的时候，就着热茶一起吃的短暂歇息是十分愉快的，
不过还要注意不能吃太多了变胖了呢……

从秋季开始一直到冬季，都会是努力制作第三张Album的时期，
现在也正在集中精力工作着。
不过，总是把神经绷太紧的话，
不但不能保持从容的创作态度，好的想法也出不来，
所以身心必须要适当的放松才行。
大家有什么推荐的自我放松方法，
告诉志方的话我会很高兴的。

注1：英文名是Bagworm，幼虫会织出袋状的蛹把自己裹起来。恩，很形象的比喻了，有兴趣的话可以搜索关键字Bagworm看图片。

注2：手まり是用线织成的用手拍着玩的小球，以前新年时候小姑娘会拍着手まり边唱歌玩。すあま是米粉和砂糖做成的饼状点心。两者组合的样子大致想象的出吧。

さあ、行こう!GAMEの時間です。（来吧，出发！到游戏的时间了。）

很喜欢本次TGS的标语。没有工作，没有学习，数十万人只为喜欢的游戏而来。看到不同国籍，不同肤色，不同年龄的人，瞪大了眼睛团坐在大屏幕下面，为即将到来的游戏时而惊讶，时而欢笑，时而激动，就会觉得游戏才是真正无国界的东西。或许把这样的信念传递给每一个来客，才是游戏展的意义吧。

以下是本次TGS的7788

KOEI

KOEI的展台正好是入口第一个，可谓占尽天时地利。刚刚进场就看到大航海时代OL这种人气游戏，排队等候牌毫不含糊的打上了120分钟的标签。

无双系列已经成为暗荣首屈一指的摇钱树，继360和PS3版后仍然余韵未尽逆移植的无双5P姑且不提，无双OROCHI魔王再临和无双卍解还是值得期待的，从宣传动画来看无双卍解协作对战的成分有很多，难道是想模仿MH？

SQUARE ENIX

今年后半年最期待的游戏莫过于SEX社的Valkyrie Profile 咎を背負う者，经历了一个多小时的等待，终于能亲手试玩了一下。虽然北妹2毁誉参半，让我大大的失望了一回，但这个系列能够延续下去，或许终会有超越自己的一天。

北妹DS最让人担心的无非有两点：DS平台和SLG的战斗模式。既然DQ9都可以出在DS上，那么前者自无需多言。后者就试玩版的情况来看，与以往的迷宫式探险是各有得失的。SLG战场可以容乃4人以上的战士，加上地形位置，从而产生更多组合和变化，不会留下很多万年板凳。但SLG战斗节奏慢，没有迷宫探险的紧张感和动作要素。究竟会如何，还是等11月1日正式版发售吧。目前值得欣慰的是VP2最让人诟病的形同虚设的战魂终于回归到VP1那种厚重的故事模式中了，战斗的手感也是很接近VP1的。

在FF13自宣布跨平台以前，SE社的重心就已经明显偏向了M$，Infinite Undiscovery，Last Remnant，Star Ocean4的三作连发十分华丽。不过人物建模也出奇的相似，大概是同一个开发引擎吧。

SE社除了上面那面墙以外都禁止拍摄，FF也是封闭式发布，Show Girl也是裹着黑色的衣服，甚是神秘。

Mircosoft

一改凶箱时代每周个位数的悲惨遭遇，Xbox360可谓顺风顺水，除了偶尔的三红问题让大门同学皱一下眉头之外，未来在神机Wii之下Xbox360和PS3两大并立的局势已经毫无悬念了。TGS上M$也是一如既往的财大气粗，配备了大量的液晶电视和叉一圈，使得排队时间并不长，遗憾的是仍然禁止拍摄。

TECMO

TECMO绝对是TGS上最会作秀的厂商（非贬义），从会展一开始，各式各样的活动就没有停止过，活动中不禁止拍照。展台旁边还停放了一辆汽车，Show Girl们不间断的结队展示着香车美女的无穷魅力。大概一半的胶卷，都会被谋杀在TECMO的展台吧。

SEGA

SEGA的展台最瞩目的还是如龙3的发布会，巨大的花篮，道贺的嘉宾，怎么看也不像是游戏发布会的样子。非常遗憾的是绕场三周也没有找到三国志大战相关的一点点资料，难得看到平衡做的这样好的卡片游戏了。

Level5

Level5的白騎士物語总是雷声大雨点小，在你快要忘记他时候，又会适时的放出一点资料。大概Level5在决定开发白騎士物語也没有想到PS3会落得如此的窘境吧。不过好在有DQ9这只稳赚不赔的摇钱树在，倒也不算是太大问题。

大概是因为开发了DQ9这样超大作的缘故，Level5最近放出的一批DS新作的画面质量达到了让人惊异的程度，二ノ国、レイトン教授と最後の時間旅行都是值得期待的作品。

CAPCOM

CAPCOM在TGS2008上重拳出击，BIOHAZARD 5、Street Fighter 5、Monster Hunter 4 的同时公布让CAPCOM展台的排队时间从来没有少于两小时。同行的日本小伙在经过两小时排队之后，还华丽丽的得到了一条纪念头巾。不过好在这次BIOHAZARD 5再没有玩XX平台独占的把戏，反正迟早会移植的，地球人都知道-_=

SNK

SNK虽然一直不景气，不过KOF的群众基础还是非常雄厚的。SNK的展台也是以邀请游客对战为主，不时有民间高手出现，引来满场惊呼，很是热闹。

KONAMI

KONAMI的展台很简单，大致是WE和MGS各占1/3，剩下的空间基本都留给幻想水滸伝DS的宣传。MGS4毫无疑问已经是PS3上最成功的游戏，KONAMI也毫不客气的打出了PS3销量最高的招牌。MGS的展台前循环上演着伪装成特种兵的工作人员的军事训练解说（其实是游戏操作解说- -）。

由于涉及到本地和服务器两方面的安全问题，所以基于input type="file"形式的页面文件上传一直处于一个很尴尬的位置。一方面，用户不希望隐私泄露，所以浏览器无法对用户在上传时选择的文件做有效的判断。另一方面，为了服务器端的安全，减轻传输负担，系统又希望能在用户开始上传之前就将非法的文件拒之门外。

一来一去，基于原始input方式的上传，成为网络存储网站避之唯恐不及的遗留性问题，也造就了现在千奇百怪的插件、上传客户端。

input方式的上传就如此之差么？当然不是。上传文件不大的时候，它还是非常简单可靠的，在PHP中，我们只需要一个复合型表单

<form enctype="multipart/form-data" action="__URL__" method="POST">

一个输入框

<input name="userfile" type="file" />

和服务器端的一行代码

move_uploaded_file($_FILES['userfile']['tmp_name'], '/var/www/uploads/'. basename($_FILES['userfile']['name']));

就可以实现整个上传过程。

但随文件增大，表单上传的不足就会暴露出来。尤其是我们想取得最基本的文件大小来阻止过大文件上传这一简单的想法，也变得如此困难。以下一一道来：

通过MAX_FILE_SIZE

我们经常会在手册里读到:

MAX_FILE_SIZE 隐藏字段（单位为字节）必须放在文件输入字段之前，其值为接收文件的最大尺寸。这是对浏览器的一个建议，PHP 也会检查此项。在浏览器端可以简单绕过此设置，因此不要指望用此特性来阻挡大文件。实际上，PHP 设置中的上传文件最大值是不会失效的。但是最好还是在表单中加上此项目，因为它可以避免用户在花时间等待上传大文件之后才发现文件过大上传失败的麻烦。

显然PHP的开发者们也考虑到了大文件上传的问题，但就像手册所说，MAX_FILE_SIZE只是对浏览器的一个建议，事实上目前为止所有主流的浏览器并没有采纳这个建议，所以采用MAX_FILE_SIZE约束文件大小形同摆设，不可行。

通过服务器端

MAX_FILE_SIZE既然无效，那么用户可以将文件上传到服务器，服务器端通过$_FILES['userfile']['size']判断用户上传的文件大小，然后决定是否接受上传并返回信息。暂且排除服务器的负荷以及可能存在的恶意破坏行为，这种解决方案听起来无非是浪费一部分带宽，也能对用户上传文件作出约束。

但这也是不可行的，PHP的文件上传受到php.ini以下这些设置的影响:

• post_max_size
• upload_max_filesize
• max_execution_time
• memory_limit

虽然设置方法在手册中都有比较详细的说明，之所以仍然说此方法不可行，是因为php执行脚本在超过memory_limit时，该次的POST数据会全部丢失并且不会报错！

试想用户填写了一个超长的表单，并伴随一个超过memory_limit的文件一起上传，经过了漫长的等待时间之后发现等来的又是一张干干净净的空白表单，那是何等印象深刻的用户体验啊。更何况数十M的服务器流量仅仅用来检测文件大小，是现在的网络环境不允许的。

通过Javascript

Javascript是基于浏览器的，虽然JS能完成很多看似不可能的任务，但浏览器做不到的事情JS同样无法做到。先天不足注定了这项工作仅仅靠Javascript是无法胜任的。不过一些IE Only的方法也还是存在的，仅作参考。

通过Flash

Flash的FileReference类提供了一套比较全面的文件处理方法，现在大多数大文件上传也都采用了基于Flash的方案。如果利用Flash与Js交互，能否实现客户端对文件大小的检测呢？答案是可行的。

首先在flash文件中实例化FileReference类。

var fr = new FileReference();

基于这个类就可以用Flash提供的file browse和SelectFile事件替代浏览器的事件。我们需要：

1.绑定SelectFile

fr.addEventListener(Event.SELECT, onSelectFile);

2.创建一个供Js访问的对象，用来放置flash得到的文件信息

var s = {
	size:0,
	name:'',
	type:''
}

3.创建file browse方法

function browseFile():void {
	fr.browse();
}

4.当SelectFile事件触发的时候，传递文件信息

function onSelectFile(e:Event):void {
	s.size = fr.size;
	s.name = fr.name;
	s.type = fr.type;
}

5.将browseFile方法公开可供Js调用

ExternalInterface.addCallback("browseFile", browseFile);

6.将得到的文件信息传递给Js

ExternalInterface.call("onSelectFile",s);

现在我们已经可以通过Js获得由flash传递来的文件大小信息了，具体的实现可以参看Demo。

结论

问题至此似乎已经得到解决了，我们已经成功的校验了文件大小不是么。但本文的最终结论是，基于Flash的文件大小校验，仍然不可行。

文件大小校验的唯一目的，是为了上传。在上面的Demo中可以看到校验成功的文件名会显示在一个输入框里。熟悉上传的同学不觉得少了什么吗？没错，通过flash只能得到文件名，而无法得到文件的完整路径，而文件路径却是input方式上传的必要条件。所以虽然可以成功的通过Flash与Js交互校验文件大小，但我们能做到的也仅仅只是校验而已，之后想要上传，唯有继续通过flash方式进行。

Flash开发出于安全考虑屏蔽了文件的完整路径这无可厚非，不过文件上传，尤其是PHP环境下的文件校验上传方案仍然没有得到最好的解决。

当然弥补的方法有很多：

• 基于Perl的项目 FileChucker , XUpload , Uber-Uploader
• 基于Flash的项目 SWFUpload
• 还有筒子用PHP直接在服务器华丽的建立socket链接。

但终究我希望有一天能看到仅基于HTML就能实现的严整健壮的上传方案，但愿这一天不会太远。

最后是本次的代码下载。

前情提要：基于ActionScript3的Flash Mp3 Player做成记录

如何绑定事件

播放器最基本的功能莫过于播放，暂停和停止，本次便来完成这三个功能。

在Code之前，必要的UI搭建是不能少的，这里建立了三个按钮并依次命名实例为：

• 播放按钮：buttPlay
• 暂停按钮：buttPause
• 停止按钮：buttStop

当然怎么做Flash按钮并不在本文的讨论之列，这里一笔带过。

有了按钮，很自然的会想到如何在按钮上绑定事件，幸运的是在经历了AS1、AS2的空前混乱之后，AS3.0中终于将事件的绑定统一为唯一的addEventListener方法，除此之外别无他路。例如

buttPlay.addEventListener(MouseEvent.CLICK,onPlay);

就是在buttPlay按钮上绑定了一个名"onPlay"的函数，这个函数在鼠标点击时触发。这种绑定类似于Javascript的addEventListener，写过Js的同学应该很容易接受。

所以现在我们只需要对每次按钮绑定事件，然后分别编写每个事件的函数，就实现了最简单的与用户的UI交互：

function onPlay(event:MouseEvent):void {}
function onPause(event:MouseEvent):void {}
function onStop(event:MouseEvent):void {}

buttPlay.addEventListener(MouseEvent.CLICK,onPlay);
buttPause.addEventListener(MouseEvent.CLICK,onPause);
buttStop.addEventListener(MouseEvent.CLICK,onStop);

设置全局变量

现在可以正式开始了么？很遗憾，在深入到每个事件之前，我们首先要考虑怎么设置全局变量。这是由于addEventListener式的事件绑定虽然便于管理，但可能实际一操作就会发现，要向绑定的函数中传递参数，解决的方法只是在函数外设置全局变量。

在这里我们设置了4个全局变量：

//当前请求的Mp3文件
var _req:URLRequest;
//声音基本类
var _sound:Sound = new Sound();
//声音播放控制
var _channel:SoundChannel;

var _status = {
	firstClick:false,
	loadComplete:false,
	isPlaying:false,
	pausePosition:0,
	length:0,
	played:0,
	volume:0.7
};

这里定义的_status包含了正在播放声音的所有必要信息，所有的操作通过这个变量联系起来，是播放器控制的核心：

• firstClick：是否是第一次点击，第一次点击需要读入文件
• loadComplete：声音文件是否已读取完毕
• isPlaying：是否正在播放
• pausePosition：播放暂停的位置
• length：声音文件的长度
• played：已经播放的长度
• volume：音量大小

播放操作

现在终于可以进入到第一个事件里了。来考虑一下当点击播放按钮之后，播放器应该做些什么：

• 如果声音已经开始播放，不做任何操作
• 如果是第一次点击，那么文件还未读入，首先要将MP3文件读入
• 读入之后开始播放，将状态firstClick和isPlaying置为true
• 为了知道是否已经播放完毕，还需要对播放完成（SOUND_COMPLETE）这个时间进行监听

转换成代码就是

function actionPlay() {
	//已经开始播放
	if (_status.isPlaying == true) {
		return false;
	}
	//首次点击
	if (_status.firstClick == false) {
		_req = new URLRequest("test.mp3");
		_sound.load(_req);
		_status.firstClick = true;
	}
	//开始播放
	_channel = _sound.play(_status.pausePosition,1);

	//初始化暂停位置
	_status.pausePosition = 0;
	_status.isPlaying = true;

	//增加完成监听
	_channel.addEventListener(Event.SOUND_COMPLETE, onPlaybackComplete);
}

至于播放完毕后的监听，是为了将状态信息清零以便不影响到以后的播放。

function onPlaybackComplete(event:Event) {
	_status.isPlaying = false;
}

停止与暂停

对于暂停操作，首先要明白一点：AS3中并没有提供"暂停"声音播放这样的功能，要实现暂停，只能每次记录播放位置，将声音停止，然后再从停止的位置开始播放。

清楚了这点，那么可以知道停止和暂停操作唯一的区别就是是否记录播放位置，所以这里将播放位置作为入口参数构造出停止操作：

function actionStop(position = 0) {
	if (_status.firstClick == true) {
		//停止播放
		_channel.stop();
		//记录停止位置
		_status.pausePosition = position;
		_status.isPlaying = false;
	} else {
		trace("Nothing to stop");
	}
}

然后在有了停止和播放两个操作的基础上实现暂停功能：

function actionPause() {
	if (_status.pausePosition == 0 && _status.isPlaying == true) {
		actionStop(_channel.position);
	} else if (_status.pausePosition > 0 && _status.isPlaying == false) {
		actionPlay();
	} else {
		trace("Nothing to Pause");
	}
}

整合

将写好的动作嵌入绑定的事件里，一个具有播放，停止，暂停功能的播放器便初步完成了。

function onPlay(event:MouseEvent):void {
	actionPlay();
}
function onPause(event:MouseEvent):void {
	actionPause();
}
function onStop(event:MouseEvent):void {
	actionStop(0);
}

当然不要忘记引用所有用到的类

import flash.events.*;
import flash.media.*;
import flash.display.*;
import flash.net.URLRequest;

最后仍然是本次代码下载

前情提要：基于ActionScript3的Flash Mp3 Player做成记录

都要做些什么

动手之前，首先要做的是理清楚一个播放器可能包括的功能模块，然后从简到难，一步一步完成。让我们列个单子：

1. 读入声音文件
2. 声音的播放与停止
3. 计时器
4. 文件读取进度条
5. 声音播放进度条
6. 在进度条上可拖拽的游标及改变播放位置
7. 音量与声道控制
8. 读取MP3 ID3 Tag
9. 将信息放入外部文件中
10. 文件列表的播放
11. 搭建外部接口
12. 歌词功能

细节会有很多变化，但大体上是这些基本的功能组成了一个音频播放器。本记录也会按照这个顺序进行。

从面向过程开始

OOP的AS3，为什么要从面向过程开始？其实这只是属于个人习惯，从面向过程开始，可以最短时间内看到做出来的东西，也可以随便修修补补，权当在打草稿。OOP的整理，会放在基本模型搭建完毕之后进行。所以本记录将有很长一段时间停留在面向过程的层面。

总之先发出声音

为了证明上面的话，我们可以用最短的时间先折腾出一点声音来让气氛轻松一点。

用Flash CS3新建并保存一个名为avplayer.fla的文件，同目录下放置名为test.mp3的音频文件。点击F9呼出动作窗口，然后输入以下代码。

import flash.media.Sound;
import flash.net.URLRequest;

var _s:Sound = new Sound();
_s.load(new URLRequest("test.mp3"));
_s.play();

然后按ctrl+enter，不出意外的话，现在已经能够听到美妙的音乐了。恩，Mp3 Player并不是很难的东西。

最后放上本次的代码。

1. 序言
2. Hello Player
3. 播放、暂停与停止
4. Demo及项目页

罗嗦的前言

其实想做一个自主开发的Web Mp3 Player已经有很久了。作为一个懒人，如果产生了要做什么的想法，那最大原因一定是现有的东西无法满足需要。

或许只是程序员蜀黍的劣根性使然，目前的Web Mp3 Player项目中并不乏优秀的作品，但在一一试用之后还是决定自己开发，不过还是稍作列举：

JW FLV MEDIA PLAYER

JW FLV MEDIA PLAYER是历史很悠久的项目了，从最初的一个简单的Mp3播放器不断改进到现在的音乐图片视频通吃的全能型Media Player，作者一直在努力。

基本上已经是比较完善的作品，可以自己制作皮肤，Js的API也比较丰富，不过如果用做扩展开发的话，不开源这一条就可以枪毙了。

Dewplayer

采用Dewplayer的网站非常多，简洁的外观，5KB的体积非常适合嵌入各类网页和Blog。现在最新版也提供了简单的Js接口。

不过很遗憾这也不是开源产品，作者还准备了Pro版本赚钱，功能简单，用用就好。

Flowplayer

Flowplayer也是屡次出现在开源项目推荐榜上的名字，我了解不多，也许是因为Licence的问题，应用没有想象的广泛。

WordPress Audio Player

看名字也知道WordPress Audio Player是专为WP打造的，不过即便如此，将播放器部分独立出来也是很优秀的作品。本Blog一直以来也是采用着Audio Player。

非常简洁的设计，所有部件都是用AS脚本渲染生成，颜色可以在客户端做自定义。很巧妙的设计了JS接口：如果页面内有复数个Audio Player时，播放其中一个，其他正在播放的都会自动关闭。

Yahoo! Media Player

Yahoo!出品，强大令人赞叹的作品，强大之处在于Yahoo! Media Player同时利用了Windows Media Player的接口和Flash技术，极大限度的保证了使用者无需额外安装插件。使用方面也是简单到了只需要引入Js文件后就可以自动侦测页面的所有指向Mp3的超链接生成播放器。

但也正是由于这样过度的封装，完全没有自定义和二次开发的余地。Yahoo! Media Player更像是观赏品，实用价值不高。

啰啰嗦嗦这么多，以上这些项目都不能让我满意的原因有三：

• 暴露Mp3地址，曲目管理功能弱
• 不支持歌词功能
• 很难进行二次开发

所以从下一次日志开始，将记录一个基于ActionScript3的Flash Mp3 Player的做成过程。暂定项目名「AVplayer」 -_,-

PS。订阅的RSS快被铺天盖地的Chrome新闻淹没了，怎么说Chrome还只是一个试验品，连最基本的CSS渲染都存在错误，占据市场份额更是不着边际的事情，Google还是快点着手修复目前的BUG吧。

Yahoo!曾经针对网站速度体验提出了34条宝贵的准则《Best Practices for Speeding Up Your Web Site》，而Yslow正是按照这些准则，评测一个网站在速度体验上的优化程度的Firefox插件，将34条精简为更加直观的13条，并针对每一条给出从F~A的评分以及最终的总分。

当然从评测得到的只能是一个分数以及建议，如何改进还是要靠自己，这里要谈的就是实实在在的如何针对每一条进行优化：

1. Make fewer HTTP requests / 减少Http请求数

一个网页不可避免的要引入大量的外部文件：Javascript、css、背景图片……由于Http协议的无状态性，用户的每一次访问，都会重新向服务器请求所有文件，而大量Http请求的累加，正是影响网站速度的最主要原因。

所以这里的解决方法只有一个：合并。最理想的情况莫过于一个网页只包含一个css，一个js，一张背景图。

合并Js和Css文件很好理解，背景图片要怎么合并？这里采用的主要方法是CSS Sprites，简单说就是把所有的图片拼接成一张大图，在不同的Css里指定背景图坐标来显示不同图片。具体可以参考Dave Shea的Image Slicing’s Kiss of Death一文，还有网站提供了在线的CSS Sprites服务，只需要上传小图片，就可以获得拼接后的大图以及相应坐标。

不过在当前越来越多动辄包含10余个文件的开发框架面前，减少Http请求数也变得越来越难。一直都认为所谓框架，给出的应该是一整套完善的开发思想，从服务器配置到数据库设计甚至是到UI体验乃至SEO，但现在很多Framework总是各自为战，后台与前端脱节，只在自己的一片领域里提供一定程度上的方便，没有考虑到最终产品的统合，甚至连基本的代码侵入性问题没有处理好（这里点名批评dojo，恨不得在所有的html标签上印上dojo的章子），不能不说是一种遗憾。

所以如果网站中采用框架的话，在框架的选择面前，建议多采用轻量级，侵入性低的框架，也是为了日后产品的优化维护着想。

2. Use a CDN / 使用CDN

CDN(Content delivery network)内容分发网络，能够智能根据网络节点情况选择服务节点，大型网站部署时尤为重要。不过这属于硬件级别的解决方案，我们没有条件配置CDN的时候，可以自行设置忽略这一项评测。

在Firefox地址栏键入about:config，然后新建一个字符串，名称为extensions.firebug.yslow.cdnHostnames，值为所要评测网站的域名，多个设置用逗号分隔。例如我的设置就是allo.ave7.net,localhost

3. Add an Expires header / 为文件头指定Expires

Expires是浏览器Cache机制的一部分，浏览器的缓存取决于Header中的四个值： Cache-Control， Expires， Last-Modified， ETag。这个项目的考评主要针对Cache-Control和Expires。

具体的Cache原理不是本文所涉及的，有兴趣的同学可以看看Caching Tutorial一文。为了优化这个选项，我们所要做的是对站内所有的文件有针对性的设置Cache-Control和Expires，这里基于Apache主机举例：

首先开启mod_header模块，在httpd.conf中取消

LoadModule headers_module modules/mod_headers.so

一行的注释。然后对于图片，文件等不会经常更新的文件设置一个比较长的过期时间

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Expires "Thu, 15 Apr 2010 20:00:00 GMT"
</FilesMatch>

对于Cache-Control可以设置的更加细致一些，这里我对图片，文件设置了1周，对XML，TXT设置了5小时，对html和php文件只设置了1小时。

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>

<FilesMatch "\.(xml|txt)$">
Header set Cache-Control "max-age=18000, public, must-revalidate"
</FilesMatch>

<FilesMatch "\.(html|htm|php)$">
Header set Cache-Control "max-age=3600, must-revalidate"
</FilesMatch>

另外Expires也可以通过开启mod_expires来实现，这里不再举例。

4. Gzip components / 启用Gzip压缩

HTTP/1.1支持接收服务器端经过Gzip压缩的数据，在Apache2中，可以开启mod_deflate实现。

同样去掉注释

LoadModule deflate_module modules/mod_deflate.so

然后对所有文本类文件添加Gzip处理

DeflateCompressionLevel 3
<FilesMatch "\.(php|htm|html|js|css)$">
SetOutputFilter DEFLATE
</FilesMatch>

5. Put CSS at the top / 将Css文件放在头部

很好理解的一条，主要是为了避免最后加载Css引起的浏览器白屏，改善用户体验。

6. Put JS at the bottom / 将Js文件放在底部

同样很容易理解，为了让DOM先行加载。

7. Avoid CSS expressions / 避免CSS expressions

CSS expressions可以轻易的引起浏览器假死，也不在W3C规范内，不只是避免，最好完全不要用。

8. Make JS and CSS external / 将Js和Css文件独立

将Js和Css文件单独做成外部文件加载，一则可以功能复用，二则可以生成缓存，当然这一条和第一条要互相参照找出最好的解决方案才是。

9. Reduce DNS lookups / 减少DNS查询

外部文件分散于多个服务器，连接每台服务器都会做一次DNS查询，这一条是针对多服务器的部署。

10. Minify JS / 压缩Js文件

压缩Js文件，Yahoo!官方推荐的工具是JSMin和YUI Compressor。

11. Avoid redirects / 避免重定向

每一次的重定向都会重新发送Header请求。所以在Apache下，无比强大的mod_rewrite是必须要学的。

12. Remove duplicate scripts / 移除重复的脚本

开发中没有规划好，会出现页面中重复引用一个文件的情况，IE中即便是重复引用也会重新向服务器发送一次请求。

13. Configure ETags / 配置ETags

在第三条中已经对浏览器缓存机制中的Cache-Control和Expires进行了配置，这一条评测的是另外两个：Last-Modified和ETag

简单的说，即使设置了文件的期限，浏览器在访问资源时往往会因为Last-Modified和ETag而重新下载整个资源，所以简单的做法是关闭Last-Modified和ETag

在Apache中做如下配置

FileETag None

<FilesMatch "\.(ico|pdf|flv|jpg|jpeg|png|gif|js|css)$">
Header unset Last-Modified
</FilesMatch>

最后看看优化后的成果