Java 和 C 之间的压缩兼容性答案

【问题标题】：Compression Compatability between Java and CJava 和 C 之间的压缩兼容性
【发布时间】：2013-09-04 20:35:34
【问题描述】：

我的 java 桌面客户端软件使用 JSON 与用 C 编写的遗留后端系统进行通信（服务器上有一个转换器）在批量部署时消耗了太多带宽。字段。

在研究了压缩选项后，我得出结论，流行的 JSON 压缩工具不适合我的情况。它们似乎是基于跨网络传递数据库查询结果的场景，这不是我的情况。没有方便的行/列算法可用于轻松压缩。我们的数据更复杂。

所以我们开始使用压缩，Java 的 DeflaterOutputStream 和 InflaterInputStream（或者可能是它们的 GZIP 和/或 ZIP 风格）。在 C 端，会有类似的东西，可能是通过 RedHat 提供的 zlib 库，我们的服务器在该库上运行。

在我步入一堆蠕虫之前，有经验的人能否告诉我 zlib 压缩和 Java 支持的压缩的兼容性如何？ Java 压缩选项中的一种或另一种比另一种更好吗？比另一个更快？

顺便说一下，协议是双向的。 Server 和 Client 都使用 JSON 对消息进行编码，所以在我的场景中，双方都需要能够压缩和解压。提前致谢。

【问题讨论】：

【解决方案1】：

Java 中的 Deflator、GZIP 和 ZIP 库都使用 zlib 库进行实际压缩，因此它们应该完全相同，而不仅仅是兼容。很可能 GZIP 和 ZIP 更便携，因为 Deflator 只是具有较小页眉/页脚的压缩数据

【讨论】：

感谢您的信息！我认为我还需要提供在解压缩端处理压缩或未压缩数据的能力，因为部署可能不均匀。但我已经在这里找到了一些东西。
您拼写正确，但 Java 没有。 Java 中的类拼写错误：Deflater.
Java Deflater class 不会生成没有标头/尾标的数据，除非您使用 nowrap true 要求它。默认情况下，Deflater 生成 zlib 包装的 deflate 数据，带有两字节的 zlib 头和四字节的 zlib 尾。
@MarkAdler - 感谢您的信息！这是一个问题。如果输入不是 GZIP 格式，则 DeflaterInputStream 的 GZIPInputStream 风格会方便地引发 IOException。 DeflaterInputStream 没有。由于在我的情况下检测非压缩数据很重要，您建议使用gz格式还是简单的deflate格式，如果是后者，尝试inflate时检测未压缩数据的策略是什么？
如果数据不是 zlib 格式，DeflaterInputStream 也应该抛出异常。我没有尝试过，但我不知道它还能做什么，因为如果它无法解码标题，它就无法继续。