基于Python zlib预测压缩数据最大尺寸以适配Zip64

核心问题 #

在流式生成ZIP文件时，需仅在必要时启用Zip64（避免兼容性下降），但Zip64需在压缩前指定。已知未压缩数据总大小时，需通过zlib的最坏压缩输出大小判断是否需要启用Zip64。

zlib最坏压缩输出大小计算 #

当数据完全不可压缩（比如随机加密字节）时，zlib会切换到存储模式（直接存储原数据并添加块开销），此时压缩后的数据会比原数据略大。具体大小取决于是否包含zlib头/尾，以及DEFLATE的块划分规则：

公式说明 #

1. 带zlib头和尾（wbits=默认15）

总大小 = zlib头部(2字节) + 原数据大小(N) + 块开销 + zlib尾部(4字节)
块开销：DEFLATE存储块最大为65535字节，每个块需额外5字节（1字节块类型+4字节长度/反长度校验），因此块开销为 ceil(N / 65535) * 5

最终公式：

def max_compressed_zlib(N):
    block_count = (N + 65534) // 65535  # 等价于ceil(N/65535)
    return 2 + N + block_count * 5 + 4

2. 原始DEFLATE（wbits=-zlib.MAX_WBITS，无zlib头/尾）

仅保留原数据和块开销：

def max_compressed_deflate(N):
    block_count = (N + 65534) // 65535
    return N + block_count * 5

参数影响 #

压缩级别（level）、memLevel对最坏情况输出无影响——无论level设为0-9，不可压缩数据都会触发存储模式；memLevel仅影响内部缓冲区大小，不改变块的最大划分尺寸（始终为65535字节）。只有wbits参数决定是否包含zlib头/尾，从而影响总大小。

动态启用Zip64的逻辑 #

1. 计算未压缩大小uncompressed_size和对应的最大压缩输出max_compressed_size
2. 满足以下任一条件时，启用Zip64：
   • uncompressed_size >= 4294967296（4GiB，Zip格式的32位大小上限）
   • max_compressed_size >= 4294967296

Python版本兼容性注意 #

不同Python版本的zlib绑定可能基于不同版本的zlib底层库，但DEFLATE存储模式的块规则是标准化的，因此最坏情况的大小计算是通用的。仅需注意极端场景（比如单块接近65535字节时的flush行为），但这不会影响总大小的最大值计算。

未知未压缩大小的场景 #

若无法提前获取未压缩数据大小，类似Java的"自动Zip64"模式（先按非Zip64写入，超过阈值后回溯修改目录）在纯流式场景（如网络输出）下不可行，且存在libarchive等工具的兼容问题。这种情况下，建议要么默认启用Zip64，要么提供用户显式开关控制。

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