某网站AJAX的加密压缩传输算法的一点研究

AJAX还是比较强大的！（显然，这是一句废话），最近在研究一个网站的AJAX应用中发现其中的“拓展视野”部分频频被挖掘出来（也由此可见，平时本人的视野有多么的狭窄了），首先是全站的JS全部使用packed进行了压缩，呃！也不知道这种称法是否正确，就是用eval(function(p,a,c,k,e,d){})的那种世界各地都很流行的压缩方法吧，在实际的观察中，一个压缩后仅为6K，在我将其转化为“肉眼能看清楚的代码”之后，足足有20K，可见其效果还是相当明显的；此外，用HttpWatch弄到了传输数据后，居然是加密的。。。形如下面这段：
q1YqT81MzyhRsqpWys3MU7Iy0FHKTaxQsjLWUUrLL8pNBMooqeoZpSnV6igVFGUmp2KoVDIzMrIwNdAzMFBC1pOiVFsLAA==

任何一个有些许密码学经验的同志都容易很看出来，这是base64编码(我实在不喜欢称这个为“加密”)，没错，和各位看官一样，我很快就用php自带的base64_decode函数对其进行了解密，如果您觉得问题到此为止，那就错了！这时我才稍稍感到了有些震撼，解密出来的数据

呃！一堆乱码，其实应该是二进制数据，加密了（后来知道是压缩了），可是用户是看不懂这些的，客户端是肯定要进行解密的！用什么？AJAX的当然用JS解密了，挖解密函数啊，挖解密函数，看到了如下的精彩代码：

1	var filterList=eval('('+utf8to16(zip_depress(base64decode(g_pgFilterList)))+')');

utf8to16()和base64decode()都好理解，也再一次证明加密的最后是用base64编码输出的，关键就是这个zip_depress()，zip解压？
是的，千真万确，用JS实现了zip的解压算法！！！到这里我深深的感到了震撼，原来，我知道的真的太少了啊！虽然之前知晓有md5.js，知道JS在运算方面是没有问题的。不会是这家伙自己写的压缩算法吧？经过搜索，我找到了这个算法（Zip inflate）的原版，原来该网站的制作人员修改了函数名，难怪我直接google不到呢？
什么是inflate算法？—

inflate是GZip, PNG等广泛使用的解压算法,linux也使用inflate对内核进行解压.inflate的解压算法使用的第3种快速解压法的一个子集,它不考虑LONG_CODE,同时把SAME_LENGTH合并到MEDIUM_CODE。而对于规则的SAME_LENGTH编码，比如length和distance编码，inflate则使用额外的base和extra表示。这是因为在构造一般的查找表时，虽然对于SAME_LENGTH前缀可以不构造副表，但我们需要另外一个表格来保存符号的顺序，而这个表格的空间可能更大。但对于length和distance编码，他们的顺序是递增的，所以无需额外的表格来保存符号的顺序。

inflate使用root表示上述的b,查找表的数据结构为code.主表和副同时保存在inflate_state结构中的大数组codes[ENOUGH]中.表的构造函数位于inftrees.c文件的inflate_table中.

令人感到欣喜若狂的是，PHP竟然已经提供的现成函数来解压和压缩inflate,它们是gzinflate()和gzdeflate()，哈哈哈！我不禁仰天狂笑的一番，用gzinflate()成功的将上文数据解密，内容是这样的

{"weight":{"min":0,"max":3,"format":"%.2f"},"price":{"min":0,"max":"622850.00","format":"%d"}}

标准的JSON数据啦，不错！这就为以后的AJAX的传输上多了一个选择，虽然还不确定这种方法能否节省流量（因为base64算法会将原始数据“稍稍”增大），但客户端有了解压算法，服务端的php压缩函数又是现成的，大不了在base64这个环节上大概需要改进下，我想对于大流量的数据应该还是有确切效果的。嗯，我很满意。

来自：http://hi.baidu.com/wshe505/blog/item/ab4c9b511a9cfd7f85352494.html