13518219792
压缩原因
1.文件太大，节省空间
2.提高数据在网络上传输的效率
3.对数据起到保护作用---加密
文件压缩类型
无损压缩：源文件被压缩之后，可以通过解压缩还原成与源文件相同的格式
有损压缩：源文件被压缩之后，解压缩无法还原成与源文件相同，但识别其内容没有影响，多用于语音，图片，视频压缩
基于Huffman树的压缩如何实现
通过Huffman编码实现，字符一般都是以字节存储的，通过编码转换为二进制编码（1字节=8比特位）
首先，什么是Huffman树
给定N个权值作为N个叶子结点，构造一棵二叉树，若该树的带权路径长度达到最小，称这样的二叉树为最优二叉树，也称为哈夫曼树。哈夫曼树是带权路径长度最短的树，权值较大的结点离根较近。
例如：给定权值为1（A）,3（B）,5（C）,7（D）四个节点，构建Huffman树
Huffman压缩原理--基于Huffman编码
以字符串中每个字符出现的次数为权值构建Huffman树
从根节点开始，左分支为0，右分支为1，如上图
所有权值节点都在叶子节点位置，遍历每条到叶子节点的路径获取字符的编码
举个栗子：ABBBCCCCCDDDDDDD
Huffman编码：
A:100
B:101
C:11
D:0
原理就是这么简单，一个字符占一个字节，现在用二进制编码代替之后，一个字符只占三位，也就是说一个字节可以表示两三个字符，所以说一次压缩，就会节省很多字节，也就起到了压缩的作用。
项目中最重要的是三点
创建Huffman树
1 先用权值创建n棵只有根节点的二叉树森林【意思是先创建n个节点】
2 选取根节点权值最小的二叉树构建新的二叉树【建小堆，新二叉树根节点权值为左右子树的根节点权值之和】【用到了priority_queue优先级队列】
3 删除使用的两棵根节点权值较小的二叉树
4 将新创建的二叉树添加到二叉树森林中
接下来2-4循环继续，直到二叉树森林中只有一棵二叉树则Huffman树创建成
文件压缩过程：
1读取源文件，读取源文件中每个字符出现的次数 2 以每个字符出现的次数作为权值，创建huffman树：小堆--优先级队列 3 通过huffman树找每个字符对应的编码 4 用每个字符的新编码重新对源文件进行改写【翻译的过程】
文件解压缩的过程：
- 从压缩文件中获取源文件的后缀
- 从压缩文件中获取字符次数的总行数
- 获取每个字符出现的次数
- 重建huffman树
- 解压压缩数据
a. 从压缩文件中读取一个字节的获取压缩数据ch
b. 从根节点开始，按照ch的8个比特位信息从高到低遍历huffman树：该比特位是0，取当前节点的左孩子，否则取右孩子，直到遍历到叶子节点位置，该字符就被解析成功，将解压出的字符写入文件，如果在遍历huffman过程中，8个比特位已经比较完毕还没有到达叶子节点，从a开始执行
c. 重复以上过程，直到所有的数据解析完毕。
写代码当中碰到的一些主要的问题，我将这些总结起来：
1.编译的时候：
刚开始写的时候测试发现如果压缩文件中出现了中文，程序就会崩溃，最后发现是数组越界的错误，因为如果只是字符，它的范围是-128~127，程序中使用char类型为数组下标(0~127)，所以字符没有问题. 但是汉字的编码是两个字节，所以可能会出现越界，
解决方法：就是将char类型强转为unsigned char，下标可表示范围为0~255.
2.解压缩的时候
有些特殊字符在处理需要注意一下，比如'\n'，我的程序中Getline()函数就是读取一行字符，但是若是该字符本身就是一个'\n'呢？ 这就非常的棘手了. 因为解压缩之后出现了乱码
解决方法：读取压缩文件时若读到了'\n',则说明该字符就是'\n'，应该继续读取它的次数
3.运行的时候：
发现文件篇幅很长的时候，只能压缩和解压缩一部分，是因为字符长度的设定太小
解决方法：_count长度设为unsigned long long类型
4.还有许多大大小小的问题等等
压缩率
| 文件类型 | 源文件大小 | 压缩后大小 | 压缩率 |
|---|---|---|---|
| word文档 | 31.5KB | 32.1KB | 1.02 |
| 音频文件 | 29.8 MB | 29.8MB | 0.99 |
| 视频文件 | 20.7MB | 20.7MB | 0.99 |
全部代码（GitHub）：https://github.com/wake5up/My-c--code/tree/master/compress
