3 回答

TA貢獻(xiàn)1842條經(jīng)驗(yàn) 獲得超22個(gè)贊
無(wú)論是什么壓縮“BQAAAB + LC”的“Hello”都是gzipper特別差的實(shí)現(xiàn)。它擴(kuò)展了“Hello”遠(yuǎn)遠(yuǎn)超過(guò)必要的范圍,使用動(dòng)態(tài)塊而不是deflate格式的靜態(tài)塊。刪除gzip流的四字節(jié)前綴(始終以hex 1f 8b開(kāi)頭)后,“Hello”擴(kuò)展為123字節(jié)。在壓縮世界中,這被視為犯罪。
您抱怨的Compress方法正常且正常。它生成一個(gè)靜態(tài)塊,總輸出為25個(gè)字節(jié)。gzip格式具有10字節(jié)頭和8字節(jié)尾部開(kāi)銷(xiāo),使得5字節(jié)輸入已經(jīng)被編碼為7個(gè)字節(jié)。這還差不多。
不可壓縮的流將被擴(kuò)展,但它不應(yīng)該太多。對(duì)于不可壓縮數(shù)據(jù),gzip使用的deflate格式將為每16K到64K增加5個(gè)字節(jié)。
為了獲得實(shí)際的壓縮,通常你需要為壓縮器提供更多的工作來(lái)處理這五個(gè)字節(jié),這樣它就可以在可壓縮數(shù)據(jù)中找到重復(fù)的字符串和有偏差的統(tǒng)計(jì)數(shù)據(jù)。我知道你只是用短字符串進(jìn)行測(cè)試。但是在實(shí)際應(yīng)用中,你永遠(yuǎn)不會(huì)使用具有這種短字符串的通用壓縮器,因?yàn)榘l(fā)送字符串總是更好。

TA貢獻(xiàn)1852條經(jīng)驗(yàn) 獲得超1個(gè)贊
我在我的項(xiàng)目中嘗試了你的代碼,并在Android上的compress方法中發(fā)現(xiàn)了一個(gè)編碼錯(cuò)誤:
byte[] blockcopy = ByteBuffer
.allocate(4)
.order(java.nio.ByteOrder.LITTLE_ENDIAN)
.putInt(str.length())
.array();
ByteArrayOutputStream os = new ByteArrayOutputStream(str.length());
GZIPOutputStream gos = new GZIPOutputStream(os);
gos.write(str.getBytes());
在上面的代碼中,你應(yīng)該使用更正的編碼,并填充字節(jié)長(zhǎng)度,而不是字符串長(zhǎng)度:
byte[] data = str.getBytes("UTF-8");
byte[] blockcopy = ByteBuffer
.allocate(4)
.order(java.nio.ByteOrder.LITTLE_ENDIAN)
.putInt(data.length)
.array();
ByteArrayOutputStream os = new ByteArrayOutputStream( data.length );
GZIPOutputStream gos = new GZIPOutputStream(os);
gos.write( data );
- 3 回答
- 0 關(guān)注
- 575 瀏覽
添加回答
舉報(bào)