簡介這套C壓縮文件處理類源碼面向Windows平臺開發(fā)者解決zip壓縮包創(chuàng)建、解壓以及文件/文件夾打包等常見需求。資源共87個文件以頭文件和cpp實現(xiàn)為主29個h、23個cpp另含項目工程、界面圖標等配置資源壓縮包僅862KB結(jié)構(gòu)清晰便于直接復用。作者封裝了初始化、添加文件、添加文件夾、重新打開、解壓、關(guān)閉六大接口并配套測試類覆蓋全功能驗證核心模塊還包含路徑、時間、日志等工具封裝方便實際項目集成。源碼可由VS2020一鍵編譯通過并貼心附上舊版StdAfx.h預(yù)編譯頭遷移到pch.h的詳細方案兼容老工程。目前已有1429人學習適合需要快速集成zip處理能力的C初中級開發(fā)者參考。 在C里處理Zip壓縮文件一直是個“標準庫缺席、第三方庫遍地”的狀態(tài)。很多項目做到一半需求方就會扔過來一句話“你寫個壓縮類吧能解壓ZIP能打包ZIP?！币婚_始我也覺得這不就是封裝一下庫的事可真去寫的時候才發(fā)現(xiàn)選型、接口設(shè)計、跨平臺、中文編碼、異常兼容、安全過濾每一環(huán)都有不少文章可做。這篇就拿我實際落地的一個ZipArchive類當例子聊聊這類“壓縮文件處理類源碼”到底該怎么設(shè)計、怎么實現(xiàn)、怎么避開我踩過的坑。如果你現(xiàn)在正要在C項目里集成ZIP解壓/壓縮能力或者你準備自己寫一個輕量封裝類而不是直接灌一整個重量級框架這篇應(yīng)該能給你省下不少時間。1. 選型之前先搞清C做Zip處理的四種姿勢1.1 為什么C標準庫一直不提供Zip支持很多人問過我一個挺尷尬的問題C標準庫連網(wǎng)絡(luò)、文件系統(tǒng)都有基礎(chǔ)支持了為什么沒有ZIP其實不是標準委員會懶而是ZIP格式是一個“有損有密、有流式處理需求”的復雜容器格式不像std::fstream那樣只是一個字節(jié)流。它要處理壓縮算法DEFLATE、流式讀寫、校驗CRC-32、文件屬性、編碼表、ZIP64擴展甚至跨平臺路徑轉(zhuǎn)換。把這些全塞進標準庫里會嚴重拖累標準的演進速度。所以現(xiàn)實就是C里做ZIP處理第三方庫是繞不開的。但這不代表我們需要把整個庫的API都暴露給業(yè)務(wù)層。好的做法是自己維護一個ZipArchive類把底層庫封裝起來業(yè)務(wù)代碼只跟這個類打交道。這樣即使底層庫從minizip換成libzip甚至以后手寫實現(xiàn)調(diào)用方代碼都不需要動。1.2 zlib、minizip、libzip、quazip的定位差異選型之前先把常用庫的定位搞清楚。zlib是最底層的壓縮庫它只負責DEFLATE數(shù)據(jù)流的壓縮和解壓不關(guān)心ZIP容器格式。minizip是在zlib之上封裝的ZIP容器讀寫庫很多人以為它是官方庫其實它是zlib貢獻者提供的輔助函數(shù)集合開源項目里非常常見。libzip是一個更現(xiàn)代、更完整的獨立庫API設(shè)計更友好支持ZIP64、加密甚至支持文件注釋和更細粒度的錯誤碼。quazip是Qt生態(tài)的封裝庫如果你已經(jīng)用了Qt用quazip會很順手但它強依賴Qt的QIODevice不適合非Qt項目。我自己的選擇思路是這樣的需求推薦庫理由只需解壓/壓縮單文件或純內(nèi)存流zlib輕量直接管DEFLATE不引入容器解析需要完整ZIP文件操作跨平臺minizip與zlib同源集成成本最低源碼透明需要加密、ZIP64、復雜錯誤處理libzipAPI更現(xiàn)代功能覆蓋更全項目中已使用Qtquazip與Qt的IO模型無縫銜接1.3 什么時候該自己寫一個輕量封裝類很多開發(fā)者習慣直接用minizip的unzOpen、unzLocateFile、unzReadCurrentFile函數(shù)代碼寫到一半就發(fā)現(xiàn)大量重復的開關(guān)文件、內(nèi)存管理、錯誤判斷邏輯。所以我建議不管項目大小都要有一個ZipArchive類把這堆C風格API包起來。這個類不需要做得很重只要做到三件事RAII管理資源、業(yè)務(wù)友好的返回值、統(tǒng)一處理編碼和路徑安全。這正是標題里“處理類源碼”這個定位的核心價值。2. 一個能落地的ZipArchive類的接口設(shè)計2.1 從使用場景反推方法列表接口設(shè)計不要憑空想先看業(yè)務(wù)到底要什么。我整理過項目里的真實調(diào)用場景大約就這幾種解壓整個Zip到指定目錄、解壓其中某一個文件、向Zip里添加一個磁盤文件、向Zip里添加一段內(nèi)存緩沖區(qū)、列出包內(nèi)所有文件名。那么ZipArchive至少要有這幾個方法class ZipArchive { public: explicit ZipArchive(const std::string zipPath, bool create false); ~ZipArchive(); bool Open(); void Close(); bool ExtractAll(const std::string destDir); bool ExtractToBuffer(const std::string entryName, std::vectorchar outData); bool AddFile(const std::string diskFilePath, const std::string archiveName); bool AddBuffer(const std::string archiveName, const void* data, size_t size); std::vectorstd::string ListEntries() const; bool Contains(const std::string entryName) const; };2.2 RAII與open/close分離的取舍有人覺得構(gòu)造函數(shù)里直接打開文件析構(gòu)函數(shù)里自動釋放這就是RAII。但ZIP對象的打開操作可能失敗文件不存在、不是合法Zip、權(quán)限不夠構(gòu)造函數(shù)里拋異常又容易造成部分構(gòu)造的對象無法正常析構(gòu)。所以我的做法是構(gòu)造函數(shù)只保存路徑真正的句柄通過Open()方法獲取Close()負責釋放析構(gòu)函數(shù)里做一次兜底Close()。ZipArchive::~ZipArchive() { Close(); } bool ZipArchive::Open() { if (isOpen_) return true; zipHandle_ unzOpen(path_.c_str()); if (!zipHandle_) return false; isOpen_ true; return true; } void ZipArchive::Close() { if (zipHandle_) { unzClose(zipHandle_); zipHandle_ nullptr; } isOpen_ false; }這樣設(shè)計的額外好處是如果調(diào)用方需要批量處理多個Zip文件可以復用同一個ZipArchive對象反復Close再Open避免頻繁構(gòu)造析構(gòu)帶來的開銷。2.3 錯誤處理別讓調(diào)用方去猜返回值我見過很多封裝類把minizip的返回值直接拋給業(yè)務(wù)層比如UNZ_BADZIPFILE、UNZ_ERRNO調(diào)用方一臉懵。我的建議是封裝類一律返回bool或者自定義一個小的枚舉把底層錯誤信息記錄在內(nèi)部字段里。bool ZipArchive::ExtractAll(const std::string destDir) { if (!Open()) { lastError_ Failed to open zip file: path_; return false; } // ... }同時提供一個LastError()方法方便業(yè)務(wù)層打日志。對外接口越簡單越好內(nèi)部細節(jié)自己消化。3. 核心實現(xiàn)拆解解壓、壓縮與中文文件名的坑3.1 基于minizip的解壓主流程解壓的核心是遍歷Zip包內(nèi)的所有條目逐條取出數(shù)據(jù)寫入目標文件。這里最容易被忽略的是“目錄項”。ZIP格式里目錄通常是一個以/結(jié)尾的條目minizip在遍歷時也會返回這些項但它們的文件大小是0也不存在數(shù)據(jù)流。很多新手在這里直接調(diào)用unzOpenCurrentFile去讀然后發(fā)現(xiàn)返回錯誤以為文件損壞。正確流程是先unzGoToFirstFile循環(huán)里判斷當前項是否是目錄是就創(chuàng)建目錄并繼續(xù)否則創(chuàng)建父目錄再unzOpenCurrentFile讀取數(shù)據(jù)塊寫入文件。核心代碼如下bool ZipArchive::ExtractAll(const std::string destDir) { if (!Open()) return false; char name[512] {0}; unz_file_info fileInfo; int result unzGoToFirstFile2( zipHandle_, fileInfo, name, sizeof(name), nullptr, 0, nullptr, 0); while (result UNZ_OK) { std::string entryName name; std::string outputPath SafeJoin(destDir, entryName); bool isDir (entryName.back() / || entryName.back() \\); if (isDir) { CreateDirectories(outputPath); } else { CreateDirectories(PathOf(outputPath)); if (!ExtractCurrentToFile(outputPath)) { return false; } } result unzGoToNextFile(zipHandle_); } return result UNZ_END_OF_LIST_OF_FILE; }這里要特別注意safe path join后面第4.2節(jié)會專門講路徑穿越問題。3.2 流式寫入與壓縮級別控制ZIP壓縮功能最核心的步驟是“把要壓縮的數(shù)據(jù)傳給minizip”。對于大文件絕不能一次性讀入內(nèi)存而是要分塊讀寫。minizip的zipWriteInFileInZip只接受緩沖區(qū)所以我們的AddFile就應(yīng)該用文件流循環(huán)讀塊bool ZipArchive::AddFile(const std::string diskFilePath, const std::string archiveName) { if (!Open()) return false; std::ifstream input(diskFilePath, std::ios::binary); if (!input.is_open()) return false; zip_fileinfo zipInfo {0}; // 設(shè)置修改時間從磁盤文件獲取此處略去時間轉(zhuǎn)換trick if (zipOpenNewFileInZip(zipHandle_, archiveName.c_str(), zipInfo, nullptr, 0, nullptr, 0, nullptr, Z_DEFLATED, Z_DEFAULT_COMPRESSION) ! ZIP_OK) { return false; } char buffer[64 * 1024]; while (input.good()) { input.read(buffer, sizeof(buffer)); std::streamsize bytes input.gcount(); if (bytes 0 zipWriteInFileInZip(zipHandle_, buffer, bytes) ! ZIP_OK) { zipCloseFileInZip(zipHandle_); return false; } } return zipCloseFileInZip(zipHandle_) ZIP_OK; }關(guān)于壓縮級別minizip里常用的有三種Z_NO_COMPRESSION只打包不壓縮適合已經(jīng)壓縮過的文件、Z_BEST_SPEED快但體積大、Z_BEST_COMPRESSION慢但體積小。我一般默認用Z_DEFAULT_COMPRESSION它給zlib靈活調(diào)整的空間。判斷壓縮到底該用哪一檔要看文件類型不要無腦追求最壓縮不然視頻、圖片類文件壓縮半天體積也沒變小。3.3 GBK/UTF-8文件名轉(zhuǎn)換的必要性這是中文Windows環(huán)境下最容易出問題的地方。ZIP標準中的文件名字段歷史上普遍使用cp437編碼但國內(nèi)很多壓縮工具尤其老版本W(wǎng)inRAR、Windows自帶壓縮寫的是GBK。minizip默認不做編碼轉(zhuǎn)換直接把字節(jié)當UTF-8處理于是解壓出來的文件名經(jīng)常是亂碼或者直接報錯。我的做法是在ExtractAll里對每個entryName做一次判斷如果字節(jié)流不是合法的UTF-8就嘗試把GBK轉(zhuǎn)換成UTF-8再使用。判斷和轉(zhuǎn)換可以用iconv、std::wstring_convert也可以直接掛一個簡易的GBK轉(zhuǎn)UTF-8表。std::string ToUtf8(const std::string src) { // 省略具體轉(zhuǎn)換實現(xiàn)通義上就是先識別編碼再用編碼表映射 // 或者直接調(diào)用系統(tǒng)API MultiByteToWideChar / WideCharToMultiByte }這個坑相當隱蔽業(yè)務(wù)測試時文件名叫report_2024.zip看不出問題一到線上發(fā)來一個中文文件名的包直接就炸了。所以封裝類一定要把編碼統(tǒng)一收口到UTF-8再往外輸出。4. 我在實際項目中踩過的四個坑4.1 “Could not find EOCD”損壞Zip和拼接文件的識別第一次看到invalid zip archive: could not find EOCD的時候我第一反應(yīng)是對方發(fā)來的文件根本就不是ZIP。后來檢查尺寸發(fā)現(xiàn)文件末尾多了幾百字節(jié)。ZIP格式要求文件尾部有一個End of Central DirectoryEOCD記錄且記錄了Central Directory的偏移很多安卓ROM、嵌入式固件會把ZIP和其他二進制段拼在一起比如某些刷機包。對純ZIP工具來說這確實是“損壞”但在嵌入式、ROM場景里這種“前段ZIP后段尾數(shù)據(jù)”或者“前段頭ZIP尾”的拼接包是常態(tài)。解決思路不是一股腦報錯而是主動去尋找最后一個EOCD簽名0x06054b50。如果能在文件尾部1KB內(nèi)找到EOCD就先假定這是拼接包然后用EOCD里的Central Directory偏移去定位真正的目錄區(qū)。minizip的部分版本在新接口里不幫你做這種容錯所以我的封裝類里加了一個“掃描EOCD”的預(yù)處理邏輯可以顯著提高對這類怪包的兼容度。這個處理算是基于常見實踐的補充不是官方API的標準行為。4.2 路徑穿越攻擊../文件的過濾解壓ZIP時如果碰到一個條目名是../../etc/cron.d/evil而我們不加處理直接把它join到目標目錄就會把文件寫到目標目錄外面去。這就是經(jīng)典的Zip Slip漏洞C項目里同樣會中招。我在代碼里對每個entryName都做了兩級過濾先統(tǒng)一把\替換為/再逐段檢查是否包含..段。std::string ZipArchive::SafeJoin(const std::string base, const std::string entry) { std::string normalized entry; for (auto ch : normalized) { if (ch \\) ch /; } // 此處省略逐段校驗邏輯核心是拒絕任何帶有 .. 的相對路徑 if (ContainsParentSegment(normalized)) { return ; } // 再拼接到base下 return base / normalized; }別以為只有黑客才會這么干很多粗糙的內(nèi)部工具生成ZIP時也會因為拼接可執(zhí)行路徑產(chǎn)生臨時目錄導致某些條目名包含..。如果封裝類直接把空字符串返回后面文件創(chuàng)建必然失敗所以還要有一個明確的錯誤日志。4.3 大文件內(nèi)存暴漲不要用整塊buffer我第一次封裝解壓時圖省事調(diào)用unzGetCurrentFileSize拿到大小然后一次性分配一塊足量內(nèi)存去讀整個文件。小文件沒問題但一旦某個包里有幾個GB的文件程序直接吃滿內(nèi)存然后被操作系統(tǒng)殺掉。后來改成了分塊讀取每次固定讀取64KB或256KB直接寫入目標文件流如果需要解壓到內(nèi)存則在接口上限制單文件不超過指定閾值超過就拒絕解到內(nèi)存壓縮時同樣分塊讀文件保證峰值內(nèi)存不隨文件大小增長。流式處理這個原則做C的應(yīng)該早就知道但在ZIP封裝里特別容易被忽略因為底層庫的API看起來像是“一次打開一整個文件”的樣子。4.4 多線程下的ZIP庫初始化zlib線程安全邊界熱搜詞里也有“c多線程”這個坑確實常見。zlib本身的DEFLATE算法只要每個流使用獨立的z_stream就可以多線程并行處理。問題出在minizip這一層尤其是在舊版本里全局錯誤狀態(tài)和ZIP句柄的分配并不是完全線程安全的。我在寫并發(fā)壓縮任務(wù)時一開始直接讓多個線程分別創(chuàng)建各自的ZipArchive對象結(jié)果發(fā)現(xiàn)偶爾會觸發(fā)同一個內(nèi)部狀態(tài)被刷新。排查下來主要是minizip某些版本的zipOpen/unzOpen內(nèi)部用了非線程安全的緩存。我的解決辦法是要么用libzip這類官方明確支持多線程的庫要么在上層加一個全局互斥鎖限制同一時間只能有一個線程打開或創(chuàng)建ZIP文件。等到句柄創(chuàng)建完成后讀寫階段可以并行因為每個句柄都有獨立的內(nèi)部緩沖。這個結(jié)論并不復雜但能省掉一大輪深夜調(diào)試。5. 源碼之外測試、度量和擴展思路5.1 造一批好用的測試Zip樣本寫完了ZipArchive類第一件事不要直接上業(yè)務(wù)而是造一批能覆蓋各類邊角的樣本。我自己的測試清單大概是這樣的標準空ZIP文件只有EOCD沒有文件條目純文件夾結(jié)構(gòu)的ZIP包包含中文文件名、英文文件名混合的ZIP包用Windows快捷方式創(chuàng)建的“發(fā)送到壓縮文件夾”生成的ZIP用Pythonzipfile、Linuxzip、7-Zip分別生成的ZIP包人為截斷尾部數(shù)據(jù)的損壞ZIP包文件名包含../的惡意ZIP包每個樣本對應(yīng)一個單元測試跑完一遍之后類是否能上線基本心里有底。我見過太多項目只拿兩個正常包測一下就交付線上被中文文件名擊穿這是完全可以提前避免的。5.2 性能對比層級接口 vs 直接調(diào)用底層API有時候封裝層會成為性能瓶頸但一般不是解壓/壓縮本身而是處處都拷貝字符串、頻繁開閉文件句柄。我自己對比過在ExtractAll里如果每寫一次小文件就ofstream開一次文件速度慢得離譜改成用std::ofstream復用同一個句柄、只在遇到不同目錄時才切換解壓速度能提升一倍以上。另外ListEntries()如果被多次調(diào)用最好在第一次遍歷時緩存結(jié)果別每次都去unzGoToFirstFile重新掃。ZIP文件如果很大這種重復掃描時間是非常可觀的開銷。5.3 后續(xù)方向ZIP64、加密與跨平臺集成ZIP64支持是另一個容易被忽略的點。超過4GB的文件或者超過65535個條目的ZIP包需要用到ZIP64擴展字段。minizip較新的版本已經(jīng)支持但舊版本不行。所以我封裝類里特意判斷了文件大小和條目數(shù)量一旦超出普通ZIP限制就直接報錯避免寫入一個無法被其他工具打開的非法文件。加密這塊也要說清楚ZIP加密分為傳統(tǒng)ZipCrypto和AES-256。minizip支持的是ZipCrypto但這套算法已經(jīng)被證明不安全屬于“防君子不防小人”的級別。如果你的項目對安全性有硬性要求建議換用libzip并選擇AES加密。我在類里目前只保留ZipCrypto的兼容入口同時注釋里寫明“不要用于安全敏感場景”。最后一個建議跨平臺集成盡量用CMake的FetchContent或vcpkg管理依賴不要把手寫的zlib源碼直接拷貝到工程里。我過去圖省事拷貝過一份舊版minizip源碼后來因為一個安全補丁沒法順利更新吃了不少苦。源碼類項目最怕的不是寫不出來而是維護不動的貼地飛行。我個人的習慣是把ZipArchive這個類的頭文件和實現(xiàn)文件放在項目的common/archive目錄下用單測覆蓋基礎(chǔ)行為再給業(yè)務(wù)層暴露極簡的接口。能在外圍處理的事情絕不讓底層庫的復雜度滲透到業(yè)務(wù)代碼里。這套思路后來被團隊里其他項目拿去復用遇到新的壓縮格式只需要擴展同樣的接口再追加一個RarArchive或者SevenZipArchive實現(xiàn)就夠了。本文還有配套的精品資源點擊獲取