论坛首页 Web前端技术论坛

脚本分析、压缩、混淆工具 JSA新版本发布,压缩效率提高大约10%

浏览 37093 次
该帖已经被评为良好帖
作者 正文
   发表时间: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

压缩算法改进:

实现了自己的文本压缩算法
  • 提高了压缩比率以及解压效率。
优化了语法压缩
  • 合并连续var申明,
  • 删除了多余var申明,
  • 删除了多余大括弧({、}),
  • 删除了多余分号(;)。

UI改进:

  • 自动编码识别
  • 支持文件拖放
  • 支持JAVA1.4.2+ 当jar打开方式为java时,可双击运行,但,若JAR打开方式被修改(如winrar),请使用如下方式:
    CMD>java -jar xx.jar
  • 格式化
    注释只能在各语句之间,插在语句中间的注释有可能丢失,在格式化的时候,算bug吧。
  • 压缩参数设置
    操作->设置:
    执行语法压缩:将替换局部变量,删除冗余语法。
    执行文本压缩:将脚本文本分词、替换压缩。执行时可通过eval( 解压函数() )方式还原。
    兼容IE5、NS3:老版本的浏览器对正则表达式支持优先,是否需要兼容他们(需要采用稍微复杂一点的解压函数)。
    执行文本压缩的条件设置:设置何时采用文本压缩,有两项,比率要求和大小要求;因为eval是需要额外开销的,所以,只有当文本压缩的比率小于指定值且文件大小大于指定值时才采用文本压缩。

ANT Task

  • 默认编码 :取JRE的默认编码,可能随机器不同而改变,所以,推荐手动指定器编码方式(eg:charset="utf-8"/charset="GBK")
  • jsicompile 任务:编译JSI (压缩,预装载编译,定制启动文件)
  • jscompress 压缩脚本

ANT Task 示例

    jsicompiler 示例(处理JSI及其集成的第三方脚本)

    xml 代码
     
    1. <target name="compress" depends="init">  
    2.   <jsicompiler destDir="ant/temp/script2" charset="utf-8" rebuildboot="true">  
    3.     <fileset dir="web/scripts">  
    4.       <include name="*/**/*.js" />  
    5.       <include name="*.js" />  
    6.       <exclude name="preload/**" />  
    7.     </fileset>  
    8.     <preloadgroup path="code-decorator.js">  
    9.       <fileset dir="web/scripts">  
    10.         <include name='js/io/__$package.js' />  
    11.         <include name='js/io/request.js' />  
    12.         <include name='js/io/writer.js' />  
    13.         <include name='js/xml/__$package.js' />  
    14.         <include name='js/xml/template.js' />  
    15.         <include name='js/xml/tag.js' />  
    16.         <include name='js/util/__$package.js' />  
    17.         <include name='js/util/collections.js' />  
    18.         <include name='org/xidea/syntax/__$package.js' />  
    19.         <include name='org/xidea/syntax/syntax-parser.js' />  
    20.         <include name='org/xidea/decorator/__$package.js' />  
    21.         <include name='org/xidea/decorator/code.js' />  
    22.       </fileset>  
    23.     </preloadgroup>  
    24.   </jsicompiler>  
    25. </target>  

    jscompress 示例(压缩普通脚本)

    xml 代码
     
    1. <target name="test-compress">  
    2.   <jscompress destDir="ant/temp/script2" charset="utf-8">  
    3.     <fileset dir="web/scripts">  
    4.       <include name="js/**/*.js" />  
    5.       <include name="*.js" />  
    6.     </fileset>  
    7.   </jscompress>  
    8. </target>  
   发表时间: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;
0 请登录后投票
   发表时间:2007-05-10  
正在准备人工合并一堆js,这个工具太合时宜了,try下看看,谢谢楼主
0 请登录后投票
   发表时间: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
0 请登录后投票
   发表时间: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

0 请登录后投票
   发表时间: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

金同志,你搞错了,人家说的是dojo基于rhino的压缩器,那个当然是非常之安全了,因为rhino本身就是js引擎。我的一个朋友曾经写了一个脚本,首先调用dojo的这个压缩器,然后调用dean的压缩器,这样达到的压缩效果是非常好的。dojo这个压缩器另外一个好处是,他实际上会补正一些语法,如自动插入分号。经过这道压缩,后续压缩才能保证安全。

不过我对你说的那个eval比较感兴趣,我认为如果允许标识符压缩,eval总是不安全的。例如下面这个代码:

function doWhat(param1, param2) {
  eval(param1);
}

doWhat('alert(param2)', 'abc');

显然,如果进行标识符压缩而改变了参数名称,那执行的结果就不一样了。实际问题在于,你无法去压缩字符串里的代码和准代码。
0 请登录后投票
   发表时间: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更高效的压缩方式,告诉我,感激不尽!
0 请登录后投票
   发表时间:2007-05-21  
你说dojo shrinksafe有问题,有没有测试用例啊?
我用的是它以前的版本,曾经用其压缩过超过130k的代码,并没有什么问题。

还有你说的那个解决eval“最简单的办法”,根本不可行,因为你找不出受影响的域。。。因为eval操作的是个字符串,而且这个字符串可以是动态产生的,甚至用户输入的。而eval时,变量可以是局部的,或者函数参数,或者外层的变量,甚或是套在with里面的。。。

总之我是想不出可行的方法,而且为安全计,我也认为eval是非常evil的。

我能想到的最好方法,就是警告压缩器的使用者,这可能造成eval的错误。

关于JSA,俺很感兴趣的。实际上我建议你考虑把jsa发展成一个compiler。
0 请登录后投票
   发表时间:2007-05-21  
hax 写道
你说dojo shrinksafe有问题,有没有测试用例啊?
我用的是它以前的版本,曾经用其压缩过超过130k的代码,并没有什么问题。

还有你说的那个解决eval“最简单的办法”,根本不可行,因为你找不出受影响的域。。。因为eval操作的是个字符串,而且这个字符串可以是动态产生的,甚至用户输入的。而eval时,变量可以是局部的,或者函数参数,或者外层的变量,甚或是套在with里面的。。。

总之我是想不出可行的方法,而且为安全计,我也认为eval是非常evil的。

我能想到的最好方法,就是警告压缩器的使用者,这可能造成eval的错误。

关于JSA,俺很感兴趣的。实际上我建议你考虑把jsa发展成一个compiler。


呵呵,算了,我不争论了,事实胜于雄辩。

JSA现在只是提供了swing界面和ant任务方式。
也想过把它做成eclipse插件,精力有限,只能作罢,呵呵。
0 请登录后投票
   发表时间:2007-05-21  
喂,大哥,你说事实,那要摆事实的呀。给个测试用例呀。

还是你认为eval是可以解决的?那你搞定我给的函数先。不要空口说什么事实胜於雄辩。。。
0 请登录后投票
论坛首页 Web前端技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics