1

アプリケーション（C＃.NET Windowsアプリ）でデータをキャッシュするための単純なバイナリファイル形式があります。形式は基本的に短いもので、オブジェクトタイプの後に、オブジェクトIDのGUID（文字列）、オブジェクト固有のデータ（strings intsなど）が続きます。多くのオブジェクトを同じファイル（> 10000）に保存できるようにしたいのですが、特定の状況ではオンデマンドでのみロードされます。私たちが持っている解決策は、ファイル内のオブジェクトの場所のインデックスを保持することです-したがって、新しいオブジェクトの書き込みを開始すると、オブジェクトが開始するファイルストリーム内の位置を記録します。このオブジェクトをロードする場合は、このインデックス付きの場所を使用して関連データをロードします。これは正常に機能します。

ただし、ファイルを圧縮する場合でも、この方法は可能ですか？圧縮がどのように機能するか、特に使用する予定のGZipStreamクラス（System.IO.Compression）についてはあまり熱心ではありません。私が理解しているように、このクラスはSeekingまたはPositionプロパティをサポートしていません。基礎となるFileStreamのシークと位置を使用することはまだ可能ですか（私は推測していません）？基本的に、選択的にロードできる圧縮ファイルを作成することは可能ですか？その場合、どのように実行しますか？

ありがとう、

スティーブ

4

3 に答える 3

1

いいえ、非圧縮データの特定の位置にアクセスする場合は、少なくとも一時的にデータを解凍する必要があります

于 2010-05-07T10:17:11.417 に答える
1

これは真のシークではありませんが、解決策は次のようになります。

  • ファイル内の自分の位置を追跡します（おそらく、BinaryReaderから継承する「myBinaryReader」を実装することによって最もよく実行されます）
  • 現在の位置から前方の位置を探している場合-そこに到達するまでReadBytes。
  • 現在の位置より前の位置を探している場合-解凍された読み取り（現在の位置をゼロにリセットします）のためにファイルを再度開き、目的の場所に到達するまでReadBytesを開きます。

明らかに、これはまったく理想的なソリューションではありませんが、それでも許容できるパフォーマンスが得られる可能性があります。私の場合、圧縮ファイルはメモリ内に簡単に収まるので（非圧縮では収まりません）、圧縮ファイルをメモリにロードしました。

理想的には、基礎となるdeflateクラスは、真のシークをサポートするように変更されます。

于 2012-10-08T03:50:22.637 に答える
0

より良い解決策：

GZipStreamを使用してメモリ内に圧縮バイトを作成してから、独自のクラスを作成して、これのキャッシュとディスクへの書き込みを制御します（DeflateStreamは使用しないでください）。また、ディスクからこのデータを読み取るために、に独自のクラスを記述します。

次に、基盤となるディスクストリームがシークをサポートしていることを確認できます。

于 2012-10-15T08:55:12.717 に答える