我的问题是：是否有任何标准压缩格式可以确保压缩数据流中不会出现某个分隔符序列？
我们想设计一种二进制文件格式，包含大量的顺序数据（3D坐标+其他数据，对于这个问题并不重要）。应使用标准压缩格式压缩每个块，如GZIP，ZIP，......
因此，文件结构如下：
FileHeader
ChunkDelimiter Chunk1_Header compress(Chunk1_Data)
ChunkDelimiter Chunk2_Header compress(Chunk2_Data)
...
用例如下：文件应该在Hadoop的分割中读取，所以我们希望能够从文件中的任意字节位置开始，并通过查找分隔符序列找到下一个块的开头。 ->分隔符序列不应出现在块中。
我知道我们可以对压缩数据进行后处理，并且＃34;转义＆＃34;在压缩输出中出现的分隔符序列。但我们最好避免这种情况，因为＆＃34;反向逃避＆＃34;在解码器中将需要，增加了复杂性。
我们选择此文件格式的更多事实：
->首选标准压缩算法应易于阅读。->难以在头中写入块起始字节位置。答案 0 :(得分：1)
我不会用压缩方案名称回答你的问题，但会告诉你其他人如何解决同样的问题。
让我们来看看Avro。基本上，它们有类似的要求：文件必须是可拆分的，每个数据块都可以压缩（你甚至可以选择压缩方案）。
从Avro Specification我们了解到，在同步标记的帮助下实现了可分割性（“对象存储在可以压缩的块中。块之间使用了同步标记，以便有效地分割文件用于MapReduce处理。“）。我们还发现同步标记是 16字节 随机生成的值（“此文件的16字节，随机生成的同步标记。< / em>的“）。
它如何解决您的问题？好吧，因为几年前Martin Kleppmann对这个问题提供了一个很好的答案，我只会复制粘贴他的信息
2013年1月23日21:09，Josh Spiegel写道：
据我了解，Avro容器文件包含同步标记 经常支持拆分文件。看到： https://cwiki.apache.org/AVRO/faq.html#FAQ-Whatisthepurposeofthesyncmarkerintheobjectfileformat%3F
（1）为什么每个容器文件的同步标记都不相同？ （即每次随机生成它的重点是什么）
（2）至少在理论上，是否有可能将自然发生的数据用于 包含与同步标记匹配的字节？如果是这样，这会打破吗？ 同步？
谢谢， 约什
因为如果它是可预测的，它有时会不可避免地出现在实际数据中（例如想象Avro文档，说明 同步标记是什么，由网络爬虫下载并存储 一个Avro数据文件;然后同步标记将出现在实际中 数据）。数据可能来自恶意来源;使标记随机 这使得利用它变得不可行。
可能，但极不可能。给定的随机16字节字符串出现在PB级（均匀分布）数据中的概率 约10 ^ -23。您的数据中心更有可能被淘汰 陨石 （http://preshing.com/20110504/hash-collision-probabilities）。
如果您的数据中出现同步标记，则只有当您在文件中寻找该位置时，它才会中断读取文件。如果你只是 按顺序阅读，没有任何反应。
马丁
Link to the Avro mailing list archive
如果它适用于Avro，它也适用于你。
答案 1 :(得分：1)
没有。我知道没有标准的压缩格式，它不允许任何位序列出现在其中。否则会（稍微）降低压缩，违背压缩格式的最初目的。
解决方案是a）对序列进行后处理以使用指定的中断模式，并在压缩数据中意外出现中断模式时插入转义 - 这可以保证有效，但是你不喜欢这个解决方案或者b）相信宇宙不会密谋反对你，并使用一个长休息模式，其长度确保在所有序列中不可能出现意外，从现在开始直到宇宙热死亡。 / p>
对于b）你可以通过为每个文件选择一个随机模式，并在文件的开头提供随机模式来保护一下攻击你的宇宙。对于真正的偏执狂，你可以更进一步，从前一个模式为每个连续的休息生成一个新的随机模式。
请注意，Universe 可以针对固定模式与您合谋。如果您使用固定中断模式制作其中一个压缩文件，然后使用该中断模式将该文件包含在另一个压缩存档中，则该存档可能无法压缩此已压缩文件并将简单地存储它，暴露出与存档使用的相同的固定中断模式。
对b）的另一个保护是通过看到断裂前的碎片没有终止来检测不正确断裂的解压缩失败，并通过将该碎片和下一块放回到一起并尝试解压缩来处理该特殊情况再次。你也很可能在下一篇文章中检测到这一点，因为减压失败了。