加載壓縮文件流的特定部分

Question

我們有一個簡單的二進制文件格式用於在我們的應用程序（C＃.NET Windows App）中緩存數據。格式基本上是一個簡短的短語，表示對象類型，後面跟着對象id的guid（字符串），然後是任何對象特定的數據（字符串整數）。我們希望能夠在同一個文件（> 10000）中存儲多個對象，但在某些情況下只能按需加載。我們的解決方案是保留文件中對象位置的索引 - 因此，當我們開始編寫新對象時，我們會記錄對象開始的文件流中的位置。當我們想要加載這個對象時，我們使用這個索引位置來加載相關數據。這工作正常。

但是，如果我們要壓縮文件，這種方法仍然有可能嗎？我對壓縮的工作方式不是太熱，特別是我們打算使用的GZipStream類（System.IO.Compression）。據我所知，這個類不支持Seeking或Position屬性。仍然有可能使用底層FileStream的搜索和位置（我猜不是）？基本上，是否有可能有一個壓縮文件，我們可以選擇加載，如果是的話，我們該怎麼做？

感謝，

史蒂夫

Answer 1

不，如果您要訪問的非壓縮數據中的特定位置，你將不得不解壓縮它，至少暫時

Answer 2

這是不是一個真正的尋求，但解決方案將是：

• 保持您的位置在文件中的軌道（可能通過實施從BinaryReader繼承的「myBinaryReader」最好）
• 如果您正在從當前位置向前尋找位置 - ReadBytes，直到您到達那裏。
• 如果您在當前位置之前尋找位置 - 重新打開解壓縮讀取文件（將當前位置重置爲零），然後ReadBytes，直到您到達想要的位置。

顯然這並不是理想的解決方案，但它仍然可以提供可接受的性能。 在我的情況下，壓縮文件很容易適應內存（未壓縮不），所以我已經將壓縮文件加載到內存中。

理想情況下，底層deflate類將被更改爲支持真正的Seeks。

Answer 3

一個更好的解決方案：

使用GZipStream創建內存中的壓縮字節，然後寫自己的類來控制這個磁盤緩存和寫（不使用DeflateStream）。另外編寫你自己的類來從磁盤讀取這些數據。

然後您可以確保底層磁盤流支持Seeks。