压缩原因
1.文件太大，节省空间
2.提高数据在网络上传输的效率
3.对数据起到保护作用---加密
文件压缩类型
无损压缩：源文件被压缩之后，可以通过解压缩还原成与源文件相同的格式
有损压缩：源文件被压缩之后，解压缩无法还原成与源文件相同，但识别其内容没有影响，多用于语音，图片，视频压缩
基于Huffman树的压缩如何实现
首先先对文件进行LZ77压缩（也就是基于字符层面的压缩），然后在LZ77压缩文件的基础上再进行Huffman压缩
第一，什么是LZ77压缩
LZ77是基于字节的通用压缩算法，它的原理就是将源文件中的重复字节(即在前文中出现的重复字节)使用（长度，距离）对来表示，例如
mnoabczxyuvwabc123456abczxydefgh
压缩之后：mnoabczxyuvm93123456186defgh。
为了记录压缩之后的数据到底是文件数据还是（长度距离）对，而又加了一个信息文件
信息文件（比特位）：0代表数据，1代表的是长度距离对
LZ77压缩原理
1.构建一个64k连续空间窗口（文件数据读取的缓冲区），窗口中分为查找缓冲区和先行缓冲区，先行缓冲区中数据压缩时，通过哈希表找出最长匹配串即距离，如果没有在前文中找到重复则把原字节放入压缩文件中，如果找到重复，则把长度距离对放入压缩文件中
2.构建哈希表，由于压缩时写长度距离对时有三个字节，所以低于三字节的数据不压缩，所以哈希表构建需要256256256，即2^24个空间个数，也就是32M,但是由于空间太大，以及随着压缩不断进行，哈希表中内容不断更新，维护起来特别耗时，最终给哈希表的个数为2^15个空间，在这种“狼多肉少”的情况下，为了避免哈希冲突，采用了64k的连续空间来维护哈希表，右窗head空间全置为0
3.通过读取文件以三个字节为一组填入哈希表中，如果遇到单组字节，直接填入，如果遇到重复字节，把右窗中的数值填入左窗，即
4.为了让解压缩的时候可以识别到底是数据文件还是长度距离对，而又加了一个信息文件 信息文件（比特位）：0代表数据，1代表的是长度距离对 对每一个字节压缩的时候，需要同时判断压缩字节是否为长度距离对，按比特位压入
第二，什么是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压缩中最重要的是三点 创建Huffman树：
1 先用权值创建n棵只有根节点的二叉树森林【意思是先创建n个节点】
2 选取根节点权值最小的二叉树构建新的二叉树【建小堆，新二叉树根节点权值为左右子树的根节点权值之和】【用到了priority_queue优先级队列】
3 删除使用的两棵根节点权值较小的二叉树
4 将新创建的二叉树添加到二叉树森林中
接下来2-4循环继续，直到二叉树森林中只有一棵二叉树则Huffman树创建成
文件压缩过程：
1读取源文件，读取源文件中每个字符出现的次数
2 以每个字符出现的次数作为权值，创建huffman树：小堆--优先级队列
3 通过huffman树找每个字符对应的编码
4 用每个字符的新编码重新对源文件进行改写【翻译的过程】
文件解压缩的过程：
1 从压缩文件中获取源文件的后缀
2 从压缩文件中获取字符次数的总行数
3 获取每个字符出现的次数
4 重建huffman树
5 解压压缩数据
a. 从压缩文件中读取一个字节的获取压缩数据ch
b. 从根节点开始，按照ch的8个比特位信息从高到低遍历huffman树：该比特位是0，取当前节点的左孩子，否则取右孩子，直到遍历到叶子节点位置，该字符就被解析成功，将解压出的字符写入文件，如果在遍历huffman过程中，8个比特位已经比较完毕还没有到达叶子节点，从a开始执行
c. 重复以上过程，直到所有的数据解析完毕。
第三，对LZ77和Huffman压缩进行整合 文件压缩和解压缩过程：LZ77压缩-->Huffman压缩(LZ77基础上)-->Huffman解压缩-->LZ77解压缩 1.整合过程中，会出现临时文件（LZ77压缩信息文件，LZ77压缩后的压缩文件，Huffman解压缩之后的文件），所以需要对这些文件进行删除：remove函数 2.压缩文件和解压缩过程中，LZ77和Huffman有交替过程，所以在调用函数时的传参过程需要封装
写代码当中碰到的一些主要的问题，我将这些总结起来： LZ77过程： 编程前：
首先知识层面的欠缺，查阅了好多资料
编程时：
1.当压缩文件压缩至右窗的时候，为了防止哈希表中prev（数组）越界，需要&HASH_SIZE-1，但是一旦这样做就会出现匹配链成环的现象
解决方案：匹配次数不超过255次
2.压缩文件开头内容需要对文件后缀进行写入，在写入时，信息文件并没有填入，所以解压缩时，文件出现乱码
解决方案：解压缩时，文件指针对压缩文件头部进行读取，但不对标记信息进行读取
3.对于一个文件中，在解压缩时会中文大部分出现乱码，英文有少部分
解决方案：解压缩时，遇到距离长度对的时候，每解压缩一个字节，都需要刷新一次缓冲区，因为后面的数据中可能有此次解压的字节
Huffman过程：
1.编译的时候： 刚开始写的时候测试发现如果压缩文件中出现了中文，程序就会崩溃，最后发现是数组越界的错误，因为如果只是字符，它的范围是-128~127，程序中使用char类型为数组下标(0~127)，所以字符没有问题. 但是汉字的编码是两个字节，所以可能会出现越界，
解决方法：就是将char类型强转为unsigned char，下标可表示范围为0~255.
2.解压缩的时候 有些特殊字符在处理需要注意一下，比如'\n'，我的程序中Getline()函数就是读取一行字符，但是若是该字符本身就是一个'\n'呢？ 这就非常的棘手了. 因为解压缩之后出现了乱码
解决方法：读取压缩文件时若读到了'\n',则说明该字符就是'\n'，应该继续读取它的次数
3.运行的时候： 发现文件篇幅很长的时候，只能压缩和解压缩一部分，是因为字符长度的设定太小
解决方法：_count长度设为unsigned long long类型
测试方面： 1.对于txt文件压缩率还可以，但是对于音频和视频方面压缩率较低 2.为了压缩率，时间复杂度优点高
压缩率
| 文件类型 |源文件大小 |压缩后大小 |压缩率 | -------- | -------- | -------- | | txt文档|27.8KB | 12.5KB |0.45 |音频文件|29.8 MB|31.9MB|1.07 |视频文件|20.7MB|22.1MB|1.06
项目代码：https://github.com/wake5up/My-c--code/tree/master/compress
