army8735

http://code.google.com/p/jssc/

众人拾柴火焰高，经过一段时间的发布和回馈，jssc4.1的版本公布出来，以供开发者们使用。这次做的比较大的革新有：css控制，自定义颜色，标记语言增强，jsp语法支持，预留接口。

1.除却高亮颜色部分外，其余已经尽可能地交由css控制。我想这也是所有人都希望看到的。

2.为了保持对word等富文本复制的功能，一定程度上牺牲了css控制高亮颜色的便捷。不过除了默认颜色外，可以使用对外提供的reset方法来重新自定义颜色。比如目前的示例就是使用：

reset({
  js:  {
    key: "f33"
  },
  java: {
    key: "39f"
  },
  as: {
    key: "333",  num: "333", string:  "333"
  }
})

重新定义了js、java、as的部分颜色，这也是为什么看上去显得很怪异的原因（我为了让效果更醒目点，当然你可以设置得比我这漂亮多了）。reset()传入一个object，里面的动态属性设置可以参照Config.as文件。

3.对于html、xml的支持被增强了。一些自封闭标签的折叠功能被修正，同时还有另外一些隐藏的bug也被修复。

4.在一些人的大力支持下（我想同时也是要求下@_@），jsp语法被支持。值得注意的是，jsp的高亮颜色并不能直接被自定义。因为jsp解析是继承html的解析并内置组合了一个java解析器，因此颜色部分是由html和java共同决定的，更改另外两者的同时就等于更改了jsp。
示例中jsp颜色的怪异就是因为java的部分颜色被我故意改乱了。

5.在init()方法的第三个参数中，多出了一个留下来的方法接口。它的作用是当客户端不支持flash player或者版本不足时使用这个方法，比如可以异步加载sh或者jssc老版本等。

最后的话是我在上传jssc4.1时发现syntaxhighlighter的2.0信息也被公布了，我没细看。呵呵，不知道它会带来哪些变化。我所希望的就是那个预留方法可以使用sh2.0。

最近实验JAte的缘故，发现了2个很恶心的bug。jssc4的制作已经发现ie的一个ExternalInterface的恶心地方了，没想到现在又发现2个。

1.jssc4中发现的bug：
当出现js通过ExternalInterface接口调用as，as接受请求通过ExternalInterface回调js时，如此循环ie下有6次的上限，其余浏览器未发现。
解决办法是在js调用as时，把调用这句话放在一个function中，然后setTimeout(function, 0)即可。

2.JAte实验bug之一：
用adobe推荐办法取得swf对象时，如果有js的方法对象存在与swf相同id或name的情况，window[swfname]在ie下会取得js的方法对象而不是swf对象。这是个很诡异的地方，因为alert测试都会输出object，不过前者是[object Object]，后者是[object]。输出其tagName便可发现，前者undefinded，后者是OBJECT。

3.JAte实验bug之二：
依然是as先调用js，然后js回调as。假如页面中写好一个test()方法，然后加入swf，再as去调用它，它再回调as，一切正常。
如果是用js产生swf对象（即js先createElement一个div，div的innerHTML是加入swf对象的html代码），as先调用js一切正常，js再回调as的话……虽然能找到这个swf对象，但恶心的是，ie下会报错说没有这个方法，其它均正常。

自从jssc ver 3 rc版发布之后，我就因为刚毕业而一直处于半消失状态，因此很长一段时间也没有更新。期间收到很多朋友们的来信，社区消息也好、qq也好、msn也好、email也好，总之是不少。许多建议都是很有价值的，当然也是很有难度的，嘿～

好吧，闲话不说，jssc4的新版本终于即将来到，而它将带来什么变化呢？请往下看：

1.平台变迁。

其实在叫《jssc》这个名字有点儿不适合了，因为它已经“不纯”了。不过为了延续习惯，还是继续下去吧。之所以“不纯”的原因，原因是分析处理的大头已经放在了as上，js只是以调用和生成者的身份出现。

2.速度提升。

js来执行高亮分析的性能一直是让人头疼的问题，即使jssc2已经做得很好了，但依然不容乐观。显然，解释执行的js代码不仅慢，而且在各个浏览器上的表现都不一样。那么为何不另辟蹊径呢？

