AJAX還是比較強大的！（顯然，這是一句廢話），最近在研究一個網站的AJAX應用中發現其中的“拓展視野”部分頻頻被挖掘出來（也由此可見，平時本人的視野有多麼的狹窄了），首先是全站的JS全部使用packed進行了壓縮，呃！也不知道這種稱法是否正確，就是用eval(function(p,a,c,k,e,d){})的那種世界各地都很流行的壓縮方法吧，在實際的觀察中，一個壓縮後僅爲6K，在我將其轉化爲“肉眼能看清楚的代碼”之後，足足有20K，可見其效果還是相當明顯的；此外，用HttpWatch弄到了傳輸數據後，居然是加密的。。。形如下面這段：q1YqT81MzyhRsqpWys3MU7Iy0FHKTaxQsjLWUUrLL8pNBMooqeoZpSnV6igVFGUmp2KoVDIzMrIwNdAzMFBC1pOiVFsLAA==
任何一個有些許密碼學經驗的同志都容易很看出來，這是base64編碼(我實在不喜歡稱這個爲“加密”)，沒錯，和各位看官一樣，我很快就用php自帶的base64_decode函數對其進行了解密，如果您覺得問題到此爲止，那就錯了！這時我才稍稍感到了有些震撼，解密出來的數據
呃！一堆亂碼，其實應該是二進制數據，加密了（後來知道是壓縮了），可是用戶是看不懂這些的，客戶端是肯定要進行解密的！用什麼？AJAX的當然用JS解密了，挖解密函數啊，挖解密函數，看到了如下的精彩代碼：
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://www.zendstudio.net/archives/js-zip-inflate/
