我不知道這是否會幫助你很多,作爲解決方案取決於您的需求,但我有項目我的工作(至少我是這麼認爲的),在那裏我有類似的問題將許多文章文章保存在驅動器中,並以相當隨機的方式訪問它們,並且由於數據量很大,我不得不壓縮它們。
一次壓縮所有這些數據的問題是,大多數算法在解壓縮時依賴於先前的數據。例如,流行的LZW方法在執行解壓縮時會在運行時創建adictionary(關於如何解壓縮數據的說明),所以不可能從中間解壓縮流,儘管我相信這些方法可能會被調整。
解決方案,我發現是工作最好的,但它確實減少你的壓縮比是塊打包數據。在我的項目中很簡單 - 每篇文章都是1塊,我將它們壓縮爲1,然後創建一個索引文件,保存每個「塊」開始的位置,在這種情況下,解壓縮很容易 - 只需解壓整個流即可我想要的文章。
所以,我的文件是這樣的:
Index; compress(A1); compress(A2); compress(A3)
,而不是
compress(A1;A2;A3)
。
如果你不能在這樣優雅的方式分割你的數據,你可以總是試圖人爲地分割塊,例如,在5MB塊包數據。所以當你需要讀取7MB到13MB的數據時,你只需要解壓縮5-10和10-15塊。 那麼你的索引文件看起來像:
0 -> 0
5MB -> sizeof(compress 5MB)
10MB -> sizeof(compress 5MB) + sizeof(compress next 5MB)
這種解決方案的問題是,它給略差的壓縮比。塊越小 - 壓縮越糟糕。
另外:有許多數據塊並不意味着你必須有硬盤驅動器不同的文件,剛剛收拾他們後,對方在一個文件中,並記住,當他們開始。
另外:http://dotnetzip.codeplex.com/是用於創建,您可以使用壓縮和寫在C#中的zip文件一個漂亮的圖書館。對我來說工作起來相當不錯,你可以使用其構建的功能在1個zip文件中創建許多文件,以便將數據拆分爲塊。
我在這裏看到的問題是,大多數壓縮算法不支持這種功能。因爲fe。解壓縮100-202需要先前的數據。如果是fe,你能否擴展你的問題?你知道未來將要解壓的原始文件的哪些部分?所以你確定,你會減壓100-202,而不是90-220?這可以幫助我想 –