jssc4中主要的分析工作变成了由action script 3来执行，as3的速度和跨平台甚至对oop支持可好得太多了。于是这样做带来的速度提升，是显而易见的。

3.富文本复制。

fins希望在选择代码后复制到word等编辑器中能够连带颜色一块儿复制过去，这在之前的版本中是无法办到的。因为若要复制，高亮后的结果必须是<font color=”(color)”>code</font>或者<span style=”color:#(color)”>code</span>的形式。若想纯js办到，需要牺牲掉很多东西。然而在jssc4中，这些都可以了，因为这一切都是在flash编译期间完成的事。

4.扩展。

这可能是需要特殊提及一下的事情了。

jssc4由于主分析工作是由as3来完成的，因此若需要修改、扩展等，都必须修改as代码重新编译才行。想要定制自己的高亮器的话，都必须这样做。

5.大小。

可以看到swf文件目前只有8k多，编译成abc字节码后大小的确很令人惊喜啊。

—

当然有人会这样问：极少数人的浏览器没有flash播放器或者级别太低怎么办？

答案就是不支持的话代码不会被高亮，仍旧原样显示，这算是一种折中吧。代码放在pre或者textarea里，定义好css，也不会乱。

制作过程中仍旧有许多问题，解决后有很多心得，将陆续发布出来讨论。一些改进仍需，请回帖发言……

《Fantasy Sky》的进展顺利，一切继续着。今天下午把10种职业基本补齐了，除了小偷还缺4张截图，小事而已。于是想来张全家福，突然发现bug。

同时登陆多个账号时，头几个显示还正常，后面的就看不见前面同张地图内的人了。debug半天，发现数据完全正常，接收发送都处理到了，可真杀死脑细胞啊。

最终在客户端想了个办法把每次socket接收的数据都打印出来看看，终于发现问题所在：

swf在接收socket的数据时，是用触发侦听进行的。然而可能服务器端两次发送的数据由于延迟原因同时到达客户端了，此时由于程序编写的问题，就会出现冲突。

比如接收到 str1 这一段数据，客户端判别应该生成一个人物a；接收到 str2 就该生成b。由于延迟，二者合到一起了，客户端读取的是 str1 + str2 的内容，错误就出现在这里了。

解决得办法就是换用xmlsocket对象，它用\0字符为结尾标识每次传送数据的结束，不会起冲突；又或者仍然用低层的socket对象，它有readInt()方法，可以每次在数据开头设个长度，用来标识此次接收多少字节。

前者容易，后者更强大。综合来说，我先用前者试一试。

缩小讨论范围，仅限常用的浏览器：ie和ff；仅限常用的搜索引擎：google和百度。

先看google：搜索关键字时由于页面编码也是utf8，所以等于直接encodeURI后添加到url后面；
再看百度：由于页面编码是gb2312，所以关键字编码相当于urlencode后添加到url后面。

于是，矛盾就出现了。假如从搜索引擎搜索后点击链接连到我们的页面，想根据document.referrer来提取出关键字，再交给后台处理一下，最后返回显示的时候，google就和百度战起来了……

这还不算什么，即使一段相同的encodeURI编码传给后台处理一下，再通过ajax返回前端显示的时候，ff和ie也战起来了……

好吧好吧，这两对儿真是恩恩怨怨反复纠缠你死我活鱼死网破啊！最终还得我们来辛辛苦苦任劳任怨兢兢业业毫无怨言地来调节。

—

首先，从document.referrer提取出的关键字要根据来源判断，从google来的是utf8，从百度来的是gb2312。传给xhr时加一个参数标明来源，再加个参数判断标明用户使用浏览器。

然后，后端处理的php逻辑页面，必须改为utf8编码的文件。通过判明来源和浏览器种类分别处理：ff下的gb2312就转换为utf8；ie下无论什么都转为utf8。

最后，在前端gbk编码的情况下显示，终于结果正常了……

—

其实这种情况足以应付大多数需要了，因为搜索引擎编码我们常用的不是gb2312就是utf8，像yahoo、qq等。而浏览器除了ie也就ff、极少数用标准的opera什么等等等等等。

这次实验证明了：跨国婚姻矛盾多啊！性格不合是最主要的原因！