10

I have a simulation that reads large binary data files that we create (10s to 100s of GB). We use binary for speed reasons. These files are system dependent, converted from text files on each system that we run, so I'm not concerned about portability. The files currently are many instances of a POD struct, written with fwrite.

I need to change the struct, so I want to add a header that has a file version number in it, which will be incremented anytime the struct changes. Since I'm doing this, I want to add some other information as well. I'm thinking of the size of the struct, byte order, and maybe the svn version number of the code that created the binary file. Is there anything else that would be useful to add?

4

12 に答える 12

7

大規模なバイナリの場合、私はHDF5（Googleの場合）を真剣に検討します。採用したいものではない場合でも、独自のフォーマットを設計する際に役立つ方向性を示す可能性があります。

于 2009-01-06T15:22:48.033 に答える
4

大きなバイナリの場合、バージョン番号に加えて、レコード数と CRC を付ける傾向があります。その理由は、大きなバイナリは、時間の経過や転送中に小さなバイナリよりも切り捨てられたり破損したりする傾向があるためです。最近、恐ろしいことに、Windows がこれをまったくうまく処理できないことに気付きました。エクスプローラーを使用して、接続された NAS デバイスに数百のファイルにわたって約 2TB をコピーしたところ、各コピーの 2 ～ 3 個のファイルが破損していることがわかりました (完全ではありません)。コピーされます）。

于 2009-01-06T13:20:42.430 に答える
3

それらがそれほど大きい場合は、ファイルの先頭に十分な容量 (64K?) のスペースを確保し、そこにメタデータを XML 形式で配置し、その後にファイルの終わり文字 (DOS の場合は Ctrl-Z/ Windows、UNIX の場合は ctrl-D?)。そうすれば、XML 用のさまざまなツールセットを使用して、メタデータを簡単に調べて解析できます。

それ以外の場合は、他の人がすでに言っていることを使用します。ファイル作成のタイムスタンプ、ファイルが作成されたマシンの識別子、基本的に診断目的で考えられるその他すべて。そして理想的には、構造フォーマット自体の定義を含めることです。構造を頻繁に変更している場合、古いデータファイルのさまざまな形式を読み取るために適切なバージョンのコードを維持するのは非常に面倒です。

@highpercomp が述べたように、HDF5 の大きな利点の 1 つは、名前とデータ型の規則がある限り、構造形式の変更について心配する必要がないことです。構造体の名前とデータ型はすべてファイル自体に格納されるため、C コードを粉々に吹き飛ばしても問題ありません。HDF5 ファイルからデータを取得することはできます。つまり、 HDF5の問題であるバイトのシーケンスは気にしませんが、フィールド名などは気にします。

私が HDF5 を気に入っているもう 1 つの理由は、圧縮を使用することを選択できることです。これは非常に短い時間で済み、データがゆっくりと変化する場合、またはいくつかの興味深い点を除いてほとんど同じである場合、ストレージ スペースを大幅に節約できます。

于 2009-01-06T16:17:19.453 に答える
3

ファイルのタイプの識別子は、後でバイナリ ファイルに他の構造を書き込む場合に役立ちます。おそらく、これは短い文字列である可能性があるため、(16 進エディターを使用して) ファイルを調べることで、その内容を確認できます。

于 2009-01-06T13:11:25.180 に答える
2

@rstevensは「ファイルの種類の識別子」と言いました...適切なアドバイス。慣習的に、これはマジック ナンバーと呼ばれ、ファイルでは乱用の用語ではありません (乱用の用語であるコードとは異なります)。基本的に、それはいくつかの数値です-通常は少なくとも4バイトであり、通常、それらのバイトの少なくとも1つがASCIIではないことを確認します-これを使用して、ファイルが期待するタイプであり、混乱する可能性が低いことを検証できます. /etc/magic (またはローカルの同等のもの) にルールを記述して、マジック ナンバーを含むファイルが特別なファイル タイプであることを報告することもできます。

ファイル形式のバージョン番号を含める必要があります。ただし、コードの SVN 番号を使用しないことをお勧めします。ファイル形式が変更されない場合、コードが変更される可能性があります。

于 2009-01-06T13:25:08.350 に答える
1

テレコム機器の構成とファームウェアのアップグレードに関する私の経験から、バージョン (ヘッダーの固定部分) から始まる最初 (これは重要です) にいくつかの事前定義されたバイトだけが実際に必要であることが示されています。ヘッダーの残りはオプションです。適切なバージョンを示すことで、いつでも処理方法を示すことができます。ここで重要なことは、ヘッダーの「変数」部分をファイルの最後に配置することです。ファイルの内容自体を変更せずにヘッダーの操作を計画している場合。また、これにより、変数ヘッダー部分を再計算する必要がある「追加」操作が簡素化されます。

固定サイズのヘッダーの機能があると便利です (最初に):

  • 共通の「長さ」フィールド (ヘッダーを含む)。
  • CRC32 のようなもの (ヘッダーを含む)。

OK、ヘッダーの可変部分 XML またはかなり拡張可能な形式は良い考えですが、本当に必要なのでしょうか? 私は ASN エンコーディングの経験が豊富でした...ほとんどの場合、その使用法は行き過ぎでした。

RFC 2126 (第 4.3 章)で説明されている TPKT 形式などを見れば、さらに理解が深まるかもしれません。

于 2013-04-19T06:32:02.923 に答える
1

スキーマのバージョン管理に必要な情報に加えて、問題のトラブルシューティングを行う場合に役立つ可能性のある詳細を追加します。例えば：

  • ファイルが作成および更新されたときのタイムスタンプ (該当する場合)。
  • ビルドからのバージョン文字列 (理想的には、すべての「公式」ビルドで自動インクリメントされるバージョン文字列があります...これはファイル スキーマ バージョンとは異なります)。
  • ファイルを作成するシステムの名前と、アプリに関連するその他の統計情報

これは、(a) そうでなければ顧客に提供を求めなければならない情報を入手するのに、また (b) 正しい情報を入手するのに非常に役立つことがわかりました。データクレーム！

于 2009-01-06T13:18:39.393 に答える
1

ファイルオフセットをヘッダーの固定位置に配置することを検討してください。これにより、ファイル内の実際のデータの開始位置がわかります。これにより、必要に応じてヘッダーのサイズを変更できます。

いくつかのケースでは、値 0x12345678 をヘッダーに挿入して、ファイル形式がそれを処理しているマシンのエンディアンと一致するかどうかを検出できるようにしました。

于 2009-01-06T16:03:10.870 に答える
0

ヘッダーにバージョン番号を入れている場合は、POD 構造体を変更したり、新しいフィールドをヘッダーに追加したりする必要があるときはいつでもそのバージョンを変更できます。

興味深いかもしれないので、今はヘッダーに何かを追加しないでください。維持する必要があるコードを作成しているだけですが、実際の価値はほとんどありません。

于 2009-01-06T13:12:06.457 に答える
0

大きなファイルの場合、データ定義を追加して、ファイル形式を自己記述型にすることができます。

于 2009-01-06T13:51:01.153 に答える