鹏程万里——虽然我可能羽翼未丰，但这是我永不磨灭的志向

在线版JavaScript混淆器，支持变量重命名、流程混淆、压缩等功能。

地址：JavaScript eXtreme Obfuscator Online

使用说明：

在线版混淆器允许输入的JavaScript脚本最大长度为800

JavaScript eXtreme Obfuscator：JavaScript极限混淆器

功能：

1、格式化代码

2、根据前缀、后缀、正则表达式重命名变量，并可指定新变量名的前缀

3、根据前缀、后缀、正则表达式重命名函数，并可指定新函数名的前缀 

4、去掉换行、空白、注释

5、数字混淆

6、字符串混淆

7、花指令混淆

8、流程混淆 

9、打包（或者叫压缩） 

截图：

说明：

1、格式化的过程不是简单地替换，而是进行了适当的改进。如：在语句的结束添加“;”，为if、for、while等增加“{}”，将正则表达式“/....../”改为“new RegExp”的形式。

2、数字混淆是将数字替换成一个十六进制的表达式。

3、字符串混淆是将字符串简单加密后通过一个函数进行解密。

4、花指令混淆：是随机插入一些比较让人迷惑的if……else……指令，加大阅读的困难。 

5、流程混淆：用随机的循环配合if或switch，在不破坏执行顺序的情况下打乱代码的顺序，加大阅读的困难。

6、Pack：用一个简单的方法减小代码的长度，很常见。但会造成效率降低。

也正因为不是简单地替换，带来了新的麻烦。已知问题有：

1、某些朋友认为“{}” 比较多余，但我还是加上去了。

2、算数表达式之类的我加上了“()” ，这个到不是为了好看，而是因为我比较懒，不想去把精力花在处理运算符的优先级上。结果导致一个算数表达式可能会变成这样“1+2*3+4”=>“((1+(2*3))+4)”（MS比较恶心些，下次再改进吧）。

3、对于正则表达式，一般情况下不会出现问题。目前唯一已知的问题是JQuery中出现了“/=.../” 这种类型的正则表达式，会导致无法解析。 

最后， 既然是混淆，不可避免地使代码变得庞大，但并会对效率造成什么太大的影响，这就是传说中的双刃剑吧。

JavaScriptFormatter：JavaScript代码格式化工具

功能：

1、格式化代码

2、重命名变量，并可指定新变量名的前缀

3、去掉换行、空白、注释

截图：

说明：

格式化的过程不是简单地替换，而是进行了适当的改进。如：在语句的结束添加“;”，为if、for、while等增加“{}”，将正则表达式“/....../”改为“new RegExp”的形式。

也正因为不是简单地替换，带来了新的麻烦。已知问题有：

1、某些朋友认为“{}” 比较多余，但我还是加上去了。

2、算数表达式之类的我加上了“()” ，这个到不是为了好看，而是因为我比较懒，不想去把精力花在处理运算符的优先级上。结果导致一个算数表达式可能会变成这样“1+2*3+4”=>“((1+(2*3))+4)”（MS比较恶心些，下次再改进吧）。

3、对于正则表达式，一般情况下不会出现问题。目前唯一已知的问题是JQuery中出现了“/=.../” 这种类型的正则表达式，会导致无法解析。

以这篇东东主要是作为一个新的起点，开始新的计划。

从2008年下半年起，就没有再碰过这个东西。其实我一直想将它做好、做精，只是苦于工作生活上的压力，将它丢在了一边。

今天对我来说，可能会算是一个转折点（不知道是好是坏）。我决定重新启动这个久违了的项目。

名称改为JSXO，JavaScript极限混淆器，版本号从3.0开始。

一定要把之前没有完成的东西做完，并且要做好、做精。

上一回说到普通属性的延迟加载，这次说下我对于联结关系的延迟加载的看法。

所谓联结关系，就是一对一、一对多、多对多这样的对象之间的关系。一说到这类延迟加载，就不能不想到NHibernate。通过编辑配置文件，即可实现联结关系的延迟加载。我不想进行太多的介绍，毕竟，比我研究得深入的大有人在。所以就只如主题了。

曾经，我也曾经考虑过用配置文件和CustomAttribute来定义联结关系，并且付诸实现。基本的xml定义方式如下：

<Relation Property="" TargetType="" RelationType="" ConditionColumn="" SlaveColumn="" JoinTable="" JoinType=”” JoinTableConditionColumn="" JoinTableSlaveColumn=""></Relation>

其中：

1、 Property是实体的属性，如果用CustomAttribute就可以省掉。

2、 TargetType是延迟加载的数据类型。

3、 RelationType是关系类型，一对多还是多对多。

4、 ConditionColumn也就是作为条件的列，主要是为了取得延迟加载的条件。从ConditionColumn对应的属性中获取值进行查询。

5、 SlaveColumn是从表的列。

6、 JoinTable是中间表。

7、 JoinType是联结的类型，比如：left join、left outer join、full join之类。

8、 JoinTableConditionColumn是使用中间表的时候，中间表中作为条件的列。

9、 JoinTableSlaveColumn是谁哦用中间表的时候，中间表和从表列对应的列。

用SQL语句来描述就是：

1、    不使用中间表：from TargetType.Table where SlaveColumn = ConditionColumn.Value

2、    使用中间表：from TargetType.Table JoinType join JoinTable on JoinTableSlaveColumn = SlaveColumn where JoinTableConditionColumn = ConditionColumn.Value

考虑以下几种情况：

1、 不使用中间表的一对一延迟加载

2、 不使用中间表的一对多延迟加载

3、 使用中间表的一对一延迟加载

4、 使用中间表的一对多延迟加载

其中1和2比较容易搞定，直接根据“ConditionColumn”所对应的属性，用“SlaveColumn”作为条件列，获取TargetType所对应的表名进行查询即可。如果是一对一，则填充实体，赋值。如果是一对多，则填充实体集合，赋值。对于3和4使用了中间表的情况，就更麻烦些，毕竟要生成“Join”语句嘛。先用“JoinTableConditionColumn”和“ConditionColumn”所对应的属性值生成“join”之后的“where”条件。然后用“SlaveColumn”和“JoinTableSlaveColumn”生成“join” 语句的“on” 部分。当然也少不了根据“JoinTable”和“JoinType”的“join”语句的“join”部分。查询的结果，就如1和2那样同等对待了。

从上面的描述可以看出，我没有特别定义多对多关系。因为，所谓的多对多只是数据库意义上的，在使用ORM后，如果从对象的加载的角度来看，多对多其实就是一对多，只是多对多一般都会有一个中间表而已。

现在，开始说关键问题了。上面说的是“曾经”，这表示现在我放弃了这种做法。下面就开始说明一下“现在”。

通过配置或者“CustomAttribute”的确可以实现延迟加载自动化（至少是半自动化吧）。但是这些自动化真能带来所期望的便利吗？不使用中间表的延迟加载还好说，使用中间表你要在配置中填多少东西？稍微写错，就会出现问题，虽然在调试时我会输出异常，但是这并不能像编译时检查那样方便，而且提供的信息也不如用SQL语句时那样直观。这也是使用配置动态生成SQL的弊端，不能在第一时间检查错误，也不能在出错时给出非常明确的提示。还有一点让我也觉得很头疼，SQL语句可以直接放到查询分析器进行调试，那些配置该如何验证，虽然我们可以用代码生成器，但是小的修改直接手工怎么减少出错呢？而且，自动化的加载只能做到有限的自动化，双向的关联就比较不好处理。如果再用配置，不是更容易导致混乱。持久化的时候呢？