2012-09-12 36 views
5

zip文件格式以中央目錄部分結尾,然後指向文件中的各個zip條目。這似乎允許zip條目發生在zip文件本身的任何地方。事實上,自解壓縮zip文件就是一個很好的例子:它們以可執行文件開頭,所有zip文件都在可執行字節之後發生。zip文件可以稀疏/不連續嗎?

的問題是:不壓縮文件格式,真正讓稀疏或不連續的拉鍊條目?例如如果在zip條目之間有空的或者其他不明的字節?權威PK筆記和維基百科文章似乎都允許這樣做。所有/最典型的壓縮實用程序是否可以使用這種稀疏的zip文件?

的使用情況是這樣的:我希望能夠刪除或zip文件中替換ZIP條目。要做到這一點,典型的minizip等圖書館希望你複製出整個zip文件,同時不復制刪除或替換的zip條目,這似乎浪費和緩慢。刪除或替換,你可以找出其中的未分配的字節數是直接使用這些條目中時,

豈不是更好的過度分配,說1.5倍的存儲的條目,然後呢?使用1.5倍的存儲空間意味着如果zip條目線性增長,重新分配也應該線性分攤。這可能與文件系統塊分配類似,但可能並不複雜。

這也有助於很多基於zip的文件格式。不必在臨時解壓文件的某個地方(甚至在內存中)使用某個臨時目錄來進行編輯/更改,然後不得不將這些文件重新壓縮成文件格式,這樣就不需要重新壓縮和重寫壓縮文件的某些部分文件。

是否有任何C/C++庫,在那裏,這樣做呢?

+1

是不是過度放置存儲類型打敗壓縮的目的? –

+0

壓縮文件不是動態存儲管理的最佳媒體。它是存檔的。將數據一起壓縮並完成。 –

+0

一些數據,例如英文文本或XML,可以壓縮到10倍。如果允許整個zip文件不被重寫,那麼僅分配超過0.5x的額外空間仍然值得。這種過度分配可以在API級別確定,以便例如已知不太可能增加尺寸的條目可以被分配足夠的空間。 –

回答

4

否。讀取中央目錄是可選的。 zip解碼器可以,也有一些可以從頭開始順序讀取zip文件,期望能夠連續查看本地頭文件和條目數據。他們可以完成解碼工作,從來沒有看過中央目錄。

爲了做到你想要什麼,你就需要把有用的條目之間的虛擬拉鍊條目以認爲空間。至少如果你想與其他zip世界兼容。

+0

什麼會在非連續的zip文件上運行這樣的zip解碼器(假設沒有虛擬zip條目)?如果解碼器按順序掃描zip文件中的zip條目幻數,然後對條目進行解碼以確定數據的真實時間,則看起來非連續的zip仍然是兼容的。關於唯一的警告就是我必須清空空白區域以防止迷路數字混淆解碼器。 –

+0

解碼器不搜索幻數。它期望它將看到的下一個東西是一個幻數,它表示它是本地標題,中央目錄標題還是結尾標題。如果它看到零,它將會以無效的格式錯誤停在那裏。 –

+0

最後,我編寫了我自己的Objective-C庫來進行重新編輯。它不會將zip條目視爲稀疏條目,但它會跳過寫出未更改的zip條目。所以如果你不斷地改變最後的幾個條目,你將不必爲從頭開始重寫所有條目而付費。 https://github.com/pixelglow/zipzap –