2009-01-10 207 views
0

我知道有很多免費的,沒有那麼自由的壓縮庫,但對於我正在開發的項目,我需要能夠從流中獲取文件數據並將其放入某種壓縮或打包文件,但沒有壓縮,因爲我需要快速訪問這些文件,而不必等待它們解壓縮。創建不帶壓縮的zip文件

任何人都知道如何處理這個問題,或者如果有一些圖書館這樣做,我不知道?

+0

不要過早優化:基準減壓是否實際增加了大量開銷。 – Piskvor 2009-01-10 13:59:28

回答

9

您可以使用Zip爲此。你可以使用像「none」或「store」這樣的壓縮級別,它只是在不壓縮的情況下合併文件。 This site列舉其中一些:

  • 最大 - 最慢的 壓縮選項,但對於創建小檔案最 有用。
  • 正常 - 默認值。
  • 低 - 比默認快,但 效果不好。
  • 最小值 - 非常快的 壓縮,但不如 其他方法的效率。
  • - 創建一個ZIP文件,但確實 不壓縮它。如果存檔爲 加密或進行自解壓縮,則文件大小可能爲 稍大。

這裏有一些C#示例:

爲UNIX不知道,這正是tar一樣。當您看到.tar.gz文件時,它只是將一堆文件合併爲一個tar文件,然後通過gzip運行。

1

Windows下的傳統簡單存儲文件是cabinet文件,它支持壓縮以及簽名,zip不支持。

看看如果在.net中創建cabinet文件的方法。

7

查看System.IO.Packaging命名空間。從MSDN

引用:

System.IO.Packaging程序

提供可支持的多個數據對象的存儲 在單個 容器類。

包是可以被 用於組織對象到定義的物理格式 爲了便攜和高效 訪問的 單個實體的抽象類。

ZIP文件是Package的主要物理格式 。其他軟件包 的實現可能使用其他 物理格式,例如XML 文檔,數據庫或Web服務。

你可以爲你的包選擇不同compression options

  • NotCompressed - 壓縮關閉。
  • 正常 - 壓縮針對尺寸和 性能之間的平衡進行了優化。
  • 最大值 - 壓縮優化爲 大小。
  • 快速 - 壓縮優化爲 的性能。
  • SuperFast - 壓縮針對高性能進行了優化。
+0

哇,我剛剛學到了一些東西......我以前不知道這個命名空間。 +1 – 2009-01-10 16:47:43

4

也許只是使用壓縮設置爲「無」的zip; SharpZipLib就足夠了。

要小心假設壓縮速度較慢,但​​ - 它實際上可能會(視情況)是更快與壓縮,因爲你減少物理IO和IPC(通常是一個瓶頸)的量,並簡單做多一點CPU工作;但你通常有足夠的CPU。

1

請記住首先進行簡介。你的硬盤比你的CPU或RAM要慢很多。如果文件坐在磁盤上讀取較小的文件,壓縮文件比讀取未壓縮的文件塊花費的時間少。差異可能比解壓縮它的時間要多。

此外操作系統可能會緩存文件在內存中。當發生這種情況時,硬盤將完全從循環中移除(對您來說透明)。這可能會導致減壓時間過於昂貴。

我在處理緩慢的互聯網連接時學會了這種「技巧」。客戶需要快速的數據,而且我們有充足的週期。發送壓縮數據包會增加應用程序的吞吐量/延遲。

0

我有一個額外的要求,生成的包文件可以瀏覽標準工具(至少FAR管理器)。

到目前爲止,我已經試過:

  • OPC(開放式打包約定,System.Packaging命名空間,ZIP爲主,後端爲MSO的.docx文件)。內置和標準的,但很慢,可能是因爲它實際上首先將所有數據複製到臨時位置,以防它必須被壓縮(即使不是這樣),然後才寫入最終目的地。難以忍受的緩慢。請注意,還有一個不是基於.NET的Windows內置實現,可能會更快,但不會涵蓋我必須支持的所有操作系統版本。

  • ITSS(InfoTech存儲系統,CHM文件的後端)。內置在Windows中,有點標準。令人驚訝的是,這個實現並不完整,而且速度非常慢,甚至比OPC還要慢。

  • DOC(COM複合文件結構化存儲,後端用於MSO .doc文件,.msi文件等)。內置在Windows中,非常標準。不支持超過32個字符的文件名,這在我的情況下是一個重大缺陷。對於小到中等大小(完全超過.NET OPC impl),速度足夠快,但是在達到千兆字節時會出現一些可擴展性問題。

各種ZIP實現仍有待測試。