简介面向需要在 Visual Studio 环境中基于 Zlib 实现 ZIP 解压功能的 C 开发者这份资源集中解决从第三方网站下载的 Zlib 原始代码在 Windows 平台编译失败、工程配置繁琐、依赖关系混乱等常见问题。作者逐项修正源文件错误后重新封装为 myZlib 库32 位 Debug 版库文件与 myZlib.h 头文件均放在 myZlib 文件夹头文件内附有详细调用方式和参数说明引入工程即可直接链接使用。压缩包共包含七百三十八个文件体积约三点五八兆字节类型以 h 头文件、cpp 与 c 源文件、vcxproj/vcproj 工程文件、makefile 构建脚本、txt 说明文档为主其中头文件约一百二十一个、C 源文件约五十八个、C 源文件约四十二个工程内还保留 Zlib 官方为多种平台准备的配置和补丁。整体目录既保留原始 zlib/minizip 组件又新增封装层便于对照学习跨平台移植与静态库封装方法也可以直接引入实际项目使用。目前已有七百五十八人学习下载适合有一定 C 基础、希望快速获得解压能力并保留自定义空间的开发者能明显缩短二次开发中的排错时间。1. 用 Zlib 在 C 里解 ZIP容器格式和压缩流是两码事很多人第一次用 Zlib 解 ZIP 时都踩过同一个坑直接把整个 zip 文件丢给inflate()结果得到一堆乱码。原因很简单ZIP 本身不是一条连续的压缩流而是把一个文件的目录结构、文件数据和压缩流封装在一起的容器格式。Zlib 只负责其中「压缩算法」那一段也就是对容器里的每个条目做 deflate/inflate 处理真正要花功夫的是把 ZIP 的二进制结构拆开、定位每条数据。C 实现 zip 文档解压如果选型正确项目里甚至可以完全不依赖第三方库之外的重量级组件只引入一个 zlib自己写解析逻辑就能在 Windows、Linux 甚至嵌入式环境里稳定读取常见 ZIP 包。这个方案适合需要减少外部依赖、要按需解压单个条目的场景但如果目标是完整支持加密、多卷、zip64那还是换现成库更省心。ZIP 的解压链路可以拆成三条明确的任务从文件尾部找到中央目录索引、靠中央目录拿到每个条目的偏移和大小、再去对应位置读取压缩数据并送给 Zlib 解压。听起来不复杂实际做下来才发现细节不少尤其是数据描述符、文件名编码、路径穿越这三类问题。这篇文章就按我自己实践过的路径从二进制结构讲到可运行的 C 实现。2. 从 EOCD 开始解析 ZIP中央目录结构与读取顺序2.1 ZIP 不是一节到底的数据流而是三段式布局一个正常的 ZIP 文件在磁盘上可以粗暴地分成三段前面是一个接一个的本地文件头每个本地文件头后紧跟该文件的压缩数据中间是整个包所有条目的索引也就是中央目录最后是一个 22 字节的结束记录专业叫 EOCD。ZIP 规定中央目录不需要放在文件末尾EOCD 才是真正的收尾标记所以解析顺序一定要从尾部到头部。EOCD 里存了中央目录的位置和条目总数拿到它才能跳过前面一堆本地段直接去看索引。有人会问为什么不直接从文件开头遍历本地文件头原因很实际本地文件头之间靠压缩数据隔开而压缩数据大小只能通过本地文件头里的字段读出来万一遇到 bit 3 标志开启的情况数据后面还会多出一个数据描述符按顺序硬推很不稳定。中央目录则集中记录了每个条目的文件名、CRC、压缩后大小、解压后大小和本地偏移一次就读完整包的结构是最可靠的入口。2.2 从文件尾部扫出 EOCD注意边界和签名偏移EOCD 的签名固定为PK\x05\x06也就是十六进制0x06054b50但它不一定正好挨着文件末尾因为 EOCD 最后还有一个最多 65535 字节的注释字段。所以安全做法是读取文件最后 2265535 字节在这个窗口里从后往前找签名命中后再按偏移解析各字段。下面的代码是一个把尾部读取和 EOCD 解析合在一起的写法。#include cstdint #include fstream #include vector #include stdexcept #include string #include algorithm struct Eocd { uint16_t disk_num; // 当前磁盘编号 uint16_t cd_start_disk; // 中央目录起始磁盘编号 uint16_t num_entries_disk; // 本磁盘上目录条目数 uint16_t total_entries; // 目录条目总数 uint32_t cd_size; // 中央目录总字节数 uint32_t cd_offset; // 中央目录相对文件头的偏移 uint16_t comment_len; // 注释长度 }; uint16_t ReadU16(const uint8_t* p) { return static_castuint16_t(p[0] | (p[1] 8)); } uint32_t ReadU32(const uint8_t* p) { return static_castuint32_t(p[0] | (p[1] 8) | (p[2] 16) | (p[3] 24)); } Eocd ReadEocd(const std::string path) { std::ifstream f(path, std::ios::binary); if (!f) throw std::runtime_error(cannot open file); f.seekg(0, std::ios::end); auto file_size f.tellg(); if (file_size 22) throw std::runtime_error(file too small to be zip); // EOCD 结构 22 字节注释最长 65535 字节 size_t tail_len std::minsize_t(static_castsize_t(file_size), 22u 65535u); std::vectoruint8_t tail(tail_len); f.seekg(file_size - tail_len); f.read(reinterpret_castchar*(tail.data()), tail_len); if (!f) throw std::runtime_error(read tail failed); // 从窗口末尾往前扫注释里也可能出现伪签名 for (int i static_castint(tail_len) - 22; i 0; --i) { if (tail[i] ! P) continue; if (tail[i 1] ! K) continue; if (tail[i 2] ! 0x05 || tail[i 3] ! 0x06) continue; Eocd e; e.disk_num ReadU16(tail[i 4]); e.cd_start_disk ReadU16(tail[i 6]); e.num_entries_disk ReadU16(tail[i 8]); e.total_entries ReadU16(tail[i 10]); e.cd_size ReadU32(tail[i 12]); e.cd_offset ReadU32(tail[i 16]); e.comment_len ReadU16(tail[i 20]); return e; } throw std::runtime_error(EOCD signature not found); }这段代码有两个容易翻车的地方。第一个是从后往前扫描时窗口起点不能从tail_len - 22往前随意扩因为注释字段可能包含伪造的PK\x05\x06字节扫到伪造签名会导致偏移错乱从最接近文件末尾的合法位置开始扫优先命中真正的 EOCD。第二个是如果解析出来的comment_len加上 22 不等于窗口里实际剩余偏移说明签名窗口位置有问题严谨的实现还应该校验这个一致性。读取完还要判断disk_num和cd_start_disk只要不是 0 就说明是多卷 zip当前这套最小实现直接抛异常就好。2.3 遍历中央目录条目每个文件的信息都在这张表里拿到 EOCD 之后就能定位中央目录的起始偏移和大小。中央目录是一条一条记录连续排列的每条固定的头是 46 字节签名是PK\x01\x02后面跟着文件名、扩展字段和注释。字段里有用的信息包括压缩方法、CRC32、压缩大小、解压大小、通用标志位和本地文件头偏移。下面这段代码用来把中央目录读出来并转成结构体数组。struct Entry { std::string name; // 文件名带路径分隔符 uint16_t method; // 0store 8deflate uint32_t crc; // 解压后数据的 CRC32 uint32_t compressed_size; // 压缩后字节数 uint32_t uncompressed_size; // 解压后字节数 uint32_t local_offset; // 本地文件头的文件偏移 bool is_utf8; // 通用标志位 bit 11 bool encrypted; // 通用标志位 bit 0 }; std::vectorEntry ReadCentralDirectory(const std::string path, const Eocd eocd) { std::ifstream f(path, std::ios::binary); f.seekg(eocd.cd_offset); std::vectoruint8_t buf(eocd.cd_size); f.read(reinterpret_castchar*(buf.data()), buf.size()); if (!f) throw std::runtime_error(read central directory failed); std::vectorEntry entries; size_t i 0; while (i 46 buf.size()) { if (buf[i] ! P || buf[i 1] ! K || buf[i 2] ! 0x01 || buf[i 3] ! 0x02) { throw std::runtime_error(central directory entry signature mismatch); } uint16_t flags ReadU16(buf[i 8]); uint16_t method ReadU16(buf[i 10]); uint32_t crc ReadU32(buf[i 16]); uint32_t comp_size ReadU32(buf[i 20]); uint32_t uncomp_size ReadU32(buf[i 24]); uint16_t name_len ReadU16(buf[i 28]); uint16_t extra_len ReadU16(buf[i 30]); uint16_t comment_len ReadU16(buf[i 32]); uint32_t local_offset ReadU32(buf[i 42]); Entry e; e.name.assign(reinterpret_castconst char*(buf[i 46]), name_len); e.method method; e.crc crc; e.compressed_size comp_size; e.uncompressed_size uncomp_size; e.local_offset local_offset; e.is_utf8 (flags (1u 11)) ! 0; e.encrypted (flags 1u) ! 0; entries.push_back(std::move(e)); // 跳过: 固定头46字节 文件名 扩展字段 注释 i 46 name_len extra_len comment_len; } if (entries.size() ! eocd.total_entries) { throw std::runtime_error(entry count mismatch); } return entries; }这里注意几个字段的读取位置偏移 42 是本地头部偏移这个字段在中央目录里是 4 字节但对 zip64 来说只剩 0xFFFFFFFF 这种哨兵值。我强烈建议解析完total_entries后和实际循环次数做一次校验因为有些第三方打出来的 zip 包会在 EOCD 里写多或者写少宁可报错也不要往下面传一个残缺的列表。另外文件名里可能带/甚至../在保存文件前必须单独处理后面避坑章节会专门讲。2.4 压缩方法只要认得 0 和 8 就能覆盖大多数包中央目录里的 method 字段表示压缩方法。0 表示不压缩原样存储8 表示 deflate这两个是绝对主流。Zlib 的inflate处理的就是 deflate 流所以 method 为 0 时直接拷贝 compressed_size 个字节就能得到原文件为 8 时才需要走 Zlib 解压。至于 12 的 bzip2、14 的 LZMA以及 Windows 下偶尔出现的 99 等最小实现一律返回「unsupported method」。不要尝试自己写算法zlib 不覆盖这些硬解只会浪费时间。3. 把 Inflate 接到解压链条一个最小可用的条目解压器3.1 先弄清楚 Zlib 的工作方式再去解数据Zlib 的inflate是一个流式状态机输入是压缩字节流输出是解压后的字节。所有状态都放在一个z_stream结构体里最核心的四个字段是next_in、avail_in、next_out、avail_out。调用一次inflate()会把avail_in里的数据尽量解到avail_out返回Z_OK表示还有输出或输入没处理完返回Z_STREAM_END表示这条 deflate 流已经完整结束。所以解一个条目的逻辑就是循环调用直到遇到Z_STREAM_END。这里有个关键选择inflateInit2的第二个参数传-15还是15。ZIP 存储的是裸的 deflate 流没有 zlib 头所以必须传-15如果传15Zlib 会期待一个 zlib 头解 ZIP 数据时必报错。这是我第一次做这个功能时翻车最狠的地方网上很多示例代码都用15 MAX_WBITS那是处理 zlib 流的不是处理 ZIP 的。3.2 代码用 InflateRaw 解出一个条目的全部数据下面的函数只负责把一段裸 deflate 流解成完整字节输入是压缩数据输出是vectoruint8_t。#include zlib.h #include vector #include stdexcept std::vectoruint8_t InflateRaw(const std::vectoruint8_t compressed, size_t expected_size) { z_stream strm{}; // -15 表示原始 deflate 流不含 zlib 头 if (inflateInit2(strm, -15) ! Z_OK) { throw std::runtime_error(inflateInit2 failed); } strm.next_in const_castBytef*(compressed.data()); strm.avail_in static_castuInt(compressed.size()); std::vectoruint8_t out; out.reserve(expected_size); uint8_t buffer[64 * 1024]; int ret; do { strm.next_out buffer; strm.avail_out sizeof(buffer); ret inflate(strm, Z_NO_FLUSH); if (ret Z_STREAM_ERROR) { inflateEnd(strm); throw std::runtime_error(stream error: input corrupt); } // 记录本次实际解出多少字节 size_t produced sizeof(buffer) - strm.avail_out; out.insert(out.end(), buffer, buffer produced); } while (ret Z_OK strm.avail_in 0); bool done (ret Z_STREAM_END); inflateEnd(strm); if (!done) { throw std::runtime_error(deflate stream incomplete); } return out; }这段代码里expected_size只是用来提前reserve内存避免频繁扩容导致的拷贝开销真正限制输出的是strm.avail_out。每一次inflate返回后都要算produced这个值等于缓冲区大小减去剩余的avail_out别用返回值去推断输出长度。如果 zip 的条目不完整或者 compressed_size 被外部数据弄错了循环会在输入耗尽但没有Z_STREAM_END时退出这时候抛异常就是正确行为。实际项目中我碰到过解压出来的数据比expected_size小的情况所以不要用expected_size去截断输出留给调用方做 CRC 校验。3.3 配合之前的中央目录解析完成单个条目解压有了 InflateRaw 之后解压一个 ZIP 条目的完整流程就通顺了先读 EOCD再读中央目录找到目标文件名对应的 Entry根据local_offset跳到本地文件头跳过文件名和 extra 字段读出压缩数据再根据 method 决定直接拷贝还是调 InflateRaw。下面的代码把「按名字解出一个条目」串了起来。std::vectoruint8_t ExtractEntry(const std::string zip_path, const Entry entry) { std::ifstream f(zip_path, std::ios::binary); f.seekg(entry.local_offset); // 本地文件头固定 30 字节签名 PK\x03\x04 uint8_t header[30]; f.read(reinterpret_castchar*(header), 30); if (!f || header[0] ! P || header[1] ! K || header[2] ! 0x03 || header[3] ! 0x04) { throw std::runtime_error(local header signature mismatch); } uint16_t name_len ReadU16(header 26); uint16_t extra_len ReadU16(header 28); // 跳过文件名和扩展字段到达压缩数据起点 f.seekg(entry.local_offset 30 name_len extra_len); std::vectoruint8_t compressed(entry.compressed_size); f.read(reinterpret_castchar*(compressed.data()), compressed.size()); if (!f) throw std::runtime_error(read compressed data failed); if (entry.method 0) { return compressed; // store 方法直接返回原样数据 } if (entry.method 8) { return InflateRaw(compressed, entry.uncompressed_size); } throw std::runtime_error(unsupported compression method); }这里有一点要注意中央目录里的 local_offset 指向的是本地文件头的起点但中央目录里的文件名长度、extra 长度和本地文件头里的可能不一致。严谨做法是从本地文件头的 30 字节里重新读name_len和extra_len而不是直接用 Central Directory 里的同名长度因为某些打包工具会在本地头额外塞一些私有字段。如果跳转数据起点后读不满compressed_size同样说明文件损坏或偏移计算有问题。4. 解压只是开始CRC32 校验、文件名编码与加密条目的识别4.1 CRC32 校验不是可选项是最后的防线ZIP 里每个条目都记录了原始数据的 CRC32解压完成后必须用 Zlib 自带的crc32()函数重新计算一次和中央目录里的值对比。这一步能拦截两类问题一类是压缩数据本身损坏另一类是读到的数据不是这个条目的比如偏移算错或者 store 方法下压缩大小字段被篡改。Zlib 的crc32()接口非常简单关键是边接收解压数据边算不要等整块都放进内存再算。#include zlib.h uint32_t ComputeCrc32(const uint8_t* data, size_t len) { uLong crc crc32(0L, Z_NULL, 0); crc crc32(crc, data, static_castuInt(len)); return static_castuint32_t(crc); }调用时直接与entry.crc比较不一致就抛异常。特别要提醒的是把crc32的第二个参数传reinterpret_castconst Bytef*(data)对uInt长度做一次转换因为 crc32 内部接受的uInt在 64 位平台上size_t可能比它宽单次超过 4GB 的数据最好分批算。对大文件解压场景一次把几 GB 全塞给crc32也不现实应该一边写入磁盘一边累计 CRC 值。4.2 文件名是 UTF-8 还是 GBK别猜看通用标志位中央目录的通用标志位 bit 11 明确表示文件名是否以 UTF-8 编码。置 1 就是 UTF-8直接当std::string用没问题置 0 时在简体中文环境里大概率是 GBK/ANSI 编码直接用 UTF-8 解析必然出现乱码。我的处理方式是先把 bit 11 存进 Entry保存文件前做判断。bool IsAscii(const std::string s) { for (unsigned char c : s) { if (c 0x80) return false; } return true; } std::string DecodeEntryName(const Entry e) { if (e.is_utf8 || IsAscii(e.name)) { return e.name; } // 非 UTF-8 且包含高位字节这里走 GBK 转 UTF-8 的逻辑 // 实际项目里我用 GPU/ICU 这类库做转换最小实现可以直接抛异常 return e.name; }如果你不想引入编码转换库一个折中做法是不改文件名直接保存但记录一份日志说明源编码非 UTF-8至少别在文件名里硬塞 GBK 字节去和 Linux 文件系统打交道那会造成文件系统层乱码。真正要彻底解决中文文件名必须在 Windows 上用 WideCharToMultiByte 或者跨平台的转换库。4.3 加密条目的处理原则不支持就直接拒绝遇到加密 ZIP最怕的事情是解出一堆乱码还当成正常结果。检测方式很简单通用标志位 bit 0 置 1 就是加密条目。Zlib 本身不提供解密能力传统 ZipCrypto 可以暴力破解但没必要在解压器里实现AES 加密的 ZIP 更是和 Zlib 没有关系。所以 ExtractEntry 开头就应该加一个判断。if (entry.encrypted) { throw std::runtime_error(encrypted entry not supported: entry.name); }这样做的价值是让上层逻辑拿到一个明确错误而不是继续给用户生成损坏文件。真实项目中我看到很多团队在「解压失败」和「解压后文件打不开」之间反复调试最后才发现是加密包被当成普通包处理了所以提前把这条拦截加上能省不少排查时间。5. 避坑解压结果和系统自带工具对不上的常见场景5.1 文件名带../或绝对路径把文件写到目标目录外面现象代码用root / entry.name直接拼接保存路径解压一个恶意构造的 zip 后文件出现在了/tmp/../../etc/下覆盖了系统文件。原因ZIP 条目里的文件名完全可控中央目录不会校验路径合法性。攻击者可以把名字写成../../tmp/evil.sh业务侧如果不做拦截就会中招。解决保存前用std::filesystem::path做规范化然后强制检查规范化后的路径仍然在目标根目录下。namespace fs std::filesystem; fs::path SafeJoin(const fs::path root, const std::string entry_name) { fs::path root_abs fs::absolute(root).lexically_normal(); // 统一用正斜杠拼接避免 Windows 分隔符混入 fs::path out root_abs / entry_name; out out.lexically_normal(); // 检查 out 是否仍在 root_abs 下 auto root_str root_abs.string(); auto out_str out.string(); if (out_str.compare(0, root_str.size(), root_str) ! 0) { throw std::runtime_error(entry path escapes target directory); } return out; }有一个细节字符串前缀比较时如果 root 是/tmp/out恶意路径是/tmp/outside会因为恰好共享前缀而漏判所以必须在比较后检查out_str[root_str.size()]是否为目录分隔符或者直接用fs::relative(out, root_abs)判断是否以..开头。跨平台场景下路径分隔符不一样先统一转换成/是最省事的办法。5.2 inflate 正常结束但 CRC 对不上数据描述符在捣乱现象解压出来的字节流完整大小也和 uncompressed_size 一致但 CRC32 校验失败。原因这类 ZIP 的本地文件头开启了 bit 3 标志意味着压缩数据后面紧跟一个数据描述符描述符里重新写了 CRC 和大小而中央目录里记录的 CRC 是本条目的真实值如果整个文件的 bytes 被某一步错误地截断或拼接CRC 自然对不上。解决严格用中央目录里的 CRC 作为最终校验本地头里的 CRC 字段可能为 0千万不要在数据描述符里找答案。另外在处理 flow 时宁可多读几个字节再截断也不要因为 local_header 后面的一段数据偏移不齐就把压缩流一起切坏。5.3 解压大文件时内存暴涨现象程序在某台机器上只解一个 3GB 的 zip结果内存直接吃到 4GB 以上接近被系统杀掉。原因我在第一版实现里用了out.reserve(expected_size)再加std::ifstream一次读整个压缩数据两条路径叠加导致内存里同时存在压缩块和解压块内存占用接近两倍文件大小。解决解压循环里用固定 64KB 缓冲区每解出一段就写入磁盘不保留整个解压结果。std::ifstream in(zip_path, std::ios::binary); std::ofstream out(target_path, std::ios::binary); uint8_t in_buf[64 * 1024]; uint8_t out_buf[64 * 1024]; // 边读边解边写压缩数据和输出数据只保留一个窗口这样峰值内存基本固定在几百 KB不会随文件大小线性上升。唯一的代价是代码结构更复杂要自己管理读入进度和 inflate 的输入输出窗口。5.4 有些 zip 打不开但系统自带工具能开现象一套自研解压器对市面上 90% 的 zip 都没问题遇到某些国产办公软件导出的包就报「central directory signature mismatch」。原因对方可能在中央目录或者本地文件头里写了非法的 extra 字段或者本地文件头长度和中央目录记录不一致。系统工具往往带容错比如扫描中央目录时遇到伪签名就跳过继续找而我们的严格实现一遇非法签名就抛异常。解决先在代码里把「签名不匹配」改为「跳过 4 字节继续找下一个 PK\x01\x02」只有当连续找不到真实条目时才报错。这个容忍策略能覆盖大多数不规范的打包工具生成物。另一个常见原因是 zip64 扩展文件或者某个条目超过 4GB 时 EOCD 里会出现 zip64 定位器一些老库没解析 zip64 的额外字段就会看到 total_entries 或者 cd_offset 异常这种不是玄学按 zip64 规范补解析即可。5.5 解压后目录层级对不上少了一层嵌套现象压缩包里文件名是dir1/file.txt用我们的代码解出来却只有file.txt或者保存在了错误目录。原因中央目录里每个条目都完整保留了相对路径实现时如果盲目用std::string::find_last_of(/)去截断目录就会把多层目录当一层处理。解决文件名里的/是路径分隔符保存时用path.parent_path()递归创建目录而不是只切一次。必须保证所有父目录都存在后再写文件否则std::ofstream会直接失败但不会自动建目录。6. 进阶不读整个包按条目跳读并流式写出既然解析中央目录后已经拿到每个条目的 local_offset那就不必把整个 zip 载入内存。做法是先读 EOCD 和中央目录然后直接 seek 到目标条目的 local header读完 30 字节头和 name/extra 段后从数据起点开始读 compressed_size 字节再循环 inflate 写到输出文件。这个模式适合大包中只取一个配置文件或制作热更新的场景典型的读入量只有中央目录加目标条目数据。void ExtractEntryToFile(const std::string zip_path, const Entry entry, const fs::path target) { std::ifstream in(zip_path, std::ios::binary); std::ofstream out(target, std::ios::binary); in.seekg(entry.local_offset); uint8_t header[30]; in.read(reinterpret_castchar*(header), 30); uint16_t name_len ReadU16(header 26); uint16_t extra_len ReadU16(header 28); in.seekg(entry.local_offset 30 name_len extra_len); uint8_t out_buf[64 * 1024]; if (entry.method 0) { std::vectoruint8_t raw(entry.compressed_size); in.read(reinterpret_castchar*(raw.data()), raw.size()); out.write(reinterpret_castchar*(raw.data()), raw.size()); return; } z_stream strm{}; if (inflateInit2(strm, -15) ! Z_OK) { throw std::runtime_error(inflateInit2 failed); } uint8_t in_buf[64 * 1024]; size_t remaining entry.compressed_size; uLong crc crc32(0L, Z_NULL, 0); while (remaining 0 || strm.avail_in 0) { if (strm.avail_in 0 remaining 0) { size_t to_read std::min(remaining, sizeof(in_buf)); in.read(reinterpret_castchar*(in_buf), to_read); strm.next_in in_buf; strm.avail_in static_castuInt(to_read); remaining - to_read; } strm.next_out out_buf; strm.avail_out sizeof(out_buf); int ret inflate(strm, Z_NO_FLUSH); size_t produced sizeof(out_buf) - strm.avail_out; if (produced 0) { out.write(reinterpret_castchar*(out_buf), produced); crc crc32(crc, out_buf, static_castuInt(produced)); } if (ret Z_STREAM_END) break; if (ret ! Z_OK) { inflateEnd(strm); throw std::runtime_error(inflate failed); } } inflateEnd(strm); if (crc ! entry.crc) { throw std::runtime_error(CRC mismatch for entry.name); } }这段实现里最值得注意的细节是remaining和strm.avail_in的配合。第一次调用inflate后输入缓冲区里可能还剩下一部分没消费这时不能急着读下一段而是要等strm.avail_in 0才继续读文件。很多人在这个点翻车每次都往next_in里塞新数据导致流中间被覆盖。流式写出的补偿是内存占用稳定但解压过程里 CRC 是边写边算的最后仍然要和中央目录比对比完整载入内存的方案更安全。这套按需跳读的写法也是我现在处理资源包的首选方案。某跨平台系统的内置资源包里有上千个文件直接用流式接口按需解压打包时也不需要把每个文件都拆出来。后来我陆续补上了 zip64 条的拒绝逻辑和路径穿越防护才敢真正放到线上跑。要用这个方案时先把 EOCD 和中央目录解析做好再逐步加上校验和流式输出每一步都可以独立写单元测试最好为每个步骤准备一个能触发异常的畸形 zip。做这个方向最值得投入的不是算法而是边界情况的处理希望这些实践能帮到你。本文还有配套的精品资源点击获取
简介面向需要在 Visual Studio 环境中基于 Zlib 实现 ZIP 解压功能的 C 开发者这份资源集中解决从第三方网站下载的 Zlib 原始代码在 Windows 平台编译失败、工程配置繁琐、依赖关系混乱等常见问题。作者逐项修正源文件错误后重新封装为 myZlib 库32 位 Debug 版库文件与 myZlib.h 头文件均放在 myZlib 文件夹头文件内附有详细调用方式和参数说明引入工程即可直接链接使用。压缩包共包含七百三十八个文件体积约三点五八兆字节类型以 h 头文件、cpp 与 c 源文件、vcxproj/vcproj 工程文件、makefile 构建脚本、txt 说明文档为主其中头文件约一百二十一个、C 源文件约五十八个、C 源文件约四十二个工程内还保留 Zlib 官方为多种平台准备的配置和补丁。整体目录既保留原始 zlib/minizip 组件又新增封装层便于对照学习跨平台移植与静态库封装方法也可以直接引入实际项目使用。目前已有七百五十八人学习下载适合有一定 C 基础、希望快速获得解压能力并保留自定义空间的开发者能明显缩短二次开发中的排错时间。1. 用 Zlib 在 C 里解 ZIP容器格式和压缩流是两码事很多人第一次用 Zlib 解 ZIP 时都踩过同一个坑直接把整个 zip 文件丢给inflate()结果得到一堆乱码。原因很简单ZIP 本身不是一条连续的压缩流而是把一个文件的目录结构、文件数据和压缩流封装在一起的容器格式。Zlib 只负责其中「压缩算法」那一段也就是对容器里的每个条目做 deflate/inflate 处理真正要花功夫的是把 ZIP 的二进制结构拆开、定位每条数据。C 实现 zip 文档解压如果选型正确项目里甚至可以完全不依赖第三方库之外的重量级组件只引入一个 zlib自己写解析逻辑就能在 Windows、Linux 甚至嵌入式环境里稳定读取常见 ZIP 包。这个方案适合需要减少外部依赖、要按需解压单个条目的场景但如果目标是完整支持加密、多卷、zip64那还是换现成库更省心。ZIP 的解压链路可以拆成三条明确的任务从文件尾部找到中央目录索引、靠中央目录拿到每个条目的偏移和大小、再去对应位置读取压缩数据并送给 Zlib 解压。听起来不复杂实际做下来才发现细节不少尤其是数据描述符、文件名编码、路径穿越这三类问题。这篇文章就按我自己实践过的路径从二进制结构讲到可运行的 C 实现。2. 从 EOCD 开始解析 ZIP中央目录结构与读取顺序2.1 ZIP 不是一节到底的数据流而是三段式布局一个正常的 ZIP 文件在磁盘上可以粗暴地分成三段前面是一个接一个的本地文件头每个本地文件头后紧跟该文件的压缩数据中间是整个包所有条目的索引也就是中央目录最后是一个 22 字节的结束记录专业叫 EOCD。ZIP 规定中央目录不需要放在文件末尾EOCD 才是真正的收尾标记所以解析顺序一定要从尾部到头部。EOCD 里存了中央目录的位置和条目总数拿到它才能跳过前面一堆本地段直接去看索引。有人会问为什么不直接从文件开头遍历本地文件头原因很实际本地文件头之间靠压缩数据隔开而压缩数据大小只能通过本地文件头里的字段读出来万一遇到 bit 3 标志开启的情况数据后面还会多出一个数据描述符按顺序硬推很不稳定。中央目录则集中记录了每个条目的文件名、CRC、压缩后大小、解压后大小和本地偏移一次就读完整包的结构是最可靠的入口。2.2 从文件尾部扫出 EOCD注意边界和签名偏移EOCD 的签名固定为PK\x05\x06也就是十六进制0x06054b50但它不一定正好挨着文件末尾因为 EOCD 最后还有一个最多 65535 字节的注释字段。所以安全做法是读取文件最后 2265535 字节在这个窗口里从后往前找签名命中后再按偏移解析各字段。下面的代码是一个把尾部读取和 EOCD 解析合在一起的写法。#include cstdint #include fstream #include vector #include stdexcept #include string #include algorithm struct Eocd { uint16_t disk_num; // 当前磁盘编号 uint16_t cd_start_disk; // 中央目录起始磁盘编号 uint16_t num_entries_disk; // 本磁盘上目录条目数 uint16_t total_entries; // 目录条目总数 uint32_t cd_size; // 中央目录总字节数 uint32_t cd_offset; // 中央目录相对文件头的偏移 uint16_t comment_len; // 注释长度 }; uint16_t ReadU16(const uint8_t* p) { return static_castuint16_t(p[0] | (p[1] 8)); } uint32_t ReadU32(const uint8_t* p) { return static_castuint32_t(p[0] | (p[1] 8) | (p[2] 16) | (p[3] 24)); } Eocd ReadEocd(const std::string path) { std::ifstream f(path, std::ios::binary); if (!f) throw std::runtime_error(cannot open file); f.seekg(0, std::ios::end); auto file_size f.tellg(); if (file_size 22) throw std::runtime_error(file too small to be zip); // EOCD 结构 22 字节注释最长 65535 字节 size_t tail_len std::minsize_t(static_castsize_t(file_size), 22u 65535u); std::vectoruint8_t tail(tail_len); f.seekg(file_size - tail_len); f.read(reinterpret_castchar*(tail.data()), tail_len); if (!f) throw std::runtime_error(read tail failed); // 从窗口末尾往前扫注释里也可能出现伪签名 for (int i static_castint(tail_len) - 22; i 0; --i) { if (tail[i] ! P) continue; if (tail[i 1] ! K) continue; if (tail[i 2] ! 0x05 || tail[i 3] ! 0x06) continue; Eocd e; e.disk_num ReadU16(tail[i 4]); e.cd_start_disk ReadU16(tail[i 6]); e.num_entries_disk ReadU16(tail[i 8]); e.total_entries ReadU16(tail[i 10]); e.cd_size ReadU32(tail[i 12]); e.cd_offset ReadU32(tail[i 16]); e.comment_len ReadU16(tail[i 20]); return e; } throw std::runtime_error(EOCD signature not found); }这段代码有两个容易翻车的地方。第一个是从后往前扫描时窗口起点不能从tail_len - 22往前随意扩因为注释字段可能包含伪造的PK\x05\x06字节扫到伪造签名会导致偏移错乱从最接近文件末尾的合法位置开始扫优先命中真正的 EOCD。第二个是如果解析出来的comment_len加上 22 不等于窗口里实际剩余偏移说明签名窗口位置有问题严谨的实现还应该校验这个一致性。读取完还要判断disk_num和cd_start_disk只要不是 0 就说明是多卷 zip当前这套最小实现直接抛异常就好。2.3 遍历中央目录条目每个文件的信息都在这张表里拿到 EOCD 之后就能定位中央目录的起始偏移和大小。中央目录是一条一条记录连续排列的每条固定的头是 46 字节签名是PK\x01\x02后面跟着文件名、扩展字段和注释。字段里有用的信息包括压缩方法、CRC32、压缩大小、解压大小、通用标志位和本地文件头偏移。下面这段代码用来把中央目录读出来并转成结构体数组。struct Entry { std::string name; // 文件名带路径分隔符 uint16_t method; // 0store 8deflate uint32_t crc; // 解压后数据的 CRC32 uint32_t compressed_size; // 压缩后字节数 uint32_t uncompressed_size; // 解压后字节数 uint32_t local_offset; // 本地文件头的文件偏移 bool is_utf8; // 通用标志位 bit 11 bool encrypted; // 通用标志位 bit 0 }; std::vectorEntry ReadCentralDirectory(const std::string path, const Eocd eocd) { std::ifstream f(path, std::ios::binary); f.seekg(eocd.cd_offset); std::vectoruint8_t buf(eocd.cd_size); f.read(reinterpret_castchar*(buf.data()), buf.size()); if (!f) throw std::runtime_error(read central directory failed); std::vectorEntry entries; size_t i 0; while (i 46 buf.size()) { if (buf[i] ! P || buf[i 1] ! K || buf[i 2] ! 0x01 || buf[i 3] ! 0x02) { throw std::runtime_error(central directory entry signature mismatch); } uint16_t flags ReadU16(buf[i 8]); uint16_t method ReadU16(buf[i 10]); uint32_t crc ReadU32(buf[i 16]); uint32_t comp_size ReadU32(buf[i 20]); uint32_t uncomp_size ReadU32(buf[i 24]); uint16_t name_len ReadU16(buf[i 28]); uint16_t extra_len ReadU16(buf[i 30]); uint16_t comment_len ReadU16(buf[i 32]); uint32_t local_offset ReadU32(buf[i 42]); Entry e; e.name.assign(reinterpret_castconst char*(buf[i 46]), name_len); e.method method; e.crc crc; e.compressed_size comp_size; e.uncompressed_size uncomp_size; e.local_offset local_offset; e.is_utf8 (flags (1u 11)) ! 0; e.encrypted (flags 1u) ! 0; entries.push_back(std::move(e)); // 跳过: 固定头46字节 文件名 扩展字段 注释 i 46 name_len extra_len comment_len; } if (entries.size() ! eocd.total_entries) { throw std::runtime_error(entry count mismatch); } return entries; }这里注意几个字段的读取位置偏移 42 是本地头部偏移这个字段在中央目录里是 4 字节但对 zip64 来说只剩 0xFFFFFFFF 这种哨兵值。我强烈建议解析完total_entries后和实际循环次数做一次校验因为有些第三方打出来的 zip 包会在 EOCD 里写多或者写少宁可报错也不要往下面传一个残缺的列表。另外文件名里可能带/甚至../在保存文件前必须单独处理后面避坑章节会专门讲。2.4 压缩方法只要认得 0 和 8 就能覆盖大多数包中央目录里的 method 字段表示压缩方法。0 表示不压缩原样存储8 表示 deflate这两个是绝对主流。Zlib 的inflate处理的就是 deflate 流所以 method 为 0 时直接拷贝 compressed_size 个字节就能得到原文件为 8 时才需要走 Zlib 解压。至于 12 的 bzip2、14 的 LZMA以及 Windows 下偶尔出现的 99 等最小实现一律返回「unsupported method」。不要尝试自己写算法zlib 不覆盖这些硬解只会浪费时间。3. 把 Inflate 接到解压链条一个最小可用的条目解压器3.1 先弄清楚 Zlib 的工作方式再去解数据Zlib 的inflate是一个流式状态机输入是压缩字节流输出是解压后的字节。所有状态都放在一个z_stream结构体里最核心的四个字段是next_in、avail_in、next_out、avail_out。调用一次inflate()会把avail_in里的数据尽量解到avail_out返回Z_OK表示还有输出或输入没处理完返回Z_STREAM_END表示这条 deflate 流已经完整结束。所以解一个条目的逻辑就是循环调用直到遇到Z_STREAM_END。这里有个关键选择inflateInit2的第二个参数传-15还是15。ZIP 存储的是裸的 deflate 流没有 zlib 头所以必须传-15如果传15Zlib 会期待一个 zlib 头解 ZIP 数据时必报错。这是我第一次做这个功能时翻车最狠的地方网上很多示例代码都用15 MAX_WBITS那是处理 zlib 流的不是处理 ZIP 的。3.2 代码用 InflateRaw 解出一个条目的全部数据下面的函数只负责把一段裸 deflate 流解成完整字节输入是压缩数据输出是vectoruint8_t。#include zlib.h #include vector #include stdexcept std::vectoruint8_t InflateRaw(const std::vectoruint8_t compressed, size_t expected_size) { z_stream strm{}; // -15 表示原始 deflate 流不含 zlib 头 if (inflateInit2(strm, -15) ! Z_OK) { throw std::runtime_error(inflateInit2 failed); } strm.next_in const_castBytef*(compressed.data()); strm.avail_in static_castuInt(compressed.size()); std::vectoruint8_t out; out.reserve(expected_size); uint8_t buffer[64 * 1024]; int ret; do { strm.next_out buffer; strm.avail_out sizeof(buffer); ret inflate(strm, Z_NO_FLUSH); if (ret Z_STREAM_ERROR) { inflateEnd(strm); throw std::runtime_error(stream error: input corrupt); } // 记录本次实际解出多少字节 size_t produced sizeof(buffer) - strm.avail_out; out.insert(out.end(), buffer, buffer produced); } while (ret Z_OK strm.avail_in 0); bool done (ret Z_STREAM_END); inflateEnd(strm); if (!done) { throw std::runtime_error(deflate stream incomplete); } return out; }这段代码里expected_size只是用来提前reserve内存避免频繁扩容导致的拷贝开销真正限制输出的是strm.avail_out。每一次inflate返回后都要算produced这个值等于缓冲区大小减去剩余的avail_out别用返回值去推断输出长度。如果 zip 的条目不完整或者 compressed_size 被外部数据弄错了循环会在输入耗尽但没有Z_STREAM_END时退出这时候抛异常就是正确行为。实际项目中我碰到过解压出来的数据比expected_size小的情况所以不要用expected_size去截断输出留给调用方做 CRC 校验。3.3 配合之前的中央目录解析完成单个条目解压有了 InflateRaw 之后解压一个 ZIP 条目的完整流程就通顺了先读 EOCD再读中央目录找到目标文件名对应的 Entry根据local_offset跳到本地文件头跳过文件名和 extra 字段读出压缩数据再根据 method 决定直接拷贝还是调 InflateRaw。下面的代码把「按名字解出一个条目」串了起来。std::vectoruint8_t ExtractEntry(const std::string zip_path, const Entry entry) { std::ifstream f(zip_path, std::ios::binary); f.seekg(entry.local_offset); // 本地文件头固定 30 字节签名 PK\x03\x04 uint8_t header[30]; f.read(reinterpret_castchar*(header), 30); if (!f || header[0] ! P || header[1] ! K || header[2] ! 0x03 || header[3] ! 0x04) { throw std::runtime_error(local header signature mismatch); } uint16_t name_len ReadU16(header 26); uint16_t extra_len ReadU16(header 28); // 跳过文件名和扩展字段到达压缩数据起点 f.seekg(entry.local_offset 30 name_len extra_len); std::vectoruint8_t compressed(entry.compressed_size); f.read(reinterpret_castchar*(compressed.data()), compressed.size()); if (!f) throw std::runtime_error(read compressed data failed); if (entry.method 0) { return compressed; // store 方法直接返回原样数据 } if (entry.method 8) { return InflateRaw(compressed, entry.uncompressed_size); } throw std::runtime_error(unsupported compression method); }这里有一点要注意中央目录里的 local_offset 指向的是本地文件头的起点但中央目录里的文件名长度、extra 长度和本地文件头里的可能不一致。严谨做法是从本地文件头的 30 字节里重新读name_len和extra_len而不是直接用 Central Directory 里的同名长度因为某些打包工具会在本地头额外塞一些私有字段。如果跳转数据起点后读不满compressed_size同样说明文件损坏或偏移计算有问题。4. 解压只是开始CRC32 校验、文件名编码与加密条目的识别4.1 CRC32 校验不是可选项是最后的防线ZIP 里每个条目都记录了原始数据的 CRC32解压完成后必须用 Zlib 自带的crc32()函数重新计算一次和中央目录里的值对比。这一步能拦截两类问题一类是压缩数据本身损坏另一类是读到的数据不是这个条目的比如偏移算错或者 store 方法下压缩大小字段被篡改。Zlib 的crc32()接口非常简单关键是边接收解压数据边算不要等整块都放进内存再算。#include zlib.h uint32_t ComputeCrc32(const uint8_t* data, size_t len) { uLong crc crc32(0L, Z_NULL, 0); crc crc32(crc, data, static_castuInt(len)); return static_castuint32_t(crc); }调用时直接与entry.crc比较不一致就抛异常。特别要提醒的是把crc32的第二个参数传reinterpret_castconst Bytef*(data)对uInt长度做一次转换因为 crc32 内部接受的uInt在 64 位平台上size_t可能比它宽单次超过 4GB 的数据最好分批算。对大文件解压场景一次把几 GB 全塞给crc32也不现实应该一边写入磁盘一边累计 CRC 值。4.2 文件名是 UTF-8 还是 GBK别猜看通用标志位中央目录的通用标志位 bit 11 明确表示文件名是否以 UTF-8 编码。置 1 就是 UTF-8直接当std::string用没问题置 0 时在简体中文环境里大概率是 GBK/ANSI 编码直接用 UTF-8 解析必然出现乱码。我的处理方式是先把 bit 11 存进 Entry保存文件前做判断。bool IsAscii(const std::string s) { for (unsigned char c : s) { if (c 0x80) return false; } return true; } std::string DecodeEntryName(const Entry e) { if (e.is_utf8 || IsAscii(e.name)) { return e.name; } // 非 UTF-8 且包含高位字节这里走 GBK 转 UTF-8 的逻辑 // 实际项目里我用 GPU/ICU 这类库做转换最小实现可以直接抛异常 return e.name; }如果你不想引入编码转换库一个折中做法是不改文件名直接保存但记录一份日志说明源编码非 UTF-8至少别在文件名里硬塞 GBK 字节去和 Linux 文件系统打交道那会造成文件系统层乱码。真正要彻底解决中文文件名必须在 Windows 上用 WideCharToMultiByte 或者跨平台的转换库。4.3 加密条目的处理原则不支持就直接拒绝遇到加密 ZIP最怕的事情是解出一堆乱码还当成正常结果。检测方式很简单通用标志位 bit 0 置 1 就是加密条目。Zlib 本身不提供解密能力传统 ZipCrypto 可以暴力破解但没必要在解压器里实现AES 加密的 ZIP 更是和 Zlib 没有关系。所以 ExtractEntry 开头就应该加一个判断。if (entry.encrypted) { throw std::runtime_error(encrypted entry not supported: entry.name); }这样做的价值是让上层逻辑拿到一个明确错误而不是继续给用户生成损坏文件。真实项目中我看到很多团队在「解压失败」和「解压后文件打不开」之间反复调试最后才发现是加密包被当成普通包处理了所以提前把这条拦截加上能省不少排查时间。5. 避坑解压结果和系统自带工具对不上的常见场景5.1 文件名带../或绝对路径把文件写到目标目录外面现象代码用root / entry.name直接拼接保存路径解压一个恶意构造的 zip 后文件出现在了/tmp/../../etc/下覆盖了系统文件。原因ZIP 条目里的文件名完全可控中央目录不会校验路径合法性。攻击者可以把名字写成../../tmp/evil.sh业务侧如果不做拦截就会中招。解决保存前用std::filesystem::path做规范化然后强制检查规范化后的路径仍然在目标根目录下。namespace fs std::filesystem; fs::path SafeJoin(const fs::path root, const std::string entry_name) { fs::path root_abs fs::absolute(root).lexically_normal(); // 统一用正斜杠拼接避免 Windows 分隔符混入 fs::path out root_abs / entry_name; out out.lexically_normal(); // 检查 out 是否仍在 root_abs 下 auto root_str root_abs.string(); auto out_str out.string(); if (out_str.compare(0, root_str.size(), root_str) ! 0) { throw std::runtime_error(entry path escapes target directory); } return out; }有一个细节字符串前缀比较时如果 root 是/tmp/out恶意路径是/tmp/outside会因为恰好共享前缀而漏判所以必须在比较后检查out_str[root_str.size()]是否为目录分隔符或者直接用fs::relative(out, root_abs)判断是否以..开头。跨平台场景下路径分隔符不一样先统一转换成/是最省事的办法。5.2 inflate 正常结束但 CRC 对不上数据描述符在捣乱现象解压出来的字节流完整大小也和 uncompressed_size 一致但 CRC32 校验失败。原因这类 ZIP 的本地文件头开启了 bit 3 标志意味着压缩数据后面紧跟一个数据描述符描述符里重新写了 CRC 和大小而中央目录里记录的 CRC 是本条目的真实值如果整个文件的 bytes 被某一步错误地截断或拼接CRC 自然对不上。解决严格用中央目录里的 CRC 作为最终校验本地头里的 CRC 字段可能为 0千万不要在数据描述符里找答案。另外在处理 flow 时宁可多读几个字节再截断也不要因为 local_header 后面的一段数据偏移不齐就把压缩流一起切坏。5.3 解压大文件时内存暴涨现象程序在某台机器上只解一个 3GB 的 zip结果内存直接吃到 4GB 以上接近被系统杀掉。原因我在第一版实现里用了out.reserve(expected_size)再加std::ifstream一次读整个压缩数据两条路径叠加导致内存里同时存在压缩块和解压块内存占用接近两倍文件大小。解决解压循环里用固定 64KB 缓冲区每解出一段就写入磁盘不保留整个解压结果。std::ifstream in(zip_path, std::ios::binary); std::ofstream out(target_path, std::ios::binary); uint8_t in_buf[64 * 1024]; uint8_t out_buf[64 * 1024]; // 边读边解边写压缩数据和输出数据只保留一个窗口这样峰值内存基本固定在几百 KB不会随文件大小线性上升。唯一的代价是代码结构更复杂要自己管理读入进度和 inflate 的输入输出窗口。5.4 有些 zip 打不开但系统自带工具能开现象一套自研解压器对市面上 90% 的 zip 都没问题遇到某些国产办公软件导出的包就报「central directory signature mismatch」。原因对方可能在中央目录或者本地文件头里写了非法的 extra 字段或者本地文件头长度和中央目录记录不一致。系统工具往往带容错比如扫描中央目录时遇到伪签名就跳过继续找而我们的严格实现一遇非法签名就抛异常。解决先在代码里把「签名不匹配」改为「跳过 4 字节继续找下一个 PK\x01\x02」只有当连续找不到真实条目时才报错。这个容忍策略能覆盖大多数不规范的打包工具生成物。另一个常见原因是 zip64 扩展文件或者某个条目超过 4GB 时 EOCD 里会出现 zip64 定位器一些老库没解析 zip64 的额外字段就会看到 total_entries 或者 cd_offset 异常这种不是玄学按 zip64 规范补解析即可。5.5 解压后目录层级对不上少了一层嵌套现象压缩包里文件名是dir1/file.txt用我们的代码解出来却只有file.txt或者保存在了错误目录。原因中央目录里每个条目都完整保留了相对路径实现时如果盲目用std::string::find_last_of(/)去截断目录就会把多层目录当一层处理。解决文件名里的/是路径分隔符保存时用path.parent_path()递归创建目录而不是只切一次。必须保证所有父目录都存在后再写文件否则std::ofstream会直接失败但不会自动建目录。6. 进阶不读整个包按条目跳读并流式写出既然解析中央目录后已经拿到每个条目的 local_offset那就不必把整个 zip 载入内存。做法是先读 EOCD 和中央目录然后直接 seek 到目标条目的 local header读完 30 字节头和 name/extra 段后从数据起点开始读 compressed_size 字节再循环 inflate 写到输出文件。这个模式适合大包中只取一个配置文件或制作热更新的场景典型的读入量只有中央目录加目标条目数据。void ExtractEntryToFile(const std::string zip_path, const Entry entry, const fs::path target) { std::ifstream in(zip_path, std::ios::binary); std::ofstream out(target, std::ios::binary); in.seekg(entry.local_offset); uint8_t header[30]; in.read(reinterpret_castchar*(header), 30); uint16_t name_len ReadU16(header 26); uint16_t extra_len ReadU16(header 28); in.seekg(entry.local_offset 30 name_len extra_len); uint8_t out_buf[64 * 1024]; if (entry.method 0) { std::vectoruint8_t raw(entry.compressed_size); in.read(reinterpret_castchar*(raw.data()), raw.size()); out.write(reinterpret_castchar*(raw.data()), raw.size()); return; } z_stream strm{}; if (inflateInit2(strm, -15) ! Z_OK) { throw std::runtime_error(inflateInit2 failed); } uint8_t in_buf[64 * 1024]; size_t remaining entry.compressed_size; uLong crc crc32(0L, Z_NULL, 0); while (remaining 0 || strm.avail_in 0) { if (strm.avail_in 0 remaining 0) { size_t to_read std::min(remaining, sizeof(in_buf)); in.read(reinterpret_castchar*(in_buf), to_read); strm.next_in in_buf; strm.avail_in static_castuInt(to_read); remaining - to_read; } strm.next_out out_buf; strm.avail_out sizeof(out_buf); int ret inflate(strm, Z_NO_FLUSH); size_t produced sizeof(out_buf) - strm.avail_out; if (produced 0) { out.write(reinterpret_castchar*(out_buf), produced); crc crc32(crc, out_buf, static_castuInt(produced)); } if (ret Z_STREAM_END) break; if (ret ! Z_OK) { inflateEnd(strm); throw std::runtime_error(inflate failed); } } inflateEnd(strm); if (crc ! entry.crc) { throw std::runtime_error(CRC mismatch for entry.name); } }这段实现里最值得注意的细节是remaining和strm.avail_in的配合。第一次调用inflate后输入缓冲区里可能还剩下一部分没消费这时不能急着读下一段而是要等strm.avail_in 0才继续读文件。很多人在这个点翻车每次都往next_in里塞新数据导致流中间被覆盖。流式写出的补偿是内存占用稳定但解压过程里 CRC 是边写边算的最后仍然要和中央目录比对比完整载入内存的方案更安全。这套按需跳读的写法也是我现在处理资源包的首选方案。某跨平台系统的内置资源包里有上千个文件直接用流式接口按需解压打包时也不需要把每个文件都拆出来。后来我陆续补上了 zip64 条的拒绝逻辑和路径穿越防护才敢真正放到线上跑。要用这个方案时先把 EOCD 和中央目录解析做好再逐步加上校验和流式输出每一步都可以独立写单元测试最好为每个步骤准备一个能触发异常的畸形 zip。做这个方向最值得投入的不是算法而是边界情况的处理希望这些实践能帮到你。本文还有配套的精品资源点击获取
区别)
