私貨時間到~
JSON vs Zipack
當今最流行的序列化格式無疑是JSON，但是基於文本的JSON有許多缺點，比如解析速度慢，體積較大。根本原因在於，JSON是基於文本的，只要是文本就離不開編譯，只要編譯就永遠沒有二進制格式來的快，而只有基於前綴的二進制格式能克服這些問題。經過若干個月的打磨，我設計出了一套緊湊的、無協議的二進制序列化格式Zipack用來取代JSON，爲數據的存儲和傳輸提供更好的方案。
官網：https://zipack.gitee.io/
Gitee倉庫：https://gitee.com/zipack/
文件後綴名：.zipack
mime類型：application/zipack
Zipack初體驗
在線體驗：https://zipack.gitee.io/#demo
在官網的在線demo中，我們可以輸入任意的JSON串，下面會自動生成相對應的Zipack字節串（16進制），不同的是，體積大大壓縮了！事實上，Zipack採用的是變長前綴編碼，簡單地說，更常用的類型更短，比如0~127的正整數只佔一個字節，短的字符串只需額外一個字節來表示類型和長度。
拒絕Base64，隨意插入純二進制數據
想象一下，如果想要在JSON中插入一個純二進制數據，我們得使用Base64等手段把字節串序列化成字符串再插入JSON，但用Base64編碼的後果就是，體積膨脹1/3。在Zipack中就不會出現這個問題，因爲Zipack有一個基本類型就是字節串！比如在JavaScript中，我們可以這樣定義一個文件對象，包括文件名，mime類型以及文件內容：
zipack.serialize({
name: 'binary-file.bin',
mime: 'application/octet-stream',
file: new ArrayBuffer(8)
})
這裏我們使用的軟件是zipack.js，這也是Zipack官方提供的JavaScript版本的編解碼器，之前的在線demo也用的它。如果你覺得還可以，記得回來star，follow一下我的倉庫哦，地址：https://gitee.com/zipack/zipack-javascript。
迷惑行爲大賞：0.1和0.5的區別
只有一個特殊情況下壓縮率是超過100%的，如果輸入的是一個不能被2的冪整除的十進制小數，那它的Zipack值反而變大了，觀察下面這2種情況：
當我們輸入0.5，壓縮率是100%，但輸入0.1時壓縮率變成167%，體積反而變大了，這是因爲十進制的0.5用二進制表示爲0.1，但是十進制的0.1用二進制表示就是0.00011001100110011001100110011001100110011......無限循環。這是因爲0.5可以表示爲1/2，分母的2的冪，但0.1無法這樣表示，所以0.1無法用二進制精確地表示，小數點後面只能拖很長的一條尾巴，於是zipack的體積反而變大了。但是不用擔心，在正常情況下我們存放在內存中的小數都是二進制的，不會出現這種問題。
Zipack的優勢
體積更小：可以將JSON壓縮至70%左右。
速度更快：基於前綴的二進制格式無須編譯，比文本格式更快。
類型豐富：支持Number，String，Bool，Null，ByteArray，List，Map（字典）以及保留類型。
變長編碼：根據Huffman編碼，常用的類型更短，如小整數只佔1個字節。
原創算法：在處理字符串和浮點數上，Zipack採用壓縮率更高的編碼來取代標準的UTF8和IEEE浮點數，具體原理請參考Zipack的格式規範。
自由擴展：Zipack提供保留前綴，開發者可藉此添加新的類型。
流化傳輸：處理大數據的時候，Zipack可以無縫拼接，邊傳輸邊處理。
好啦，以上就是我給大家帶來的Zipack初體驗，但本文尚未涉及Zipack是如何實現的，下一期我將帶給大家一篇詳細的說明文來介紹Zipack的底層原理以及近乎完美的設計理念，當然你也可以去官方的Gitee倉庫閱讀Zipack規範：https://gitee.com/zipack/spec。如果可以科學上網的話，建議直接去Github倉庫上閱讀“原著”：
https://github.com/zipack/spec
最後別忘了star和follow，如果還能打賞，那將是對我對大的鼓勵。
