2013-03-24 198 views
-2

我想在iPhone應用中使用zlib將文本文件壓縮爲gzip文件作爲測試。我使用下面的代碼Zlib壓縮放大文件

const char *s = [[Path stringByReplacingOccurrencesOfString:[NSString stringWithFormat:@".%@", [Path pathExtension]] withString:@".gz"] UTF8String]; 
gzFile *fi = (gzFile *)gzopen(s, "wb"); 
const char *c = readFile(Path.UTF8String); 
gzwrite(fi, c, strlen(c)); 
gzclose(fi); 

其中readFile()返回從使用fgets()函數的文件獲得const char*。問題是,當我使用它來壓縮文件時,它不會壓縮它,而是gzip文件比原始文件大。例如,我有一個90字節的文本文件,使用此方法後,gzip的大小爲98字節。爲什麼不是gzip比原始文件小?

+2

任何類型的zip壓縮將添加一個頭來標識格式並提供一個文件名和其他整體結構。對於小文件來說,這種開銷完全可能比壓縮節省更大。 – 2013-03-24 02:59:34

+0

壓縮零大小的文件以查找開銷。 – 2013-03-24 03:10:33

+0

@pst我考慮在我的評論中加入這一點,但由於它不適用於這個特定情況,我認爲這只是噪音。文本幾乎總是可壓縮的。 – 2013-03-24 03:31:26

回答

5

GZip格式包含固定大小的頭信息。由於您壓縮的數據太少,標題信息比您保存的空間大。

90字節通常不值得壓縮。

http://www.gzip.org/zlib/rfc-gzip.html#header-trailer

+0

是的,我剛剛測試,這就是爲什麼該文件是如此之小。在增加尺寸後,它確實變小了。 – 2013-03-24 03:06:28

1
  1. 您要壓縮的數據太小,沒有很多冗餘的,所以沒有什麼留下來壓縮。通過消除數據中的重複序列,壓縮算法的工作非常簡單。在90個字節中,您可能沒有太多冗餘,除非它是像"aaaaaaa...."這樣的文本。
  2. 固定的頭部開銷,如前所述。

嘗試一個更大的數據文件。

2

無論使用哪種壓縮算法,總會有產生的數據比輸入大的可能性,否則將不可能對任何輸入比特模式的組合進行編碼。

正如您在特例中已經指出的,與頭部開銷相比,文件大小非常小似乎是問題所在。

儘管如此,請記住,從來沒有保證「壓縮」文件的大小會更小。