我的问题是：有没有标准的压缩格式可以确保在压缩的数据流中不会出现特定的分隔符序列？
我们想要设计一个二进制文件格式，包含大量的顺序数据（3d坐标+其他数据，对这个问题并不重要）。每个块都应该使用标准的压缩格式进行压缩，比如gzip、zip等等。。。
因此，文件结构如下：
FileHeader
ChunkDelimiter Chunk1_Header compress(Chunk1_Data)
ChunkDelimiter Chunk2_Header compress(Chunk2_Data)
...用例如下：在hadoop中，文件应该以拆分方式读取，因此我们希望能够从文件中的任意字节位置开始，并通过查找分隔符序列找到下一个块的开始。 -> 分隔符序列不应出现在块中。
我知道我们可以对压缩后的数据进行后处理，“转义”分隔符序列，以防它出现在压缩输出中。但我们最好避免这种情况，因为解码器中需要“反向转义”，增加了复杂性。
我们选择此文件格式的更多原因：
第三方应易于阅读 -> 首选标准压缩算法。
大文件；流操作：开始写入文件时，数据量和块数未知 -> 很难在头中写入块字节位置的开始。
2条答案
按热度按时间pb3s4cty1#
我不会用压缩方案的名称来回答你的问题，但会给你一个提示，告诉你其他人是如何解决同样的问题的。
让我们来看看avro。基本上，它们有相似的要求：文件必须是可拆分的，每个数据块都可以压缩（甚至可以选择压缩方案）。
从avro规范中我们了解到，可拆分性是通过同步标记来实现的（“对象存储在可以压缩的块中。在块之间使用同步标记，以便高效地拆分文件以进行mapreduce处理。“）。我们还发现同步标记是一个16字节随机生成的值（“这个文件的16字节随机生成的同步标记”）。
它如何解决你的问题？好吧，既然马丁·克莱普曼几年前就为这个问题提供了一个很好的答案，我就复制粘贴他的信息
2013年1月23日21:09，josh spiegel写道：
据我所知，avro容器文件经常包含同步标记，以支持拆分文件。请参见：https://cwiki.apache.org/avro/faq.html#faq-目标文件格式%3f中的同步标记的目的是什么
（1） 为什么每个容器文件的同步标记都不相同(i、 e.每次随机生成有什么意义）
（2） 至少在理论上，自然发生的数据是否可能包含与同步标记匹配的字节？如果是这样，这会破坏同步吗？
谢谢，乔希
因为如果它是可预测的，它有时会不可避免地出现在实际数据中（例如，想象一下，说明同步标记是什么的avro文档被网络爬虫下载并存储在avro数据文件中；然后同步标记将出现在实际数据中）。数据可能来自恶意来源；随机标记使其无法利用。
可能，但极不可能。给定的随机16字节字符串出现在PB（均匀分布）数据中的概率约为10^-23。更有可能是你的数据中心被陨石摧毁了(http://preshing.com/20110504/hash-collision-probabilities).
如果同步标记出现在您的数据中，它只会中断读取文件，如果您碰巧也要查找文件中的该位置。如果你只是按顺序读一遍，什么都不会发生。
马丁
链接到avro邮件列表存档
如果它对avro有用，它也会对你有用。
nnvyjq4y2#
不。我知道没有一种标准的压缩格式不允许任何位序列在其中的某个地方出现。否则会（稍微）降低压缩，违背压缩格式的最初目的。
解决方案是a）对序列进行后处理，以使用指定的中断模式，如果中断模式意外出现在压缩数据中，则插入转义符--这保证可以工作，但您不喜欢此解决方案，或者b）相信宇宙并没有与你作对，使用一个长间隔模式，其长度确保从现在起直到宇宙热死的任何时候，它都不太可能意外地出现在所有的序列中。
对于b）通过为每个文件选择一个随机模式，并在文件的开头提供随机模式，您可以在一定程度上防止宇宙合谋攻击您。对于真正的偏执狂，你可以更进一步，从之前的模式中，为每个连续的中断生成一个新的随机模式。
请注意，宇宙可以为一个固定的模式与你合谋。如果您使用固定中断模式生成这些压缩文件中的一个，然后将该文件包含在另一个也使用该中断模式的压缩归档文件中，则该归档文件可能无法压缩此已压缩的文件，而只是将其存储起来，从而保留与归档文件使用的相同的固定中断模式。
b）的另一个保护措施是通过观察破裂前的碎片没有终止来检测错误破裂的减压失败，并通过将该碎片和下一个碎片放回一起并再次尝试减压来处理特殊情况。你也很有可能在下面的文章中发现这个问题，因为解压失败了。