该帖已经被评为良好帖
|
|
---|---|
作者 | 正文 |
发表时间:2007-05-08
JSA 1.0 Alpha发布,压缩效率提高大约10%最新更新(2007-05-23 IE5 bug) 感谢 PHPRPC 作者 andot 的bug报告:下载地址:http://sourceforge.net/project/showfiles.php?group_id=175776 压缩算法改进:实现了自己的文本压缩算法 优化了语法压缩 UI改进:
ANT Task
ANT Task 示例
jsicompiler 示例(处理JSI及其集成的第三方脚本)xml 代码
jscompress 示例(压缩普通脚本)xml 代码
声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2007-05-10
bug更新:
上次发布的版本,在合并for in 及其后连续申明时发现bug。新版本已经发布,见sf下载站点和google jsier邮件列表。 出错情况: for(var a in x){}var b=1;var c=2; 将错误合并为: for(var a in x){}b=1,c=2; |
|
返回顶楼 | |
发表时间:2007-05-10
正在准备人工合并一堆js,这个工具太合时宜了,try下看看,谢谢楼主
|
|
返回顶楼 | |
发表时间:2007-05-20
楼主可以参考这个Dojo compressor
http://dojotoolkit.org/docs/compressor_system.html the Dojo compressor is based on Rhino, a JavaScript engine from the Mozilla project. dojo的压缩率在60%左右,因为它用Mozilla的内核,会分析javascript,所以能改变量名。是通过分析源代码做的,比一般的安全很多的。它相当于本身就是一个JS虚拟机。 另一款我常用的是叫做ESC的JavaScript代码混淆器。 ESC是用JavaScript编写的一个代码预处理工具,可以对JavaScript(ECMAScript)源代码进行压缩和混淆。经过处理之后,源代码的长度可以被压缩至45%左右,可读性自然也将大大降低。ESC是开源软件,采用GNU授权协议(GPL)发布。 下载地址:http://www.saltstorm.net/depo/esc/?pod=js |
|
返回顶楼 | |
发表时间:2007-05-20
YuLimin 写道 楼主可以参考这个Dojo compressor
http://dojotoolkit.org/docs/compressor_system.html the Dojo compressor is based on Rhino, a JavaScript engine from the Mozilla project. dojo的压缩率在60%左右,因为它用Mozilla的内核,会分析javascript,所以能改变量名。是通过分析源代码做的,比一般的安全很多的。它相当于本身就是一个JS虚拟机。 另一款我常用的是叫做ESC的JavaScript代码混淆器。 ESC是用JavaScript编写的一个代码预处理工具,可以对JavaScript(ECMAScript)源代码进行压缩和混淆。经过处理之后,源代码的长度可以被压缩至45%左右,可读性自然也将大大降低。ESC是开源软件,采用GNU授权协议(GPL)发布。 下载地址:http://www.saltstorm.net/depo/esc/?pod=js 呵呵,多谢回复。 你对dojo压缩工具的看法是错的,他不够安全。没有注意eval。with等特殊语法。此外,对于变量的压缩,也不完美。 你说的他的压缩效率能达到60%,那是有很多水分的(空格,注释是不能算的,要不,没法评价)。 早再JSA0.4的时候,仅仅语法压缩就全面超越了dojo的压缩工具。 这个新版本,除了改进了语法压缩,同时,实现了自己的文本压缩,效率也超越了同类中的佼佼者:Dean Edwards 写的packer。 同时采用语法压缩和文本压缩,目前为止,我还没有发现压缩比率可以超过jsa的。 关于dojo的问题,在仍一个主题上有详细说明和例子: http://www.iteye.com/article/57252 |
|
返回顶楼 | |
发表时间:2007-05-21
jindw 写道 YuLimin 写道 楼主可以参考这个Dojo compressor
http://dojotoolkit.org/docs/compressor_system.html the Dojo compressor is based on Rhino, a JavaScript engine from the Mozilla project. dojo的压缩率在60%左右,因为它用Mozilla的内核,会分析javascript,所以能改变量名。是通过分析源代码做的,比一般的安全很多的。它相当于本身就是一个JS虚拟机。 另一款我常用的是叫做ESC的JavaScript代码混淆器。 ESC是用JavaScript编写的一个代码预处理工具,可以对JavaScript(ECMAScript)源代码进行压缩和混淆。经过处理之后,源代码的长度可以被压缩至45%左右,可读性自然也将大大降低。ESC是开源软件,采用GNU授权协议(GPL)发布。 下载地址:http://www.saltstorm.net/depo/esc/?pod=js 呵呵,多谢回复。 你对dojo压缩工具的看法是错的,他不够安全。没有注意eval。with等特殊语法。此外,对于变量的压缩,也不完美。 你说的他的压缩效率能达到60%,那是有很多水分的(空格,注释是不能算的,要不,没法评价)。 早再JSA0.4的时候,仅仅语法压缩就全面超越了dojo的压缩工具。 这个新版本,除了改进了语法压缩,同时,实现了自己的文本压缩,效率也超越了同类中的佼佼者:Dean Edwards 写的packer。 同时采用语法压缩和文本压缩,目前为止,我还没有发现压缩比率可以超过jsa的。 关于dojo的问题,在仍一个主题上有详细说明和例子: http://www.iteye.com/article/57252 不过我对你说的那个eval比较感兴趣,我认为如果允许标识符压缩,eval总是不安全的。例如下面这个代码: function doWhat(param1, param2) { eval(param1); } doWhat('alert(param2)', 'abc'); 显然,如果进行标识符压缩而改变了参数名称,那执行的结果就不一样了。实际问题在于,你无法去压缩字符串里的代码和准代码。 |
|
返回顶楼 | |
发表时间:2007-05-21
hax 写道 你搞错了,人家说的是dojo基于rhino的压缩器,那个当然是非常之安全了,因为rhino本身就是js引擎。我的一个朋友曾经写了一个脚本,首先调用dojo的这个压缩器,然后调用dean的压缩器,这样达到的压缩效果是非常好的。dojo这个压缩器另外一个好处是,他实际上会补正一些语法,如自动插入分号。经过这道压缩,后续压缩才能保证安全。
不过我对你说的那个eval比较感兴趣,我认为如果允许标识符压缩,eval总是不安全的。例如下面这个代码: function doWhat(param1, param2) { eval(param1); } doWhat('alert(param2)', 'abc'); 显然,如果进行标识符压缩而改变了参数名称,那执行的结果就不一样了。实际问题在于,你无法去压缩字符串里的代码和准代码。 你说的eval问题,要解决它最简单的办法就是,找出受影响的域,保留这些域的局部变量,ok.... Dojo shrinksafe的安全问题我已经说过很多遍了,现在再从重复一下: 1、eval catch with 这三个特殊语法的处理。 2、JScript的条件编译。 仍外,JSA的语法压缩也是基于Rhino。只是功能比shrinksafe强,也更安全。 我建议你试一下JSA再来发言。 如果你找到比JSA更高效的压缩方式,告诉我,感激不尽! |
|
返回顶楼 | |
发表时间:2007-05-21
你说dojo shrinksafe有问题,有没有测试用例啊?
我用的是它以前的版本,曾经用其压缩过超过130k的代码,并没有什么问题。 还有你说的那个解决eval“最简单的办法”,根本不可行,因为你找不出受影响的域。。。因为eval操作的是个字符串,而且这个字符串可以是动态产生的,甚至用户输入的。而eval时,变量可以是局部的,或者函数参数,或者外层的变量,甚或是套在with里面的。。。 总之我是想不出可行的方法,而且为安全计,我也认为eval是非常evil的。 我能想到的最好方法,就是警告压缩器的使用者,这可能造成eval的错误。 关于JSA,俺很感兴趣的。实际上我建议你考虑把jsa发展成一个compiler。 |
|
返回顶楼 | |
发表时间:2007-05-21
hax 写道 你说dojo shrinksafe有问题,有没有测试用例啊?
我用的是它以前的版本,曾经用其压缩过超过130k的代码,并没有什么问题。 还有你说的那个解决eval“最简单的办法”,根本不可行,因为你找不出受影响的域。。。因为eval操作的是个字符串,而且这个字符串可以是动态产生的,甚至用户输入的。而eval时,变量可以是局部的,或者函数参数,或者外层的变量,甚或是套在with里面的。。。 总之我是想不出可行的方法,而且为安全计,我也认为eval是非常evil的。 我能想到的最好方法,就是警告压缩器的使用者,这可能造成eval的错误。 关于JSA,俺很感兴趣的。实际上我建议你考虑把jsa发展成一个compiler。 呵呵,算了,我不争论了,事实胜于雄辩。 JSA现在只是提供了swing界面和ant任务方式。 也想过把它做成eclipse插件,精力有限,只能作罢,呵呵。 |
|
返回顶楼 | |
发表时间:2007-05-21
喂,大哥,你说事实,那要摆事实的呀。给个测试用例呀。
还是你认为eval是可以解决的?那你搞定我给的函数先。不要空口说什么事实胜於雄辩。。。 |
|
返回顶楼 | |