army8735

本着想写系列文章《web端语法高亮原理：走进jssc的世界》，介绍jssc的历史和核心算法的，结果无意间发现两个bug，真是丢脸啊。
一是数字高亮的bug，最终处理上居然一小步布尔逻辑写错了，造成长串数字的误认；二是ie下的复制按钮，定位的复制对象居然是“关于”，而不是源代码（少了个parentNode）。
这么明显的失误啊，真想跳楼谢罪了……
话归正题，系列文章会逐步出炉的，将jssc的一切毫无保留地叙述出来。这次失误的收获倒是知晓了其它几个web端的语法高亮器（以前只知道syntax highlighter，貌似也是最知名的），其中最吸引我的是prettify，貌似是google官方的东东。不愧是大佬啊！拿我常用的一段js代码测试了下，prettify是目前我所知js解析器中最为准确的！当然还有一点点小瑕疵，那就是正则的flag（i、m、g）没有跟随正则一起被高亮。不过最让我搞不懂的是，相对简单的flag没有解析正确，反而更难的跨行除法却做到了。
以下是我常用的测试代码，如果web端语法高亮器能解析到jssc的程度，才能够说明是正确了。
//javascript
function none(){
}
/** javascript
jscript
*/
var reg = /[\/][*]([\S\s]*?)(?:[*][/;\[\]]|$)|[\/][/g;](.*)|”((?:\\\\|\\”|[^"])*)”|’((?:\\\\|\\’|[^'])*)’/gm; ”; /\d/.test(1);
reg = 12;
a / b
/reg/;
var num1 = 0.541f;
function f(test) {
…

国庆期间的努力，TAT～
http://code.google.com/p/jssc/
这里有预览：
http://ff9.ffsky.cn/temp/jssc5/index.html
改进：

相对于alpha版性能至少提升1个数量级而言，beta版也提升了数倍，其中个别逻辑性能提升近10倍。
整体架构有明显变化，体积减小约10%。
改进了对php的支持。
修正了细微的bug，删改细节功能体验。

似乎终于到了消停的日子。只买到30号的票所以请1天假，外加国庆中秋长假一共9天，够爽的了。此外hax在此篇中计划将放出史上最快的Web语法高亮引擎，给俺带来不少压力和动力啊。于是乎十一的休息就用来做jssc5 beta版的开发吧！
功能上jssc5 beta将发生以下变化：

去除鸡肋的异常处理功能。写在web上的代码基本都是本地测试运行过的，做那一点语法纠错功能没多大用，浪费功夫。这个功能还是放到以后的JAse上去吧。
重构框架。整体结构将发生一定改变，主要还是继承方面。分化更细致，有利于最终swf文件体积的减少。
增加自动格式化功能。这其实是以前同事提过的一点，在此准备加上。因web输入等原因造成录入代码缩进问题的话，就不必担心了，因为最终显示会计算缩进量（当然诸如python这样的语言就不行了）。
改善算法，优化性能。这也是最重要的！即使jssc5 alpha已经大大改善了性能，dojo的9k行代码在2秒内跑完，但理论上还有挖掘的潜力！到时候要和hax的PK一番，哈哈！

至于添加语法种类就需要广大爱好者的帮助了。我也准备陆续写关于高亮的文章，分享jssc5的核心算法和具体思路。虽然一直开源，但貌似从未有人对源代码的改善提过建议，我还是写点教程服务人民群众吧。
另外，发现alpha2里的说明alert居然显示的是beta版。上次修改改错，成超前发布了……

jssc5开发版本测试地址：
http://jssc.googlecode.com/svn/trunk/jssc5/test.html
基于as3和js的。
草草做了个输入框，放在了googlecode的svn上，所以ie下看这个反而会解析为html，其它的可能会只是文字。勉强一下了。
仅写了ecmascript4的lexer（即javascript和actionscript），在词法分析上多做了一些语法分析上的纠错功能，语法分析的内容本次将暂不涉及到。用mootools、jquery、dojo的代码测试了下，目前所有已知bug都已修正。
本次jssc5是基于词法分析的，功能比以前大大增强，性能也有显著增加。但缺点就是必须为每种语言编写不同的lexer，所以将考虑优先一些常用语言的编写。
（注：是每种不是每一个，像javascript和actionscript就是同种语言属于ecmascript，而c、java、c++也可用同种lexer解析）。
可以输入一些明显错误代码，如：var i = 0s; 词法处理上会告知出现的错误并且暂停分析，错误后面的代码会被格式化后保存。
代码折叠已有，深度也已经计算出来，只是没有让它显示出来。：P
源代码过几天会放到googlecode的svn上，lgpl协议。由于语种过多，我个人熟悉的语言也就那几个，因此有兴趣的人欢迎来编写其它语言的lexer，主页上参与编写的人员将会增加你的名字。
—
关于jssc的项目主页以及之前的老版本或者想使用它的，请看这里：
http://code.google.com/p/jssc/

源于新的jssc5的设想，开辟基于词法分析和语法分析的高亮器。当然，词法分析和语法分析我还在学习中，编译原理没好好学，大学时间那个悔啊……
简单测试了下，主要是性能方面。hax曾经做过chrome下面正则的测试，实验证明google浏览器对正则的优化真的很牛X！不过我考虑仍将继续基于flash平台来做，原因很显然：词法分析必须遍历字符串，而js的遍历性能目前来看是实在不敢恭维的。
大概排序一下吧：
直接比较字符串最快：s == “string”；
用as3内置的indexOf来寻找其次；
判断charCode和indexOf差不多：比如单个字符是否数字；
用isNaN结合parseInt来判断是否数字就比较慢了，但不限单个字符，大概是charCode的数倍到十倍，所以要综合考虑；
用正则最慢！这和js情况正好相反，但正则功能最强大，不过目前情况来看用到正则的可能性很少。
唔，jssc5搞定后JAse研究就能迈进一大步了。
—-
更新：
发现Array类的push()操作性能居然还不如手动写入？！
真晕啊，不知道Adobe搞什么鬼。
array.push(value)还不如array[array.length] = value;，当然舍却length用计数器还要快一点点。

http://army.javaeye.com/blog/360024
起因hax对于jssc 4.2的dojo的9000行代码测试，性能差到难以想象；后来改进的innerHTML的事件侦听，结果才勉勉强强。
“今天才忙的过来测试了一下，ie、ff、chrome都试了试。
很奇怪的是，flash在这三种浏览器的运行效率居然有略微的不同，其中ff上跑完9000行代码大概是2.5秒，随机分布有时会略微低一些，比如2.4秒等；而ie和chrome都要慢一些，大概在2.7秒、2.8秒的样子。
上面只是传递到flash分析再传递回来分析结果的时间，还未加上innerHTML，假如加上，chrome就明显占了优势，大概在3.7秒左右；ff则是4.1秒左右；ie最惨，占了4.6秒。
至于js分析9000行代码能达到500ms的效率我感到很吃惊，因为之前的版本以及使用hl的结果，让我感到js的分析能力远远达不到这个要求；在flash中由于对其性能的信任，我没有用正则，直接进行的字符串遍历。有机会到要试一试正则在flash中比字符串遍历的性能到底有没有提高，提高多少。”
后续进行中，期待Dr.hax的js分析器，将会对目前js和as在分析上的局面有哪些探知和改变？

《编译原理》，也就是龙书三、紫龙书。的确够难的，可能是我读过的最难懂的一本书了——当然，除了霍金的《时间简史》。我估计半年都读不完。
目前进度是第4章文法分析了吧，前面有的地方跳过去了，因为暂时感觉不需要，比如说设计编译器以及编译成汇编什么什么的，我需要的是对jssc有帮助的地方。
回想2007年一时冲动写下破烂不堪的jssc1到目前为止，真没想到会有如此的发展经历。在读《编译原理》的时候，我居然发现自己的算法分析的设计和书中许多地方不谋而合！当然我那点小聪明根本不及《编译原理》的九牛一毛，但我所希望的是，下一个版本中能够带来更强的特性。
最近坛子里看到龙博编辑器的作者说“要让老外们来模仿我们”云云的话，不由得赞叹一下。以前也是我模仿syntaxhighlighter，现在恐怕也快要倒过来了吧。所以我去看《编译原理》，准备可能的jssc5，设计出前端最好的高亮器。
目前想到的就是靠as3的高效率和oop，用真正的文法分析来分析语法，能够提炼类、类型、类属性、类方法，能够对某些可能的错误给出错误提示。这个想法显得有些夸张，人有多大胆，地有多大产么？

http://code.google.com/p/jssc/
众人拾柴火焰高，经过一段时间的发布和回馈，jssc4.1的版本公布出来，以供开发者们使用。这次做的比较大的革新有：css控制，自定义颜色，标记语言增强，jsp语法支持，预留接口。
1.除却高亮颜色部分外，其余已经尽可能地交由css控制。我想这也是所有人都希望看到的。
2.为了保持对word等富文本复制的功能，一定程度上牺牲了css控制高亮颜色的便捷。不过除了默认颜色外，可以使用对外提供的reset方法来重新自定义颜色。比如目前的示例就是使用：
reset({
js: {
key: “f33″
},
java: {
key: “39f”
…

自从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，也不会乱。
制作过程中仍旧有许多问题，解决后有很多心得，将陆续发布出来讨论。一些改进仍需，请回帖发言……

源自对jssc的改进，原有的自动装载版本是先检测页面中出现的语法文件，然后零碎地一个一个去装载。
新的思路是，先制作好不同组合类型的文件，然后在检测的时候计算出是哪种组合，再整体一次性地去装载。
比如页面有a语法，就只装载a；有a、b就装载a和b的组合文件；有a、b、……g、h的就装载他们的组合。
思路是好的，因为这样减少了http请求，每一次至多只发送一次异步装载便可，然而我忽略了一个最基本的常识：有多少种组合。
用java写了个读取每种文件然后进行组合的程序，刚不久就发现了这个问题，用println语句打印，n长时间都没有结束。
试试计算一下多少种组合：c15/0 + c15/1 + c15/2 + c15/3 + … + c15/14 + c15/15，这是一个天文数字啊……