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

这个要支持一把楼主。dojo的压缩是有bug的，它对eval的处理很危险。同一段用dojo处理会出错的代码改用楼主的压缩工具，工作正常。但未广泛测试，还不能定论。

要例子，其实你自己运行一下就可以的。
为了说明更多的问题，在你的例子里再加个函数doOther：

function doWhat(param1, param2) {
eval(param1);
}
function doOther(param1, param2) {
function inner(param3){alert(param3)}
inner(param1);
}
doWhat('alert(param2)', 'abc');

压缩结果（便于查看，重新格式化了）：

function doWhat(param1,param2){
  eval(param1);
}
function doOther(C,A){
  function B(A){
    alert(A);
  }
  B(C);
}
doWhat("alert(param2)","abc");

1。eval影响的域，变量名没去压缩。
2。再doOther中，因不会受到eval影响，可以压缩。
3。最大限度重用了变量符号，这对局部变量很多，或者将来的文本压缩，都有好处。

文件太小，文本压缩就没有优势，所以这里只有语法压缩

结果就是所有eval语句处可以访问的变量（包括外层变量）的标识符统统不能压缩呀！！！eval真是祸患呀！
所以写代码能不eval千万别eval。。。
btw，如果eval函数也是被传进来的呢？这回就惨了。。。


function evilEval(param1, param2, param3) {
  param1(param2);
}

evilEval(eval, 'alert(param3)', 'abc')

嗯不得不佩服我自己，太变态了。。。。

这个而且ff和jscript处理不一样的。

呵呵，确实够狠。

不过这是违背ECMA规范的，按它的说明，eval甚至不能有别名，不能通过别名调用。
所以，你这种情况就更不允许了。

不过规范归规范，还是很多不怕死的人这么用了，dojo就用了（并且，它的情况完全可避免的）

我在写JSA的时候，这个问题也考虑过，我可以定义eval这样危险函数的别名。
但是，还没提供用户接口。

规范好像没说不能别名吧，好像说的是eval可以没有call等方法。


ff由于历史原因，eval会记住其所在的function的scope，所以可以把一个function 里的eval传出来，就可以对该函数内部搞破坏了。

我记得有的，我以前看到过。

最新更新（2007-05-23 IE5 bug） 感谢 PHPRPC 作者 andot  的bug报告：
下载地址：http://sourceforge.net/project/showfiles.php?group_id=175776

这个工具怎么对有中文的js处理啊，会变成乱码的，我对Ant不熟，不知道该怎么做，能给个详细的步骤吗？

    <jsicompiler destDir="ant/temp/script2" charset="utf-8" rebuildboot="true"> 
如果你的脚本原文件不是utf8,如gbk,自己设置一下就是.

中文处理后变成\uxxxx 方式,这就是为了解决中文问题.
经过这样处理后,无论是gbk还是utf8的网页,都可以正确处理.

有人反应说,图形界面里面识别字符集的时候,偶尔也会搞错,图形界面里面是先尝试jvm的默认字符集,这个可能随机器变化.
暂时的解决办法:先用记事本吧要压缩的文件打开,拷贝进去.
这样就不会乱码了.

如何选择用英文界面？我用linux下的jdk，没有给swing和awt配置中文字体...