NodeJS：低带宽环境下传输大型decimal数组的最优方法

嘿，这个场景我太熟了——decimal数组的压缩确实是个有意思的问题，毕竟纯JSON的冗余度太高了，尤其是对数值类型来说。咱们一步步拆解，看看哪种方案最适配你的需求：

在选方案前，得先理清几个关键点：

• 客户端是什么环境？是浏览器、Node.js服务，还是移动端APP？
• 你的decimal精度要求有多高？会不会有超长小数位（比如金融场景的精确小数）？
• 你是想要序列化+压缩一步到位的方案，还是接受先序列化再单独做压缩？

1. UBJSON：原生二进制JSON，但未必是最优解 #

UBJSON是JSON的二进制版本，它会把decimal这类数值直接转成二进制存储，避免了JSON里把数值字符串化的冗余（比如123.456在JSON里是7个字符，UBJSON里可能只需要8字节的double，甚至更短的整数类型如果精度允许）。但有几个要注意的点：

• 如果你的数组里有大量重复值或规律数值，UBJSON的内置$zip压缩标记能进一步缩小体积，但效果可能不如gzip这类专门的压缩算法。
• 客户端解析UBJSON需要专门的库支持，比如浏览器得引入对应的解析包，Node.js有现成的，但移动端可能需要额外适配。

2. JSON序列化+gzip压缩：简单高效，兼容性拉满 #

你已经看到RAR能把17MB的JSON压到1.9MB，那用gzip压缩JSON字符串的效果会非常接近（毕竟RAR和gzip都是无损压缩，针对文本冗余的压缩效率差不多）。这个方案的优势简直拉满：

• 兼容性极强：几乎所有客户端都支持gzip解压缩——浏览器会自动处理带Content-Encoding: gzip响应头的内容，Node.js和移动端也有内置API。
• 实现成本极低：不需要改太多现有代码，只需要在发送前把JSON字符串做gzip压缩，客户端接收后解压缩再JSON.parse就行。
• 压缩效果达标：针对你的场景，17MB的JSON压到2MB左右完全没问题，和RAR的结果基本一致。

3. MessagePack：比UBJSON更流行的二进制JSON替代品 #

MessagePack和UBJSON思路类似，但生态成熟度更高，支持的语言和库更多。它对数值类型的存储更高效：如果你的decimal能转成double且精度足够，体积会比JSON小很多；如果是整数，还会用更短的二进制格式存储。

• 优势：生态成熟，解析速度快，压缩后的体积和UBJSON差不多甚至更小。
• 注意点：如果你的decimal是高精度的（比如超过double精度的金融场景小数），MessagePack需要专门的decimal类型支持，或者只能转成字符串存储，这时候压缩效果会打折扣。

4. 纯数值二进制数组：极致压缩的终极方案 #

如果你的数组里全是decimal数值，甚至可以跳过JSON/UBJSON这类通用格式，直接把数值转成二进制数组（比如用Float64Array存储，或者针对高精度decimal用专门的二进制编码），然后转成base64或者直接发送二进制数据。这种方式的体积是最小的：

• 举个例子：17MB的JSON如果对应100万个decimal，转成二进制数组大概只有8MB，再用gzip压缩的话，体积可能比1.9MB还小。
• 缺点：需要处理精度问题，如果是高精度decimal（比如Java的BigDecimal），得用专门的二进制编码逻辑，客户端解析也需要对应处理，实现成本稍高。

• 如果优先级是兼容性>实现成本：直接选JSON+gzip，几乎零学习成本，客户端不用额外引入库，压缩效果完全能满足你的需求。
• 如果优先级是极致体积+解析速度：选MessagePack（或者UBJSON，如果你已经熟悉它的话），但要确保客户端有对应的解析库，并且处理好decimal的精度问题。
• 如果是纯数值数组且精度可控：直接用二进制数组+gzip，能拿到最小的体积。

内容的提问来源于stack exchange，提问作者J.D.