zlib压缩内存数据应先确认compress()和uncompress()的边界条件;二者是最轻量接口,适用于小数据量。

zlib 压缩内存数据:先确认 compress() 和 uncompress() 的边界条件
这两个函数是 zlib 最轻量的内存压缩接口,适合小数据量(解压。它们不支持流式处理,也不自动管理内存——你必须提前分配好输出缓冲区,并传入其大小指针。
常见错误是传入的 destLen 指针未初始化,或指向的值小于实际所需空间,导致返回 Z_BUF_ERROR;更隐蔽的问题是:解压时若输入数据被截断或损坏,uncompress() 可能静默返回 Z_DATA_ERROR 而不抛异常,容易被忽略。
-
compress()要求目标缓冲区大小至少为compressBound(srcLen)返回值,不能凭经验估算 - 解压前务必检查原始压缩数据长度是否 ≥ 4 字节(zlib header 最小长度),否则直接跳过调用
- 返回值必须显式判断:
Z_OK才代表成功;Z_MEM_ERROR表示堆内存不足(少见但可能发生在嵌入式环境)
uLong destLen = compressBound(srcLen);
Bytef* dest = new Bytef[destLen];
int ret = compress(dest, &destLen, src, srcLen);
if (ret != Z_OK) {
// 处理错误,不要假设 destLen 仍有效
}
// 注意:destLen 此时已被写入真实压缩后长度用 z_stream 手动管理流式压缩:避免 deflateInit() 后忘记 deflateEnd()
当需要分块压缩、控制压缩级别、或复用压缩上下文时,必须使用 z_stream 结构体 + deflate* 系列函数。这是生产环境更可控的方式,但生命周期管理极易出错。
最常踩的坑是:在 deflateInit() 成功后,因异常提前退出而未调用 deflateEnd(),导致 zlib 内部分配的内存泄漏(尤其在循环中反复创建时);另一个是误将 z_stream 当栈变量传递给异步回调,而回调执行时该变量已析构。
立即学习“C++免费学习笔记(深入)”;
-
deflateInit2()第二个参数可设压缩级别(Z_DEFAULT_COMPRESSION或 -1~9),负值启用 gzip header(即生成 .gz 兼容格式) - 每次调用
deflate()前,必须设置strm->next_in、strm->avail_in、strm->next_out、strm->avail_out,且不能重叠 - 压缩结束需调用
deflate(strm, Z_FINISH),并循环直到返回Z_STREAM_END,否则输出不完整
z_stream strm; strm.zalloc = Z_NULL; strm.zfree = Z_NULL; strm.opaque = Z_NULL; int ret = deflateInit2(&strm, Z_BEST_COMPRESSION, Z_DEFLATED, 15+16, 8, Z_DEFAULT_STRATEGY); if (ret != Z_OK) return ret;strm.next_in = const_cast
(src); strm.avail_in = srcLen; strm.next_out = dest; strm.avail_out = destSize; while (strm.avail_in > 0) { ret = deflate(&strm, Z_NO_FLUSH); if (ret != Z_OK) break; } ret = deflate(&strm, Z_FINISH); // 必须收尾 deflateEnd(&strm); // 必须释放
解压时识别输入格式:gzip、zlib、raw deflate 三者不能混用
zlib 库默认按「zlib 格式」解压(RFC1950),但网络传输或文件读取的数据可能是 gzip(RFC1952)或 raw deflate(RFC1951)。若格式不匹配,inflate() 会立即返回 Z_DATA_ERROR,而不是尝试自动探测。
关键区别在头部字节:zlib 以 0x78 开头(常见 0x78 0x01, 0x78 0x9C);gzip 以 0x1F 0x8B 开头;raw deflate 无标准 header。强行用 zlib 模式解 gzip 数据,前两个字节就会校验失败。
- 解压前可用前两字节快速判断:
if (data[0] == 0x1F && data[1] == 0x8B)→ 用inflateInit2(&strm, 16+MAX_WBITS) - 若确定是 raw deflate(如某些协议自定义封装),用
inflateInit2(&strm, -MAX_WBITS)(负窗口位数) - 永远不要依赖
inflate()自动识别格式——它不会
C++ RAII 封装要点:别让 z_stream 的手动管理污染业务逻辑
裸用 z_stream 容易漏掉 deflateEnd()/inflateEnd(),也难统一错误处理。用 RAII 封装是必要选择,但要注意几个细节:
- 移动构造/赋值必须置空源对象的
strm->opaque,否则双重deflateEnd()会 crash - 不要在构造函数里调用
deflateInit2()并吞掉错误——应让调用方感知初始化失败 - 压缩/解压方法应返回
std::pair:前者是 zlib 错误码,后者是本次处理的有效字节数,方便上层做流控 - 避免在析构函数里抛异常(
deflateEnd()理论上也可能失败),一律用返回值或日志
真正容易被忽略的是:zlib 的压缩率和速度高度依赖数据特征。对已经加密或随机性高的内存块(如 AES 加密后的密文),zlib 压缩率趋近于 0,甚至膨胀。上线前务必用真实数据样本跑压测,而不是只测文本或图片。











