是否存在gzip字节序列末尾不会出现的字节序列？蓝牙传输重置字节问题

咱们先直接回答你的第一个问题：当然存在永远不会出现在gzip字节序列末尾的字节序列，而且更关键的是，我们能找到永远不会出现在gzip字节序列任何位置的序列——这对你的重置字节需求更有用，毕竟你需要确保重置序列不会和传输的gzip数据中的任何子序列混淆。

为什么能找到这样的序列？ #

gzip数据的结构是严格遵循规范的：它由gzip头部、有效的DEFLATE压缩数据、以及固定的8字节尾部（CRC32校验码+原始数据长度）组成。其中DEFLATE压缩数据的格式有明确约束，某些字节序列会直接违反这些约束，因此不可能出现在任何合法的gzip数据中。

靠谱的重置序列例子 #

给你推荐几个绝对安全的序列：

• 3字节序列 0xFF 0xFF 0xFF：
  DEFLATE的位流是从字节的最高位开始解析的。这三个字节的前3位是111——其中第一位是结束块标记，后两位是块类型。根据DEFLATE规范，块类型11是保留的无效类型，任何合法的DEFLATE数据都不会包含这样的块结构。因此这个序列不可能出现在gzip的压缩数据部分，同时gzip的头部和尾部也不会出现这个序列，所以它绝对不会出现在任何合法的gzip压缩数据中。
• 4字节序列 0x00 0x00 0xFF 0xFF：
  gzip的不压缩块开头是2字节长度+2字节长度的按位取反补码，长度和补码的组合必然是[L, ~L]，所以0x0000和0xFFFF的组合完全不符合规则，不可能出现在合法的gzip数据里。

针对分块传输的额外建议 #

因为你是按最多20字节的分块传输，建议选择长度在3-8字节之间的重置序列——既不会太长影响传输效率，又能彻底避免和gzip数据中的随机子序列碰撞（像0xFF 0xFF 0xFF这种本身就不会出现在gzip数据中的序列，3字节长度就足够安全）。

内容的提问来源于stack exchange，提问作者user2074945