索引/随机访问 7zip .7z 档案答案

【问题标题】：Indexing / random access to 7zip .7z archives索引/随机访问 7zip .7z 档案
【发布时间】：2011-05-26 08:56:33
【问题描述】：

提供随机访问 gzip 和 bzip2 档案的工具：

gzip zran.c from the ghostscript source code
bzip2 seek-bzip by James Taylor

我正在为 7zip 寻找任何类似的解决方案

（目标是离线使用有时巨大的 Wikipedia 转储文件，而无需保留解压缩的副本）

【问题讨论】：

有点迂腐，我承认，但真正的目标是避免重新压缩档案，而不是避免解压缩它们？（我希望生成索引需要解压缩存档，尽管是在内存中而不是在磁盘上。）如果您不介意一次性重新压缩阶段，那么您可以使用 7z 重新压缩SOLID 选项已禁用（或设置为一个较小的值），它为您提供了可以随机访问的存档，而无需大量等待。（国际海事组织，该默认实体选项在更多地方使用。:()
我不介意将它们解压缩为创建索引的一次性成本。但我不想重新压缩它们，因为我希望有限的机器（例如上网本）能够在发布时使用未更改的存档文件。重新压缩速度要慢得多，并且占用更多资源，而且重新压缩的存档将不再具有与已发布的匹配的 MD5 校验和。让发布者生成不同格式的档案可能需要一些协商，但我会保留作为最后的手段，在这种情况下，连接许多较小的 7zip 档案可能也可以。

标签： indexing compression large-files 7zip random-access

【解决方案1】：

我认为最好总结一下 GZIP、BZIP2 和 LZMA 的内部机制以明确一些事情：

GZIP 实际上是一种使用 Deflate 算法的格式。由于静态霍夫曼代码（deflate 文档也提到了动态霍夫曼，但实际上它们也是静态的）deflate 应该被编码为块状（滑动窗口是这里的另一个术语）。 zran.c 似乎找到了这些块的边界，并尝试最多解码 2 个连续的块，这些块可能包含一些 KiB 未压缩数据，以收集足够的数据进行解压缩（以填充整个 32 KiB 窗口）。因此，即使没有索引表，随机访问也是完全可能的。
BZIP2 实际上是一种 BWT 类压缩算法。由于 BWT 的性质，难怪它是分块的。每个单独块的块限制为 900 KiB。此外，块边界被很好地定义为易于恢复过程（具有巨大的不同标记）。因此，您甚至可以一次使用多个线程来解压缩所有数据。换句话说，即使没有任何表格，随机访问也是完全可能的（格式已经支持）。
LZMA 最多支持 1 GiB 字典，并且它不是按块编码的。它使用范围编码器来编码概率而不是霍夫曼编码器。即使考虑到 64 MiB 的窗口大小（非常常见的值），由于范围编码器的性质，我们不能简单地在给定的随机点解码，直到填满整个窗口。此外，LZMA 的状态机也很麻烦。所以，它的实现是相当困难的，甚至是不可能的。

也许 LZMA2 或 PPM 方法可用于此类用途（7-zip 在 7-zip 格式中也支持它们）。 PPM 在其统计信息已满时刷新其模型，并且 LZMA2 有意在某个时间间隔刷新某些状态以启用多线程解压缩。他们的随机访问实现是可能的。

【讨论】：

【解决方案2】：

我的lzopfs 项目允许随机访问 lzop、gzip、bzip2 和 xz 文件。 XZ 文件是 LZMA 编码的，所以希望它可以替代 7-zip 来满足您的目的。请注意，对于实际的随机访问，您需要使用阻塞的编码器创建 xz 存档，例如 pixz 或 xz-utils 5.1.x alpha 的多线程模式。

【讨论】：

瓦西，谢谢！你能描述一下 lzopfs 是如何处理每种格式的吗？是否需要完全解包来创建一些索引？它可以与完整的维基百科转储一起使用吗？
当然。对于 xz，只要您进行阻塞编码，可搜索性很便宜并且内置在文件格式中。对于其他格式，lzopfs 第一次看到文件时，会对其进行扫描以生成索引文件。扫描 lzop 非常快，但是对于 bzip2 和 gzip 则很慢，相当于解压整个文件。至少一旦索引出现，寻找是便宜的。如果可以找到您需要寻找的偏移量，它将适用于维基百科转储。你有什么方法可以得到这些信息吗？
vasi，上次我检查 - stackoverflow.com/q/7882337/196561，完整的 wikidump（包含所有历史记录）被打包为单块 7z，lzma 方法。要在 wiki 转储中查找偏移量，我需要进行一次扫描以构建索引（“文章名称”来偏移），但也可以进行二进制搜索（每几兆字节中至少有一个文章名称，所有名称均已排序）。 PS：对于 bzip2，您可以扫描 6 字节“pi”常量以查找每个压缩块的开头（但该常量未与字节边界对齐）。
根据 Matt Mahoney 的Large Text Compression Benchmark，还有比 lzop 更快的方法，比如 'libzling'、'etincelle a3'、'zlite'、'slug 1.27'、'thor 0.95 e4'，所有压缩比 lzop 更好更快。不知道寻求能力。
@osgx，我确实搜索了 bzip2 常量。但我仍然会进行解压缩以确保它不是虚假的，因为常数可能会（以低概率）出现在真实的块数据中。