位元組流解壓
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復制到後面即可