字节流解压
A. 字节流与字符流有什么区别
字节流与字符流有2点不同，相关介绍具体如下：
一、两者的组成不同：
1、字节流的组成：字节流是由字节组成的。
2、字符流的组成：字符流是由字符组成的。
二、两者的处理不同：
1、字节流的处理：主要用在处理二进制数据，它是按字节来处理的但实际中很多的数据是文本。
2、字符流的处理：按虚拟机的encode来处理，也就是要进行字符集的转化。
(1)字节流解压扩展阅读：
字节流的其他介绍：
字节流由视频服务器向用户计算机顺序或实时传送。在采用流式传输方式的系统中，用户不必像采用下载方式那样等到整个文件全部下载完毕；
而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备对压缩的3D等多媒体文件解压后进行播放和观看。此时多媒体文件的剩余部分将在后台的服务器内继续下载。
B. RLE压缩是怎么回事啊
RLE压缩及优化
简单的说RLE压缩就是将一串连续的相同数据转化为特定的格式达到压缩的目的。
下面都对byte流压缩。
如输入数据
LPBTE pByte={1,1,1,1,1,1};
压缩的数据为6,1
压缩了4个字符。
但是在数据流里面不能直接这么替换，而应该使用特殊的控制字符，否则无法解压。
比如pByte={6,1,0,1,1,1,1,1,1};
这样有两个6,1无法判断是原有的6,1还是{1,1,1,1,1,1}压缩后的代码猜隐大。
所以应该有控制字符。
(1)
为了达到最大压缩率，可携汪以先扫描源数据流，使用最少出现的字符做控制字符。
如 pByte={6,1,0,1,1,1,1,1,1,...};
扫描后发现0为最少出现的字符。
我们使用0作为压缩的控制，其他字符代表他本身。源数据里面的0,用0,0来表示。
那么pByte压缩后为
6,1,0,0,0,6,1 ......
解压时 BYTE a,b,c;
a=依次扫描压缩数据，如果输入字符为非控制字符，则直接输出到解压流。
如果为控制字符，b=其下一字符是否也为控制字符，如果是，在输出流输出控制字符的代码。
如果不是c=读压缩流，然后输出b个c到输出流。
注意:该处对于>Ctrlcode 的编码需要自己计算偏移.
如ctrl=2.那么n=3时应该修正为2.
刚才介绍的方法是最大压缩率的，但是因为对每个输入字符需要检查，速度不算快。
(2)
为了增加解压速度，可以采用其他的编码方式。
主要方法是不对每个输入字符进行检查，只检查较少次就达到几乎相同的压缩率。
来看看这个改进的方法。
仔细观察，其实对不重复的字符也穗竖可以用控制n+数据的方式表示。这里的n带表n个未压缩数据。
还是刚才的数据。
pByte={6,1,0,1,1,1,1,1,1}
不用扫描选择0为控制
压缩为3,{6,1,0,} 0, 6, 1
n ctrl n m
解压就非常方便了
扫描数据读一个字符，
{
n=read;
if(n)
{
字符拷贝n个
}
else
{
n=read();
m=read;
write (n个m);
}
}
(3)优化
对(1)的优化。
观察得知，1,1,1这样的数据压缩率为0,
所以当n<=3时不用压缩。
而直接写为1,1,1样的格式。
另外如果有多个控制字符连续。也可以压缩。
观察ctrl=0;
0,0,0,0
如果用控制编码为8个0
而压缩编码为0,4,0 所以控制字符连续两个即可压缩。
对(2)：
只对压缩编码优化。
例
1,2,3,4,1,1
如果死套公式，为
4,1,2,3,4,0,2,1
反倒增加2个字节。
如果用
6,1,2,3,4,1,1只增加一个字节。
C. 深入浅出lz4压缩算法
lz4是目前综合来看效率最高的压缩算法，更加侧重压缩解压速度，压缩比并不是第一。在当前的安卓和苹果操作系统中，内存压缩技术就使用的是lz4算法，及时压缩手机内存以带来更多的内存空间。本质上是时间换空间。
lz4压缩算法其实很简单，举个压缩的栗子
其中两个括号内的便代表的是压缩时检测到的重复项，(5,4) 代表向前5个byte，匹配到的内容长度有4，即"bcde"是一个重复。当然也可以说"cde"是个重复项，但是根据算法实现的输入流扫描顺序，我们取到的是第一个匹配到的，并且长度最长的作为匹配。
压缩后的数据是下面的格式
其他情况也可能有连续的匹配：
Literals 指没有重复、首次出现的字节流，即不可压缩的部分
Match 指重复项，可以压缩的部分
Token 记录literal长度，match长度。作为解压时候memcpy的参数
可以想到，如果重复项越多或者越长，压缩率就会越高。上述例子中"bcde"在压缩后，用(5,4)表示，即从4个bytes压缩成了3个bytes来表示，其中offset 2bytes, match length 1byte，能节省1个byte。
大致流程，压缩过程以至少4个bytes为扫描窗口查找匹配，每次移动1byte进行扫描，遇到重复的就进行压缩。
由于offset用2bytes表示，只能查找到到2^16(64kb)距离的匹配，对于压缩4Kb的内核页，只需要用到12位。
扫描的步长1byte是可以调整的，即对应LZ4_compress_fast机制，步长变长可以提高压缩解压速度，减少压缩率。
我们来看下 apple的lz4实现
压缩理解了其实解压也很简单
根据解压前的数据流，取出token内的length，literals直接复制到输出，即memcpy(src,dst,length)
遇到match，在从前面已经拷贝的literals复制到后面即可