重新使用与压缩数据分开的“Deflate”数据字典答案

【问题标题】：Reusing a data dictionary for 'Deflate' separate from the compressed data重新使用与压缩数据分开的“Deflate”数据字典
【发布时间】：2013-11-26 17:59:19
【问题描述】：

我在 XML 文件中存储了许多 base64 编码的 64 位双精度块。双数据看起来都差不多。

目前在编码之前使用 java 'Deflate' 算法对双精度数据进行压缩，但是文件中的每个二进制数据块都有自己的 deflate 数据字典，这是我希望大大减少的开销。 'Deflater' 类有一个我想使用的 'setDictionary' 方法。

所以问题是：

1)。有没有人对如何最好地构建我自己的单个自定义数据字典有任何建议？基于他可以用于多个放气操作的多个双精度部分（x8 字节），即对所有压缩使用相同的字典？我是否应该在所有字节数组中查找公共字节，并将最常见的字节放在字典数组的末尾？

2)。我可以将（自定义）数据字典从压缩数据中分离出来，然后再根据压缩数据设置字典，然后再次膨胀数据吗？

3)。放气算法是否会采用我的自定义数据字典，然后无论如何创建自己的略有不同的数据字典，既使我的单一数据字典无效，又减少使用单一数据字典可能节省的空间？

4)。有人可以详细说明zlib压缩数据的结构，以便我自己尝试将数据字典与压缩数据分开吗？

我只想在我的文件中为数据字典使用一次空间，并将它用于我的文件中我的双数据的每个块，但不将它与双数据一起存储。如果数据字典不能与压缩数据分开/单独存储，那么构建自定义奇异字典似乎没有什么价值，因为每个压缩块都有自己的字典。是这样吗？

【问题讨论】：

最简单的 imo 是压缩整个 xml，而不是跨 xml 元素进行压缩。这对你来说可行吗？
@Taylor 与二进制文件相比，XML 元素（我的二进制文件除外）的大小很小，所以我不担心压缩整个文件（即文本）——这是我需要压缩的二进制文件.这是可行的，但压缩整个文件意味着压缩我的二进制数据的base64表示，我想在base64编码之前进行二进制压缩。
压缩文件的事情是微不足道的。你所追求的是大量的工作、更多的代码和非常规的启动。所有这些都将使这难以维护。如果您正在做所有这些工作以避免更多地压缩您的文档，或者因为您希望在编码之前进行压缩（为什么？），那么努力/收益比似乎并不值得。只是我的 0.02 美元
@Taylor 重点是最小化数据字典在每个压缩块中占用的空间。如果所有块（可能有数千个）共享一本字典并且不需要自己的字典，我会认为这是一个潜在的空间节省者。编码（base64）只是发生，以便数据可以在 XML 中持久保存并通过网络传输，它实际上与我正在尝试做的事情无关。
我还是不明白你为什么不压缩整个 xml 文档。不是想成为一个混蛋，它只是让我觉得简单得多。

标签： java binary double zlib deflate

【解决方案1】：

您可以设置一个由数据中常见且频繁使用的字符串组成的固定字典，也可以将最后 n 个块串联起来用作字典。无论哪种方式，压缩和解压缩端都需要相同的字典来处理任何给定的块。
字典未随数据一起发送。这就是重点。另一方需要知道用于解压缩的字典，使用类似于#1 中的方法。
deflate 使用的字典没有结构。在任何时间点，您都使用前 32K 的未压缩数据作为字典，在该字典中搜索从该 32K 之后的下一个字节开始的匹配字符串。设置字典可以让压缩器抢先获得前 32K 的数据。就是这样。
“字典”在压缩数据中，就像您解压缩时得到的一样。

【讨论】：

1)。由于我的数据是双打的，我可以在你的答案中用 'strings' 代替 'bytes' 吗？当您说“连接的最后 n 个块”时，您是指我的双数据的最后 n 个块吗？
2)。因此，如果我设置一个自定义字典，它将是唯一使用的字典，并且压缩块中不会有内部字典？ 3）。那么设置字典会阻止创建/使用内部字典吗？ 4）。那么‘字典’和压缩后的数据本身并不是一个压缩块中的两个独立实体，不能分开（这是没有设置自定义字典的情况）？