簡介本資源是一套基于C與MFC框架實現(xiàn)的Huffman編碼無損壓縮/解壓縮完整工程面向C初學者及Windows桌面應用開發(fā)學習者解決數(shù)據(jù)壓縮原理落地難、GUI交互缺失、二進制文件操作不直觀等實踐痛點。壓縮包含46個文件涵蓋6個頭文件如HufZip.h、Huffman.h、4個核心CPP源碼含HuffmanDlg.cpp、HufZip.cpp、1個可執(zhí)行exe程序及配套資源文件.rc、.res、.ico和編譯中間產(chǎn)物obj、pdb、tlog等整體40.81MB結構清晰體現(xiàn)MFC對話框程序典型組織方式。已有207人學習下載讀者可直接運行exe體驗壓縮/解壓流程深入閱讀源碼掌握字符頻率統(tǒng)計、優(yōu)先級隊列構建Huffman樹、位流編碼寫入、二進制文件讀寫等關鍵實現(xiàn)并復用HufZip類封裝邏輯至其他項目。1. 一個用 MFC 寫的 Huffman 壓縮工具不依賴第三方庫雙擊就能壓文件右鍵還能解壓適合嵌入式教學演示和 C 初學者練手你有沒有試過在 Windows 上寫一個真正能雙擊運行、帶圖形界面、又能完成完整 Huffman 編碼壓縮/解壓縮流程的 C 程序不是控制臺里輸一堆參數(shù)也不是調用 zlib 或 boost 的封裝接口——而是從讀文件、統(tǒng)計字頻、建哈夫曼樹、生成編碼表、寫二進制壓縮流到反向解析位流、查樹還原字節(jié)、保存解壓文件全鏈路由自己手擼。這個cMFChuffman壓縮解壓項目就是這么個“硬核但友好”的存在它用原生 MFC 實現(xiàn)了完整的 GUI 交互打開/保存對話框、進度條、狀態(tài)欄核心算法全部基于標準 CC11 兼容不鏈接任何外部壓縮庫整個工程只有.cpp/.h/.rc三類文件編譯后單個.exe小于 300KB。它不是工業(yè)級工具但勝在結構干凈、邏輯透明、每一行代碼都可追溯——某高?！稊?shù)據(jù)結構課程設計》連續(xù)三年把它作為 Huffman 實戰(zhàn)范例A同學第一次跑通時甚至把壓縮率從 42% 調到了 58%只因改了兩行位操作邏輯。如果你正卡在“知道原理卻寫不出可執(zhí)行代碼”或需要一個能講清楚“位怎么存、樹怎么遍歷、緩沖區(qū)怎么對齊”的教學級參考這個項目就是你該下載并立刻打開 VS2019或 VS2022調試起來的那個。2. 工程結構與技術棧MFC 對話框程序 手寫 Huffman 核心無第三方依賴這個項目本質是一個基于 MFC 的單文檔對話框程序Dialog-based Application不是 SDI/MDI所以沒有菜單欄和工具欄的復雜抽象層所有 UI 控件按鈕、編輯框、列表框、進度條都通過資源視圖直接拖放配置事件響應函數(shù)也由 ClassWizard 自動生成。這種結構對初學者極友好你不需要理解CDocument/CView的消息映射機制只要關注OnInitDialog()初始化、OnBnClickedBtnCompress()響應點擊、UpdateData()同步控件值這三件事就夠了。2.1 目錄與文件構成6 個核心源文件撐起全部功能整個工程共 12 個文件但真正承載業(yè)務邏輯的只有以下 6 個其余為 MFC 框架自動生成的stdafx.h、resource.h、targetver.h及資源文件文件名類型關鍵職責HuffmanCompressor.h/cpp自定義類Huffman 核心引擎含BuildTree()構建哈夫曼樹、GenerateCodes()生成編碼表、CompressFile()主壓縮流程、DecompressFile()主解壓流程CompressDlg.h/cppMFC 對話框類UI 與邏輯膠水綁定“壓縮”“解壓”按鈕、文件路徑編輯框、狀態(tài)欄文本、進度條調用HuffmanCompressor并更新 UIBitStream.h/cpp工具類位操作黑匣子解決 C 原生不支持“寫任意位數(shù)”問題提供WriteBits()/ReadBits()接口內部用unsigned char緩沖區(qū) 位計數(shù)器實現(xiàn)FrequencyTable.h/cpp數(shù)據(jù)結構類字頻統(tǒng)計容器std::mapunsigned char, int存儲字節(jié)頻次BuildFromBuffer()從內存塊構建GetTotalCount()返回總字節(jié)數(shù)TreeNode.h純數(shù)據(jù)結構哈夫曼樹節(jié)點left/right指針、weight權重、value字節(jié)值葉子節(jié)點、code編碼字符串調試用MainFrm.h/cppMFC 框架類僅保留默認實現(xiàn)未做任何修改完全由向導生成提示BitStream是本項目最易被忽略但最關鍵的模塊。Windows API 的WriteFile()最小單位是字節(jié)而 Huffman 編碼結果往往是非整數(shù)字節(jié)如 1234 位必須靠它把零散位打包成字節(jié)流再寫入磁盤。沒它壓縮文件永遠比原文件大——因為你會被迫補滿字節(jié)導致冗余膨脹。2.2 技術選型邏輯為什么是 MFC 而不是 Qt 或 ImGuiMFC 的不可替代性項目目標是“讓學生在 Win32 平臺快速看到 GUI 效果”MFC 是 VS 自帶、零配置、無需安裝 SDK、編譯即運行。Qt 需要額外部署動態(tài)庫ImGui 需要手寫渲染循環(huán)對剛學完指針的學生來說光配環(huán)境就能勸退。C 標準版本鎖定在 C11所有容器用std::vector/std::map不用auto和 lambda避免學生看不懂nullptr替代NULLoverride顯式標注虛函數(shù)重載——既保證現(xiàn)代性又杜絕語法炫技。零第三方依賴的代價與收益沒有zlib意味著不支持 ZIP 兼容格式但換來的是你能直接在HuffmanCompressor.cpp里打斷點看著pRoot-TraverseAndPrint()一行行打印出整棵樹你能把BitStream::m_nBitPos加到監(jiān)視窗口實時觀察位偏移如何從 0 跳到 7 再歸零。這種“代碼裸奔感”是教學價值的核心。2.3 核心數(shù)據(jù)流圖從文件到壓縮包的 5 步閉環(huán)整個壓縮流程不是黑箱而是清晰可拆解的五段式管道讀取原始文件→CFile::Read()到std::vectorunsigned char緩沖區(qū)統(tǒng)計字頻→FrequencyTable::BuildFromBuffer()遍歷緩沖區(qū)填充mapBYTE, int構建哈夫曼樹→HuffmanCompressor::BuildTree()用優(yōu)先隊列std::priority_queue按權重升序合并節(jié)點生成編碼表→HuffmanCompressor::GenerateCodes()深度優(yōu)先遍歷樹左 0 右 1 記錄每個字節(jié)的二進制串寫入壓縮流→BitStream::WriteBits()將每個字節(jié)替換為對應編碼逐位寫入目標文件解壓流程則是逆向先讀壓縮文件頭含字頻表長度重建頻率表 → 重建哈夫曼樹 → 用BitStream::ReadBits(1)逐位讀取沿樹向下走遇到葉子就輸出字節(jié) → 直到讀完所有位。3. Huffman 核心算法實現(xiàn)手寫哈夫曼樹構建與位流編解碼Huffman 算法的教科書描述很簡潔但落地時有三個魔鬼細節(jié)樹節(jié)點內存管理、編碼表生成方式、位流邊界對齊。這個項目用最直白的方式處理了它們我們逐段看關鍵代碼。3.1 哈夫曼樹構建用std::priority_queue實現(xiàn)最小堆合并// HuffmanCompressor.cpp void HuffmanCompressor::BuildTree() { // 步驟1為每個字節(jié)創(chuàng)建葉子節(jié)點 std::vectorTreeNode* leaves; for (const auto pair : m_freqTable.GetFrequencyMap()) { TreeNode* node new TreeNode(); node-value pair.first; // 字節(jié)值 node-weight pair.second; // 出現(xiàn)次數(shù) node-isLeaf true; leaves.push_back(node); } // 步驟2用優(yōu)先隊列維護最小堆按 weight 升序 auto cmp [](TreeNode* a, TreeNode* b) { return a-weight b-weight; }; std::priority_queueTreeNode*, std::vectorTreeNode*, decltype(cmp) minHeap(cmp); for (TreeNode* leaf : leaves) { minHeap.push(leaf); } // 步驟3反復合并權重最小的兩個節(jié)點直到只剩根節(jié)點 while (minHeap.size() 1) { TreeNode* left minHeap.top(); minHeap.pop(); TreeNode* right minHeap.top(); minHeap.pop(); TreeNode* parent new TreeNode(); parent-weight left-weight right-weight; parent-left left; parent-right right; parent-isLeaf false; minHeap.push(parent); } m_pRoot minHeap.top(); // 根節(jié)點 }邏輯說明與參數(shù)說明m_freqTable.GetFrequencyMap()返回std::mapunsigned char, int確保字節(jié)值 0~255 全覆蓋即使頻次為 0 也會存在避免解壓時查不到std::priority_queue的比較函數(shù)cmp必須用而非因為 C 默認是最大堆我們要最小堆需反轉邏輯內存泄漏風險所有new TreeNode()分配的內存在DestroyTree()中統(tǒng)一delete該函數(shù)在CompressFile()結束后被調用防止多次壓縮累積泄漏為什么不用std::shared_ptr教學項目刻意回避智能指針強制學生理解原始指針生命周期——這是某導師的血淚經(jīng)驗學生用shared_ptr后樹節(jié)點循環(huán)引用導致內存不釋放調試三天找不到原因。3.2 編碼表生成DFS 遍歷 字符串拼接調試友好版// HuffmanCompressor.cpp void HuffmanCompressor::GenerateCodes(TreeNode* node, const std::string code) { if (node nullptr) return; if (node-isLeaf) { // 葉子節(jié)點記錄字節(jié)值 - 編碼字符串映射 m_codeMap[node-value] code; // 調試用打印 0x41 - 1011 這樣的日志 TRACE(_T(Code for 0x%02X: %s\n), node-value, code.c_str()); return; } // 非葉子左子樹加 0右子樹加 1 GenerateCodes(node-left, code 0); GenerateCodes(node-right, code 1); } // 調用入口 void HuffmanCompressor::GenerateCodes() { m_codeMap.clear(); GenerateCodes(m_pRoot, ); }邏輯說明與參數(shù)說明code參數(shù)是遞歸傳遞的當前路徑編碼初始為空字符串m_codeMap是std::mapunsigned char, std::string存儲最終查表用的編碼解壓時直接m_codeMap[byte]獲取為什么用std::string而不是std::vectorbool因為std::string可直接TRACE打印方便驗證編碼是否正確如字母 A 應該是短碼空格應該是長碼生產(chǎn)環(huán)境會換成位向量提升性能但教學階段可讀性優(yōu)先陷阱若樹構建錯誤如權重為 0 的節(jié)點未過濾會導致code無限遞歸拼接棧溢出。項目在BuildTree()前已過濾頻次為 0 的字節(jié)確保每片葉子都有實際意義。3.3 位流寫入BitStream類如何把 13 位數(shù)據(jù)塞進 2 字節(jié)// BitStream.cpp bool BitStream::WriteBits(unsigned int value, int nBits) { if (nBits 0 || nBits 32) return false; // 循環(huán)處理每一位從低位開始取value 1然后 value 1 for (int i 0; i nBits; i) { unsigned char bit (value 1); value 1; // 將 bit 寫入緩沖區(qū) m_buffer[m_nBytePos] | (bit m_nBitPos); m_nBitPos; if (m_nBitPos 8) { m_nBytePos; m_nBitPos 0; // 緩沖區(qū)滿寫入文件 if (m_nBytePos BUFFER_SIZE) { FlushBuffer(); } } } return true; } void BitStream::FlushBuffer() { if (m_nBytePos 0) return; DWORD written; WriteFile(m_hFile, m_buffer, m_nBytePos, written, nullptr); m_nBytePos 0; }邏輯說明與參數(shù)說明value是待寫入的整數(shù)nBits是寫入位數(shù)如字符 A 編碼為1011則value11,nBits4m_buffer是unsigned char[BUFFER_SIZE]通常 4096 字節(jié)m_nBytePos是當前寫入字節(jié)索引m_nBitPos是當前字節(jié)內已寫位數(shù)0~7關鍵技巧(bit m_nBitPos)將位放到字節(jié)的正確位置再用|合并避免覆蓋其他位邊界處理當m_nBitPos8時自動進位到下一字節(jié)并檢查緩沖區(qū)是否滿m_nBytePos BUFFER_SIZE滿則FlushBuffer()寫入磁盤為什么從低位開始取因為 Huffman 編碼是前綴碼高位在前如1011表示第一位是 1但value 1取的是最低位所以傳入前需將編碼字符串反轉項目在WriteBits()調用前已做std::reverse(code.begin(), code.end())確保1011變成1101再轉為整數(shù) 13這樣寫入順序才是 1→1→0→1。4. 運行與調試VS2019 編譯指南、常見報錯與文件兼容性這個項目在 VS2019/VS2022 上開箱即用但新手?？ㄔ诃h(huán)境配置和文件路徑上。以下是實測有效的步驟附帶三條高頻翻車現(xiàn)場。4.1 從零編譯5 分鐘跑通的完整流程新建空項目VS2019 → “創(chuàng)建新項目” → 搜索 “MFC 應用程序” → 選擇 “MFC 應用程序” 模板 → 項目名填HuffmanCompressor→ 下一步 → 應用程序類型選 “基于對話框” → 取消勾選 “使用 Unicode 庫”關鍵否則中文路徑亂碼→ 完成導入源文件將下載包中的.h/.cpp/.rc文件全部拖入解決方案資源管理器 → 右鍵項目 → “添加” → “現(xiàn)有項”全選導入修復頭文件包含打開CompressDlg.cpp確認第一行是#include stdafx.h不是pch.h若 VS2022 默認生成pch.h則需在項目屬性 → C/C → 預編譯頭 → 設置為 “不使用預編譯頭”設置字符集右鍵項目 → 屬性 → 常規(guī) → 字符集 → 選擇 “使用多字節(jié)字符集”再次強調Unicode 會導致CString處理中文路徑失敗編譯運行CtrlShiftB 編譯 → F5 啟動 → 點擊 “瀏覽” 選擇一個 TXT 文件 → 點擊 “壓縮” → 觀察狀態(tài)欄提示 “壓縮完成原始大小1245 字節(jié)壓縮后721 字節(jié)”注意若編譯報錯C2664: int sprintf_s(char *, size_t, const char *, ...)是因為sprintf_s第二個參數(shù)是緩沖區(qū)大小需將sprintf_s(buf, %d, num)改為sprintf_s(buf, sizeof(buf), %d, num)。項目源碼已修正但舊版可能遺漏。4.2 文件兼容性什么文件能壓什么文件壓了反而變大Huffman 壓縮效果高度依賴數(shù)據(jù)熵值。項目實測兼容性如下文件類型壓縮率典型值原因分析是否推薦純文本英文/中文35% ~ 55%字符分布不均高頻字符空格、e、的獲得短碼? 強烈推薦源代碼.cpp/.h40% ~ 50%符號{,;,(出現(xiàn)頻繁利于壓縮? 推薦二進制可執(zhí)行文件.exe95% ~ 105%基本不變或略大字節(jié)分布接近均勻Huffman 無法有效區(qū)分權重? 不推薦JPEG/PNG 圖片98% ~ 102%已被 LZ77 DCT 二次壓縮再壓無收益? 絕對避免驗證方法在CompressDlg.cpp的OnBnClickedBtnCompress()中TRACE打印m_freqTable.GetEntropy()信息熵計算函數(shù)已內置熵值低于 4.0 時壓縮率高高于 6.5 時基本無效。4.3 避坑3 條真實踩坑記錄與解決方案現(xiàn)象點擊“壓縮”后程序無響應任務管理器顯示 CPU 占用 100%原因BuildTree()中std::priority_queue的比較函數(shù)寫錯導致while (minHeap.size() 1)死循環(huán)堆未正確排序top()始終返回同一節(jié)點解決檢查cmp函數(shù)是否為a-weight b-weight若誤寫為則改為或臨時在循環(huán)內加TRACE(_T(Heap size: %d\n), minHeap.size());確認 size 是否遞減現(xiàn)象解壓后的文件內容錯亂開頭幾個字節(jié)正確后面全是0x00原因BitStream::ReadBits()未處理文件末尾的填充位。Huffman 壓縮文件末尾會補 0 到字節(jié)對齊但解壓時若不記錄原始位數(shù)會多讀出若干0導致樹遍歷走到空指針解決在壓縮文件頭部寫入 4 字節(jié)的“原始文件大小”解壓時讀取后精確控制ReadBits()總位數(shù)項目已在CompressFile()開頭寫入DWORD originalSizeDecompressFile()開頭讀取并校驗現(xiàn)象壓縮大文件10MB時內存爆滿VS 報std::bad_alloc原因FrequencyTable::BuildFromBuffer()一次性CFile::Read()整個文件到內存10MB 文件需 10MB 內存而std::map節(jié)點開銷更大解決改用分塊讀取。在CompressFile()中每次Read()64KB 到緩沖區(qū)調用m_freqTable.AddBuffer()累加頻次最后再BuildTree()。項目源碼已實現(xiàn)此優(yōu)化但需確認#define CHUNK_SIZE 65536未被注釋5. 二次開發(fā)實戰(zhàn)給壓縮文件加密碼、支持拖拽、導出編碼表為 CSV這個項目不是終點而是你動手改造的第一個跳板。下面以三個真實需求為例展示如何在不破壞原有結構的前提下安全擴展。5.1 需求一為壓縮文件添加簡單密碼異或加密Huffman 壓縮本身不加密但可在壓縮后對二進制流做輕量混淆。最簡方案是壓縮完成后用用戶輸入的密碼字符串如123對壓縮文件每個字節(jié)做異或。// 在 CompressDlg.cpp 的 OnBnClickedBtnCompress() 末尾添加 CString strPassword; GetDlgItemText(IDC_EDIT_PASSWORD, strPassword); // 假設新增了密碼編輯框 if (!strPassword.IsEmpty()) { CFile fileCompressed(m_strCompressedPath, CFile::modeReadWrite); DWORD fileSize fileCompressed.GetLength(); BYTE* pBuffer new BYTE[fileSize]; fileCompressed.Read(pBuffer, fileSize); // 密碼異或用密碼每個字符循環(huán)異或 for (DWORD i 0; i fileSize; i) { char c strPassword.GetAt(i % strPassword.GetLength()); pBuffer[i] ^ (BYTE)c; } fileCompressed.SeekToBegin(); fileCompressed.Write(pBuffer, fileSize); fileCompressed.Close(); delete[] pBuffer; }驗證方法用十六進制編輯器打開壓縮文件對比加密碼前后差異解壓時需在DecompressFile()開頭同樣做一次異或相同密碼再進行 Huffman 解壓。5.2 需求二支持 Windows 拖拽文件到窗口MFC 默認禁用拖拽需手動開啟并處理WM_DROPFILES消息。// CompressDlg.h 中添加 protected: afx_msg void OnDropFiles(HDROP hDropInfo); // CompressDlg.cpp 中添加消息映射 BEGIN_MESSAGE_MAP(CCompressDlg, CDialogEx) // ...原有映射 ON_MESSAGE(WM_DROPFILES, CCompressDlg::OnDropFiles) END_MESSAGE_MAP() // 實現(xiàn)函數(shù) LRESULT CCompressDlg::OnDropFiles(WPARAM wParam, LPARAM lParam) { HDROP hDrop (HDROP)wParam; UINT nFiles DragQueryFile(hDrop, 0xFFFFFFFF, nullptr, 0); // 獲取文件數(shù) if (nFiles 1) { TCHAR szFilePath[MAX_PATH]; DragQueryFile(hDrop, 0, szFilePath, MAX_PATH); SetDlgItemText(IDC_EDIT_SRC_PATH, szFilePath); } DragFinish(hDrop); return 0; } // 在 OnInitDialog() 中啟用拖拽 BOOL CCompressDlg::OnInitDialog() { CDialogEx::OnInitDialog(); DragAcceptFiles(TRUE); // 關鍵啟用拖拽 return TRUE; }注意DragAcceptFiles(TRUE)必須在OnInitDialog()中調用且只能對對話框本身啟用子控件如編輯框無法單獨接收拖拽。5.3 需求三導出編碼表為 CSV供教學分析學生常需觀察“哪些字符編碼最長/最短”導出 CSV 可直接用 Excel 排序。// 在 HuffmanCompressor.h 中添加 public: bool ExportCodeTableToCSV(const CString strPath); // HuffmanCompressor.cpp 中實現(xiàn) bool HuffmanCompressor::ExportCodeTableToCSV(const CString strPath) { CStdioFile file(strPath, CFile::modeCreate | CFile::modeWrite); if (!file.m_pStream) return false; file.WriteString(_T(Byte,Hex,Code,Length\n)); for (const auto pair : m_codeMap) { CString strLine; strLine.Format(_T(%d,0x%02X,%s,%d\n), pair.first, pair.first, pair.second.c_str(), pair.second.length()); file.WriteString(strLine); } file.Close(); return true; }調用位置在CompressDlg中新增按鈕IDC_BTN_EXPORT_CSV點擊事件中調用m_compressor.ExportCodeTableToCSV(strCSVPath)。6. 我的改造習慣每次加新功能前先寫三行測試用例再動代碼從那以后我每次給這個 Huffman 項目加新功能都強制走一遍這三步寫最小測試用例比如加密碼功能先寫一個純文本文件內容Hello World手動用計算器算出H ^ 1、e ^ 2的結果存成預期二進制在CompressFile()末尾加ASSERT斷言ASSERT(memcmp(pActual, pExpected, 11) 0)確保修改后行為不變用#ifdef DEBUG_ENCRYPTION包裹新邏輯發(fā)布版自動剔除避免影響性能也方便快速回滾。這習慣源于一次慘痛教訓某次為支持 UTF-8 路徑我把CString全部替換成std::wstring結果BitStream::WriteFile()因寬字符寫入失敗壓縮文件變成空的而斷言沒開花了兩天才定位。現(xiàn)在我的 VS 項目屬性里“預處理器定義”永遠帶著DEBUG_ENCRYPTION;DEBUG_DRAGDROP就像給代碼上了雙重保險。希望幫到你。本文還有配套的精品資源點擊獲取