问题标签 [data-compression]

我有一个 gzip 压缩文件（100GB 未压缩 40GB 压缩）。现在我想修改一些字节/字节范围 - 我不想更改文件大小。

例如字节 8 + 10 和字节 5000 - 40000

在不重新压缩整个文件的情况下这可能吗？

斯特凡

我需要存储万亿个 URL 列表，其中每个 URL 列表将包含约 50 个 URL。将它们压缩以进行磁盘存储的最节省空间的方法是什么。

我正在考虑首先删除像“http://”这样的无用信息，然后构建一个最小的有限状态自动机并保存它。

另一种选择是构建一个逗号分隔的 URL 字符串，并使用常规压缩（如 GZIP 或 BZ2）压缩此字符串。

如果我不关心速度，哪种解决方案会产生最佳压缩。

我需要在我的应用程序中使用 7zip，我正在寻找 LZMA sdk 的包装器。我发现了一个由 Chadwick McNab 开发的有趣的 SevenZip++ ( https://bitbucket.org/cmcnab/sevenzip/overview )。问题是这个包装器使用 7za.dll。

是否可以在没有 7za.dll 的应用程序中使用 7zip？有任何不使用 7za.dll 的 LZMA sdk 包装器吗？

我需要压缩大于 1GB 的大型 ODB 文件。我使用了 LZMA 算法，最多可以压缩 22%。有没有更好的方法以更好的压缩比压缩这些类型的文件？压缩必须是无损的。

我有一个 JSON 文件，它可以包含 30-50 百万个数据对象。我想实现以下...

• 最好的数据压缩，以减少磁盘上的 JSON 文件大小。
• 在 ac# 应用程序中开发高效的数据查询例程，以按需将过滤后的数据加载到内存中。

请注意，我必须在本地计算机上执行此操作，并且不涉及服务器。

我需要您的专家意见来实现这些目标。

谢谢！

我正在尝试使用压缩以FITS 格式写入数据。这是我尝试过的：

它可以工作，因为返回状态为零。但我无法用任何东西打开文件。此外file test3.fits回报

而如果我删除线fits_set_compression_type......我得到

这是正确的（我可以打开图像）

我在这里做错了什么？

我有一个表，其中包含两个包含大量文本的文本字段。出于某种原因，我们的桌子开始呈指数增长。我怀疑 TOAST（postgres 中文本字段的压缩）不能自动工作。在我们的表定义中，我们没有定义任何子句来强制压缩这些字段。有没有办法检查压缩是否对该表起作用？

或者更准确地说，当两个相同的字符串相互连接时，为什么 zlib 不能压缩整个第二个字符串？似乎当匹配字符串紧跟在同一字符串的前一个实例之后开始时，zlib 将第一个字符作为字符串文字发出，然后发出对前一个字符串减去第一个字符的向后引用。

例如，如果我使用 zlib 对字符串latelate进行压缩，则输出是 5 个字符串文字，后跟一个反向引用......

或霍夫曼编码...

我通过使用“原始”放气流（即windowBits = -15）和固定霍夫曼编码（即压缩策略是Z_FIXED）简化了输出。

为什么 zlib 在使用对“ate”的反向引用之前必须发出第二个文字字符 'l'？

也就是说，为什么不能输出……？

我尝试用我自己的 deflate 实现强制第二个版本，但 zlib 不会膨胀输出。我收到错误“无效或不完整的放气数据”。

我想知道我们可以在多大程度上进行无损数据压缩；我无法找到无损算法的在线模拟器来执行一些经验测试。我可以自己做一个，但不幸的是我这段时间没有足够的时间；我仍然对我的直觉感到好奇，我将对其进行解释。

让我们只看两个更流行的算法：Huffman Coding和Run-lenght Enconding.

假设我们有一个数字A符号的字母表和该字母表中任意长的符号序列：例如：

现在，如果我们只用固定长度的n比特字对每个符号进行编码，我们就有了未压缩的序列，也就是长的N比特。

如果我们使用 Huffman 对序列进行编码，我们将使用H位而不是N位，从而节省(1-H/N)*100%位空间。

如果我们使用 RLE 编码相同的序列，我们将使用R位，节省(1-R/N)*100%.

我想知道，如果我们应用RLE + Huffman或者Huffman + RLE我们可以比只使用其中一个来节省更多空间会发生什么。

这对我来说似乎是一个非常基本的想法，但谷歌搜索我没有找到任何关于这个主题的有趣内容。

编辑：嗯，我可能没有考虑到如果我先使用 RLE，我将无法使用 Huffman，因为与单个符号的固定长度代码的对应关系会丢失；但仍然应该可以先使用 Huffman，然后再使用 RLE。

顺便说一句，我对其中的逻辑很感兴趣，我的意思是串联使用多个无损压缩算法。

编辑 2：当我在评论 Mark Adler 的回复时，我意识到我可能已经找到了我的问题的答案。就是这个：

哈夫曼，这是一个符号到符号的代码，如何影响检测？

假设我们有以下代码：AABCABAAB. 在纯二进制中，它将被编码为00 00 01 10 00 01 00 00 01（obv 空格仅出于可读性目的）。霍夫曼将其编码为0 0 11 10 0 11 0 0 11. 空格更多地显示了字符串是如何没有改变的，因此可以检测到完全相同的重复数量，假设我们正在处理这个范围内的代码（符号方面）。

这让我想到了另一点（鉴于这已经是很长的评论，我不会在这里讨论）：逐位分析代码。

所以，我实际上认为我得出了一个结论：正如我们所知，任何字典（或基于替换的）编码器将可变数量的符号分组为固定长度的码字，而 Huffman（或任何其他熵编码器）编码固定长度的符号成可变数量的比特，从而将熵逼近到最小值；因此，让霍夫曼先运行是没有意义的（而且只会浪费计算），因为另一种算法很可能会引入更多霍夫曼可以减少的冗余。

当然这只是一篇理论论文，因为在实践中我们可以考虑其他因素（例如计算时间）......更不用说要编码的字符串的不同配置可能导致不同结果的事实。但是，嗯……这对我来说很有意义。:)

我想估计一个文件、文件或文件目录在压缩后的最终大小。我正在寻找可以估计/计算的程序或脚本。

有任何想法吗？

这样的工具必须可以在命令行上访问（对于 Linux/Mac）。如果它可以与所有或大多数常用的无损压缩算法（gz、bzip2、zip等）一起工作，那将是最有用的。如果它列出了各种方法的压缩比（或等效用途，生成的文件大小），则加分。我完全希望这样的工具会在产生输出之前扫描文件，但如果可能的话，我想避免任何实际的压缩。

如果重要的话，我希望这是通用的：

• 它应该适用于任何类型的文件，包括易于压缩的 ASCII 文本文件、二进制数据以及介于两者之间的所有文件。（当然，这在很大程度上取决于压缩算法/工具。）
• 它应该与各种压缩算法/工具一起使用

下面的 BASH 脚本为一种压缩算法做了我想要的，但它不算数（我想要一个估计）：

我主要将其用于较大的文件（大于 1 GB），这就是为什么我只想要估计而不是实际压缩的原因。