本来只是想可不可以用二进制来储存 JSON 并且做一些优化之类的，结果造出来 JKSN 这货。
比较了一下文件大小，发现没有经过压缩的 JKSN 数据比 gzip -9 JSON 还要小。于是把 JKSN 的目标定为让 JSON 序列更小。
JKSN 适用于任何网络带宽比处理时间更重要的场合，如移动即时通讯。
项目地址：https://github.com/m13253/JKSN。Specification 和参考实现均以 BSD 协议发布。
为什么不用 GZIP 呢？
JKSN 和 GZIP 不冲突。JKSN 编码后的数据可以被 GZIP 压缩得更小。
由于 GZIP 的 32 KiB 滑动窗口的设计，相似的数据只有互相间隔不超过 32 KiB 才能得到有效压缩。JKSN 会将数据重新组织，使相似的数据尽可能靠近排列，更有利于 GZIP 的压缩。
下面，用项目主页上举的例子，做个比较，：
| 格式 | 文件大小 |
|---|---|
| JSON | 150 字节 |
| JSON gzip -9 | 112 字节 |
| JKSN | 109 字节 |
| JKSN gzip -9 | 107 字节 |
再来比较同类二进制 JSON 实现：
| 格式 | 文件大小 |
|---|---|
| BSON | 172 字节 |
| Universal Binary Json | 150 字节 |
| MessagePack | 120 字节 |
| JSONH | 116 字节 |
| BJSON（内置自适应哈夫曼压缩） | 115 字节 |
| JKSN | 109 字节 |
如果各位读者对此项目感兴趣，且有空余时间，不妨让 JKSN 变得更好：
目前 JKSN 已经有 Python 3、Python 2、浏览器 JavaScript、Node.JS、C 五种环境的实现了。如果你愿意，请帮助我为 JKSN 补上 PHP 5、Java 的实现。
追求模范性和稳定性的实现可以直接 fork JKSN repository 并发给我 Pull Request；追求速度的实现可以另开新 repository 并通知我。
如果你知道怎么重新组织 JSON 结构让其更易于压缩，请联系我。我希望和你探讨问题。
