简介这份数据结构课程设计报告以哈夫曼编码与译码器为题目面向计算机科学与技术等专业的学生及需要完成同类课设的读者帮助理解数据压缩中编码理论的实际落地方式。报告围绕字符频率统计、哈夫曼树构建、编码生成与存储、译码解析等模块展开涵盖结构体定义、字符-哈夫曼编码对照表、createHuffmanTree、generateCodes、encode、decode等函数说明并给出基于最小堆的建树算法与左右子树0/1路径编码规则还配有字符集输入、编码测试、译码测试等程序测试环节与附录程序清单。资源包共1个文件为619KB的pdf文档内容完整、目录清晰便于按章节检索学习。目前已有280人学习下载适合作为课设参考、算法复盘与数据结构应用的实践材料。1. 从一份课程设计报告说起哈夫曼编码与译码器到底能跑出什么很多人对哈夫曼编码的印象停留在课本上那句“带权路径长度最小的二叉树”考试能画树、能算 WPL但真给一组字符和频率让你从零写一个能编码、能译码、还能把二进制流还原回明文的完整程序就开始卡壳。这份《哈夫曼编码与译码器-数据结构课程设计报告.pdf》解决的正是这个断层它不是纯理论推导而是一份带完整程序清单、测试用例和运行截图的工程化报告把字符集输入、哈夫曼树构造、编码对照表生成、编码、译码五个模块串成了一条可复现的链路。适合正在做数据结构课设的学生、想补 C 语言指针与链表实操的开发者以及需要一份能直接对照调试的参考实现的人。下面我按“先讲清结构再落到代码最后说坑”的顺序拆一遍。2. 五个模块怎么串从字符频率到二进制密文的完整链路2.1 模块依赖关系与数据流向这份报告把系统拆成五个功能模块用户输入获取、哈夫曼树构造、字符-哈夫曼编码对照表构造、编码、译码。依赖关系是自底向上的——译码依赖哈夫曼树编码依赖对照表对照表依赖哈夫曼树哈夫曼树依赖用户输入。这个顺序不是随便排的它决定了你写代码时的调用顺序和内存释放顺序。数据流向可以这样理解用户输入一组“字符 频率”输入模块把它们存成叶子结点并挂到双向链表上构造模块反复从链表里取最小和次小的两棵子树合并直到只剩一个根节点对照表模块用深度优先搜索遍历这棵树把每个叶子节点的字符和路径编码存进单链表编码模块拿着对照表逐字符查表输出二进制串译码模块拿着树根按二进制位走左走右走到叶子就输出字符。这里有个容易被忽略的点编码和译码依赖的数据结构不同。编码依赖的是“字符到编码”的映射表译码依赖的是树本身。所以如果你的程序只建了树没建表编码功能就得每次遍历树效率低且代码更绕。报告里把两者分开是合理的工程选择。2.2 三个结构体的分工与内存布局报告里定义了三个结构体分别承担不同职责typedef struct _NODE { char word; // 叶子节点存字符内部节点存 -1 int value; // 权值即字符频率或子树频率和 _NODE *left, *right; // 左右子树指针 } Node, *LPNode; typedef struct _CONTAINER { LPNode v; // 指向哈夫曼树节点的指针 struct _CONTAINER *last, *next; // 双向链表前后指针 } Container, *LPContainer; typedef struct _CODENODE { char word; // 字符 char code[100]; // 哈夫曼编码字符串 struct _CODENODE *next; // 单链表下一节点 } CodeNode, *LPCodeNode;_NODE是哈夫曼树的节点叶子存字符内部节点word设为 -1 作为标记。_CONTAINER是双向链表节点它不存数据本身而是存一个指向树节点的指针这样在合并子树时只需要移动指针不用复制整棵子树。_CODENODE是编码对照表的单链表节点code[100]定长数组意味着编码长度上限 99 位对于一般字符集够用但如果字符种类极多、频率分布极端理论上可能溢出——这是后面避坑部分要说的。_CONTAINER用双向链表而不是数组是因为构造过程中需要频繁地“取最小两个、插入新节点”双向链表在已知插入位置时操作是 O(1)配合按频率升序插入的策略整体构造效率可以接受。如果用数组每次插入都要搬移元素代码反而更啰嗦。2.3 输入模块按频率升序插入双向链表输入模块的核心不是scanf而是插入策略。报告里的insert函数把新节点按value升序插入双向链表void insert(LPContainer list, LPContainer node) { LPContainer p; p list-last; // 从尾节点往前找 while (node-v-value p-v-value) { p p-last; } node-last p; node-next p-next; p-next-last node; p-next node; }这里list是带头节点的双向循环链表list-last是尾节点。从尾部往前找插入位置是因为新插入的节点频率通常不会太小从后往前找平均比较次数更少。找到第一个p-v-value node-v-value的位置后把node插到p后面。参数说明list是链表头node是待插入的容器节点。注意node-v必须已经分配好并填入了word和value。这个插入逻辑保证了链表始终按频率升序排列后续构造哈夫曼树时只需要取list-next和list-next-next就是最小和次小。常见错误是插入时没处理“新节点比所有现有节点都小”的情况。因为用了带头节点的循环链表list-last最终会走到头节点头节点的value初始化为 0如果字符频率都是正数循环会在头节点处停下新节点插到头节点后面逻辑正确。但如果允许频率为 0 或负数这个边界就会出问题——实际字符频率不会为负但为 0 的字符在理论上存在报告没有专门处理属于可接受的简化。3. 构造与编码哈夫曼树怎么建、对照表怎么生成3.1 哈夫曼树构造反复取最小两棵子树合并构造函数的逻辑是只要链表里还有超过一个节点就取最小和次小合并成新子树把新子树按序插回链表。LPNode createHuffmanTree(LPContainer list) { LPContainer p; LPNode left, right, t; while (list-next ! list-last) { // 多于一个节点 // 取最小 p list-next; list-next p-next; list-next-last list; left p-v; free(p); // 取次小 p list-next; list-next p-next; list-next-last list; right p-v; // 合并 t (LPNode)malloc(sizeof(Node)); t-word -1; t-value left-value right-value; t-left left; t-right right; p-v t; insert(list, p); // 复用容器节点插回链表 } // 取出根节点 p list-next; list-next p-next; list-next-last list; left p-v; free(p); return left; }关键点合并时复用了第二个容器节点p把新树节点赋给p-v再插回链表而不是重新malloc一个容器。这样减少了内存分配次数。left和right分别是最小和次小的树节点指针新节点的value是两者之和word设为 -1 表示内部节点。循环终止条件是list-next ! list-last即链表中只剩一个节点时停止。最后把这个节点的v取出来作为根返回容器节点本身释放掉。这里有个细节free(p)释放的是容器节点不是树节点。树节点left和right被挂到新节点t下面不会被释放。如果搞混了释放对象要么内存泄漏要么树被提前销毁。3.2 对照表生成DFS 遍历与路径编码传递对照表用深度优先搜索生成递归时把当前路径编码传下去void dfs(LPNode t, char *code, LPCodeNode list) { LPCodeNode p; char l[100], r[100]; if (t-word ! -1) { // 叶子节点 p (LPCodeNode)malloc(sizeof(CodeNode)); p-word t-word; strcpy(p-code, code); p-next list-next; list-next p; return; } strcpy(l, code); strcat(l, 0); dfs(t-left, l, list); strcpy(r, code); strcat(r, 1); dfs(t-right, r, list); }参数code是到达当前节点时的路径编码初始调用时传空字符串。左子树路径加 0右子树路径加 1。到达叶子时把字符和编码存入新节点头插法插入单链表。用char[100]做路径缓冲每次递归复制一份避免了共享缓冲区被覆盖的问题。代价是递归深度大时栈上会有多个 100 字节数组但哈夫曼树深度通常不超过字符种类数实际不会太深。编码函数就是遍历输入字符串在对照表里查每个字符的编码并输出void code(LPCodeNode list, FILE *in, FILE *out) { char ch; LPCodeNode p; while ((ch fgetc(in)) ! EOF) { p list-next; while (p ! NULL p-word ! ch) { p p-next; } if (p ! NULL) { fputs(p-code, out); } } }查表是线性搜索字符种类多时效率不高但课设规模下够用。如果要优化可以把对照表改成哈希或数组索引。3.3 译码从根出发按位走树译码不需要对照表直接用树void uncode(LPNode root, FILE *in, FILE *out) { LPNode p root; char ch; while ((ch fgetc(in)) ! EOF) { if (ch 0) { p p-left; } else if (ch 1) { p p-right; } if (p-word ! -1) { // 到达叶子 fputc(p-word, out); p root; // 回到根准备下一个字符 } } }每读一个二进制位就往下走一层走到叶子输出字符并回到根。这里假设输入文件只包含 0 和 1如果混入其他字符p可能走到 NULL 导致崩溃。实际使用时应该在p p-left或p p-right后判断p是否为 NULL报告的程序清单里没有这个判断属于可以改进的地方。4. 避坑与排查这份实现里最容易翻车的五个地方4.1 现象程序输入字符后直接崩溃没有任何输出原因GetInput里getchar()和scanf(%c)混用前一次scanf(%d)留下的换行符被%c读走导致字符读入错位后续频率和字符对不上构造树时访问空指针。解决在scanf(%c, p-v-word)前加一个getchar()吃掉换行或者统一用scanf( %c, ...)注意%c前的空格。报告代码里在scanf(%c)前有getchar()但位置在循环开头如果第一次循环前有残留换行仍然可能出问题。稳妥做法是每次读字符前都清一次输入缓冲。4.2 现象编码结果和预期对照表不一致比如 a 的编码不是 1原因哈夫曼树构造时取最小和次小的顺序、以及合并后左右子树的挂法会影响最终编码。报告里先取最小作为left次小作为right左路径为 0、右路径为 1。如果交换了左右编码就反了。解决对照表不是唯一的只要编码和译码用同一棵树就自洽。但如果作业要求特定编码比如 a1, b00, c01就需要按题目规定的左右顺序构造。测试时先用报告里的用例a:10, b:3, c:5验证预期 a1, b00, c01。4.3 现象译码输出多出乱码或提前结束原因编码输出文件没有分隔符译码时按位读如果最后一个字符的编码没有完整写入比如文件缓冲区没刷新或者译码时把换行符也当成二进制位处理就会错位。解决编码写完后确保fclose(out)刷新缓冲区。译码读文件时只处理 0 和 1遇到其他字符跳过或报错。报告的程序清单里译码用fgetc逐字符读如果输入文件末尾有换行会被当成无效位导致p走到 NULL。建议在译码循环里加if (ch ! 0 ch ! 1) continue;。4.4 现象字符种类多时编码被截断原因CodeNode里code[100]定长如果哈夫曼树深度超过 99strcpy会溢出。解决把code改成动态分配或者把上限提高到合理值。实际字符集超过 100 种时哈夫曼树深度可能接近 100但一般文本字符集不超过 256 种极端情况下深度可能达到 255。课设规模下 100 够用但要知道这个边界。4.5 现象内存泄漏程序跑完不报错但占用持续增长原因createHuffmanTree里free(p)释放的是容器节点但容器节点里的v指向的树节点在合并后仍然被引用不能释放。如果误把p-v也 free 了树就断了。反过来如果只释放容器不释放树最后根节点用完没释放就泄漏。解决构造过程中只释放容器节点树节点由新父节点接管。程序结束时如果需要释放整棵树写一个后序遍历递归释放。课设程序通常运行一次就退出操作系统回收内存但养成释放习惯对后续项目有好处。5. 进阶技巧把这份课设改成能处理真实文件的压缩工具课设版本要求手动输入字符和频率实际用起来很鸡肋。我一般会做三个改造第一从文件自动统计频率用int freq[256]数组扫一遍输入文件第二把编码结果按位打包成字节而不是输出 0/1 字符串这样压缩率才真实第三把哈夫曼树或频率表写入压缩文件头部译码时先读头部重建树。自动统计频率的代码很简单int freq[256] {0}; int ch; while ((ch fgetc(in)) ! EOF) { freq[ch]; }然后遍历freq对非零项创建叶子节点插入链表。这样就不需要用户手动输入直接对任意文件生效。按位打包需要一个位缓冲unsigned char buf 0; int bitcnt 0; // 每得到一个编码位 buf (buf 1) | bit; bitcnt; if (bitcnt 8) { fputc(buf, out); buf 0; bitcnt 0; } // 最后不足 8 位时补零并记录有效位数译码时反过来从字节里逐位取出。文件头部可以写一个简单的结构先写字符种类数再写每个字符和频率译码端重建同样的哈夫曼树。这样压缩文件自带解压所需信息不依赖外部对照表。验证方法找一个文本文件压缩后再解压用diff或fc比较原文件和解压文件是否完全一致。如果一致说明编码译码链路正确。再比较压缩前后文件大小对英文文本通常能压到 60% 左右对中文文本压缩率低一些因为中文字符种类多、频率分布更均匀。从那以后我每次做哈夫曼相关的东西都会先用小字符集三五个字符跑通编码译码闭环再上真实文件。小规模能暴露指针和边界问题大规模能暴露性能和内存问题。希望帮到你。本文还有配套的精品资源点击获取
简介这份数据结构课程设计报告以哈夫曼编码与译码器为题目面向计算机科学与技术等专业的学生及需要完成同类课设的读者帮助理解数据压缩中编码理论的实际落地方式。报告围绕字符频率统计、哈夫曼树构建、编码生成与存储、译码解析等模块展开涵盖结构体定义、字符-哈夫曼编码对照表、createHuffmanTree、generateCodes、encode、decode等函数说明并给出基于最小堆的建树算法与左右子树0/1路径编码规则还配有字符集输入、编码测试、译码测试等程序测试环节与附录程序清单。资源包共1个文件为619KB的pdf文档内容完整、目录清晰便于按章节检索学习。目前已有280人学习下载适合作为课设参考、算法复盘与数据结构应用的实践材料。1. 从一份课程设计报告说起哈夫曼编码与译码器到底能跑出什么很多人对哈夫曼编码的印象停留在课本上那句“带权路径长度最小的二叉树”考试能画树、能算 WPL但真给一组字符和频率让你从零写一个能编码、能译码、还能把二进制流还原回明文的完整程序就开始卡壳。这份《哈夫曼编码与译码器-数据结构课程设计报告.pdf》解决的正是这个断层它不是纯理论推导而是一份带完整程序清单、测试用例和运行截图的工程化报告把字符集输入、哈夫曼树构造、编码对照表生成、编码、译码五个模块串成了一条可复现的链路。适合正在做数据结构课设的学生、想补 C 语言指针与链表实操的开发者以及需要一份能直接对照调试的参考实现的人。下面我按“先讲清结构再落到代码最后说坑”的顺序拆一遍。2. 五个模块怎么串从字符频率到二进制密文的完整链路2.1 模块依赖关系与数据流向这份报告把系统拆成五个功能模块用户输入获取、哈夫曼树构造、字符-哈夫曼编码对照表构造、编码、译码。依赖关系是自底向上的——译码依赖哈夫曼树编码依赖对照表对照表依赖哈夫曼树哈夫曼树依赖用户输入。这个顺序不是随便排的它决定了你写代码时的调用顺序和内存释放顺序。数据流向可以这样理解用户输入一组“字符 频率”输入模块把它们存成叶子结点并挂到双向链表上构造模块反复从链表里取最小和次小的两棵子树合并直到只剩一个根节点对照表模块用深度优先搜索遍历这棵树把每个叶子节点的字符和路径编码存进单链表编码模块拿着对照表逐字符查表输出二进制串译码模块拿着树根按二进制位走左走右走到叶子就输出字符。这里有个容易被忽略的点编码和译码依赖的数据结构不同。编码依赖的是“字符到编码”的映射表译码依赖的是树本身。所以如果你的程序只建了树没建表编码功能就得每次遍历树效率低且代码更绕。报告里把两者分开是合理的工程选择。2.2 三个结构体的分工与内存布局报告里定义了三个结构体分别承担不同职责typedef struct _NODE { char word; // 叶子节点存字符内部节点存 -1 int value; // 权值即字符频率或子树频率和 _NODE *left, *right; // 左右子树指针 } Node, *LPNode; typedef struct _CONTAINER { LPNode v; // 指向哈夫曼树节点的指针 struct _CONTAINER *last, *next; // 双向链表前后指针 } Container, *LPContainer; typedef struct _CODENODE { char word; // 字符 char code[100]; // 哈夫曼编码字符串 struct _CODENODE *next; // 单链表下一节点 } CodeNode, *LPCodeNode;_NODE是哈夫曼树的节点叶子存字符内部节点word设为 -1 作为标记。_CONTAINER是双向链表节点它不存数据本身而是存一个指向树节点的指针这样在合并子树时只需要移动指针不用复制整棵子树。_CODENODE是编码对照表的单链表节点code[100]定长数组意味着编码长度上限 99 位对于一般字符集够用但如果字符种类极多、频率分布极端理论上可能溢出——这是后面避坑部分要说的。_CONTAINER用双向链表而不是数组是因为构造过程中需要频繁地“取最小两个、插入新节点”双向链表在已知插入位置时操作是 O(1)配合按频率升序插入的策略整体构造效率可以接受。如果用数组每次插入都要搬移元素代码反而更啰嗦。2.3 输入模块按频率升序插入双向链表输入模块的核心不是scanf而是插入策略。报告里的insert函数把新节点按value升序插入双向链表void insert(LPContainer list, LPContainer node) { LPContainer p; p list-last; // 从尾节点往前找 while (node-v-value p-v-value) { p p-last; } node-last p; node-next p-next; p-next-last node; p-next node; }这里list是带头节点的双向循环链表list-last是尾节点。从尾部往前找插入位置是因为新插入的节点频率通常不会太小从后往前找平均比较次数更少。找到第一个p-v-value node-v-value的位置后把node插到p后面。参数说明list是链表头node是待插入的容器节点。注意node-v必须已经分配好并填入了word和value。这个插入逻辑保证了链表始终按频率升序排列后续构造哈夫曼树时只需要取list-next和list-next-next就是最小和次小。常见错误是插入时没处理“新节点比所有现有节点都小”的情况。因为用了带头节点的循环链表list-last最终会走到头节点头节点的value初始化为 0如果字符频率都是正数循环会在头节点处停下新节点插到头节点后面逻辑正确。但如果允许频率为 0 或负数这个边界就会出问题——实际字符频率不会为负但为 0 的字符在理论上存在报告没有专门处理属于可接受的简化。3. 构造与编码哈夫曼树怎么建、对照表怎么生成3.1 哈夫曼树构造反复取最小两棵子树合并构造函数的逻辑是只要链表里还有超过一个节点就取最小和次小合并成新子树把新子树按序插回链表。LPNode createHuffmanTree(LPContainer list) { LPContainer p; LPNode left, right, t; while (list-next ! list-last) { // 多于一个节点 // 取最小 p list-next; list-next p-next; list-next-last list; left p-v; free(p); // 取次小 p list-next; list-next p-next; list-next-last list; right p-v; // 合并 t (LPNode)malloc(sizeof(Node)); t-word -1; t-value left-value right-value; t-left left; t-right right; p-v t; insert(list, p); // 复用容器节点插回链表 } // 取出根节点 p list-next; list-next p-next; list-next-last list; left p-v; free(p); return left; }关键点合并时复用了第二个容器节点p把新树节点赋给p-v再插回链表而不是重新malloc一个容器。这样减少了内存分配次数。left和right分别是最小和次小的树节点指针新节点的value是两者之和word设为 -1 表示内部节点。循环终止条件是list-next ! list-last即链表中只剩一个节点时停止。最后把这个节点的v取出来作为根返回容器节点本身释放掉。这里有个细节free(p)释放的是容器节点不是树节点。树节点left和right被挂到新节点t下面不会被释放。如果搞混了释放对象要么内存泄漏要么树被提前销毁。3.2 对照表生成DFS 遍历与路径编码传递对照表用深度优先搜索生成递归时把当前路径编码传下去void dfs(LPNode t, char *code, LPCodeNode list) { LPCodeNode p; char l[100], r[100]; if (t-word ! -1) { // 叶子节点 p (LPCodeNode)malloc(sizeof(CodeNode)); p-word t-word; strcpy(p-code, code); p-next list-next; list-next p; return; } strcpy(l, code); strcat(l, 0); dfs(t-left, l, list); strcpy(r, code); strcat(r, 1); dfs(t-right, r, list); }参数code是到达当前节点时的路径编码初始调用时传空字符串。左子树路径加 0右子树路径加 1。到达叶子时把字符和编码存入新节点头插法插入单链表。用char[100]做路径缓冲每次递归复制一份避免了共享缓冲区被覆盖的问题。代价是递归深度大时栈上会有多个 100 字节数组但哈夫曼树深度通常不超过字符种类数实际不会太深。编码函数就是遍历输入字符串在对照表里查每个字符的编码并输出void code(LPCodeNode list, FILE *in, FILE *out) { char ch; LPCodeNode p; while ((ch fgetc(in)) ! EOF) { p list-next; while (p ! NULL p-word ! ch) { p p-next; } if (p ! NULL) { fputs(p-code, out); } } }查表是线性搜索字符种类多时效率不高但课设规模下够用。如果要优化可以把对照表改成哈希或数组索引。3.3 译码从根出发按位走树译码不需要对照表直接用树void uncode(LPNode root, FILE *in, FILE *out) { LPNode p root; char ch; while ((ch fgetc(in)) ! EOF) { if (ch 0) { p p-left; } else if (ch 1) { p p-right; } if (p-word ! -1) { // 到达叶子 fputc(p-word, out); p root; // 回到根准备下一个字符 } } }每读一个二进制位就往下走一层走到叶子输出字符并回到根。这里假设输入文件只包含 0 和 1如果混入其他字符p可能走到 NULL 导致崩溃。实际使用时应该在p p-left或p p-right后判断p是否为 NULL报告的程序清单里没有这个判断属于可以改进的地方。4. 避坑与排查这份实现里最容易翻车的五个地方4.1 现象程序输入字符后直接崩溃没有任何输出原因GetInput里getchar()和scanf(%c)混用前一次scanf(%d)留下的换行符被%c读走导致字符读入错位后续频率和字符对不上构造树时访问空指针。解决在scanf(%c, p-v-word)前加一个getchar()吃掉换行或者统一用scanf( %c, ...)注意%c前的空格。报告代码里在scanf(%c)前有getchar()但位置在循环开头如果第一次循环前有残留换行仍然可能出问题。稳妥做法是每次读字符前都清一次输入缓冲。4.2 现象编码结果和预期对照表不一致比如 a 的编码不是 1原因哈夫曼树构造时取最小和次小的顺序、以及合并后左右子树的挂法会影响最终编码。报告里先取最小作为left次小作为right左路径为 0、右路径为 1。如果交换了左右编码就反了。解决对照表不是唯一的只要编码和译码用同一棵树就自洽。但如果作业要求特定编码比如 a1, b00, c01就需要按题目规定的左右顺序构造。测试时先用报告里的用例a:10, b:3, c:5验证预期 a1, b00, c01。4.3 现象译码输出多出乱码或提前结束原因编码输出文件没有分隔符译码时按位读如果最后一个字符的编码没有完整写入比如文件缓冲区没刷新或者译码时把换行符也当成二进制位处理就会错位。解决编码写完后确保fclose(out)刷新缓冲区。译码读文件时只处理 0 和 1遇到其他字符跳过或报错。报告的程序清单里译码用fgetc逐字符读如果输入文件末尾有换行会被当成无效位导致p走到 NULL。建议在译码循环里加if (ch ! 0 ch ! 1) continue;。4.4 现象字符种类多时编码被截断原因CodeNode里code[100]定长如果哈夫曼树深度超过 99strcpy会溢出。解决把code改成动态分配或者把上限提高到合理值。实际字符集超过 100 种时哈夫曼树深度可能接近 100但一般文本字符集不超过 256 种极端情况下深度可能达到 255。课设规模下 100 够用但要知道这个边界。4.5 现象内存泄漏程序跑完不报错但占用持续增长原因createHuffmanTree里free(p)释放的是容器节点但容器节点里的v指向的树节点在合并后仍然被引用不能释放。如果误把p-v也 free 了树就断了。反过来如果只释放容器不释放树最后根节点用完没释放就泄漏。解决构造过程中只释放容器节点树节点由新父节点接管。程序结束时如果需要释放整棵树写一个后序遍历递归释放。课设程序通常运行一次就退出操作系统回收内存但养成释放习惯对后续项目有好处。5. 进阶技巧把这份课设改成能处理真实文件的压缩工具课设版本要求手动输入字符和频率实际用起来很鸡肋。我一般会做三个改造第一从文件自动统计频率用int freq[256]数组扫一遍输入文件第二把编码结果按位打包成字节而不是输出 0/1 字符串这样压缩率才真实第三把哈夫曼树或频率表写入压缩文件头部译码时先读头部重建树。自动统计频率的代码很简单int freq[256] {0}; int ch; while ((ch fgetc(in)) ! EOF) { freq[ch]; }然后遍历freq对非零项创建叶子节点插入链表。这样就不需要用户手动输入直接对任意文件生效。按位打包需要一个位缓冲unsigned char buf 0; int bitcnt 0; // 每得到一个编码位 buf (buf 1) | bit; bitcnt; if (bitcnt 8) { fputc(buf, out); buf 0; bitcnt 0; } // 最后不足 8 位时补零并记录有效位数译码时反过来从字节里逐位取出。文件头部可以写一个简单的结构先写字符种类数再写每个字符和频率译码端重建同样的哈夫曼树。这样压缩文件自带解压所需信息不依赖外部对照表。验证方法找一个文本文件压缩后再解压用diff或fc比较原文件和解压文件是否完全一致。如果一致说明编码译码链路正确。再比较压缩前后文件大小对英文文本通常能压到 60% 左右对中文文本压缩率低一些因为中文字符种类多、频率分布更均匀。从那以后我每次做哈夫曼相关的东西都会先用小字符集三五个字符跑通编码译码闭环再上真实文件。小规模能暴露指针和边界问题大规模能暴露性能和内存问题。希望帮到你。本文还有配套的精品资源点击获取
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
