Frage

Ich habe eine Simulation, die große binäre Datendateien liest, die wir (10s bis 100s von GB) erstellen. Wir verwenden aus Geschwindigkeitsgründen binär. Diese Dateien sind vom System abhängig, umgerechnet von Textdateien auf jedem System, das wir laufen, also bin ich nicht besorgt über Portabilität. Die Dateien sind zur Zeit viele Instanzen einer POD-Struktur, geschrieben mit fwrite.

Ich brauche die Struktur zu ändern, so möchte ich einen Header hinzufügen, die eine Dateiversionsnummer in sich hat, die jederzeit die Struktur Änderungen erhöht werden. Da ich das tue, möchte ich auch einige andere Informationen hinzuzufügen. Ich denke an die Größe der Struktur, Byte-Reihenfolge, und vielleicht die SVN Versionsnummer des Code, der die Binär-Datei erstellt. Gibt es noch etwas, die nützlich sein würde hinzufügen?

War es hilfreich?

Lösung

Nach meiner Erfahrung zweite Mutmaßung der Daten, die Sie benötigen, um Zeit immer verschwendet werden. Wichtig ist, zu strukturieren Ihre Metadaten in einer Weise, die erweiterbar ist. Für XML-Dateien, das ist einfach, aber Binär-Dateien erfordern ein wenig mehr Gedanken.

Ich neige dazu, Metadaten in einer Struktur zu speichern, am Ende der Datei, nicht am Anfang. Dies hat zwei Vorteile:

  • Verkürzte / ungekündigten Dateien leicht erkannt werden.
  • Metadaten Fußzeilen können oft an bestehende Dateien angehängt, ohne Auswirkungen auf ihren Lesecode.

Die einfachste Metadaten Fußzeile ich wie folgt aussieht etwas verwenden:

struct MetadataFooter{
  char[40] creatorVersion;
  char[40] creatorApplication;
  .. or whatever
} 

struct FileFooter
{
  int64 metadataFooterSize;  // = sizeof(MetadataFooter)
  char[10] magicString;   // a unique identifier for the format: maybe "MYFILEFMT"
};

Nach den Rohdaten, die Metadaten Fußzeile und dann die Datei Fußzeile geschrieben werden.

Wenn Sie die Datei zu lesen, zu Ende suchen - sizeof (FileFooter). Lesen Sie die Fußzeile, und überprüfen Sie die magicString. Dann suchen wieder nach metadataFooterSize und die Metadaten lesen. In Abhängigkeit von der Fußzeile Größe in der Datei enthalten ist, können Sie die Standardwerte für fehlende Felder verwenden.

Wie KeithB weist darauf hin, könnten Sie auch diese Technik verwenden, die Metadaten als XML-String zu speichern, die Vorteile zu geben sowohl vollständig erweiterbarer Metadaten, mit der Kompaktheit und Geschwindigkeit von binären Daten.

Andere Tipps

Für große Binärdateien würde ich (denn es Google) ernsthaft HDF5 suchen. Auch wenn es wollen, es zu verabschieden, nicht etwas, das Sie ist könnte man in einigen nützlichen Richtungen zeigen Sie Ihre eigenen Formate in der Gestaltung.

Für große Binärdateien, zusätzlich zu der Versionsnummer Ich neige dazu, eine Datenanzahl und CRC zu setzen, den Grund dafür ist, dass große Binärdateien sind viel anfälliger abgeschnitten und / oder beschädigt im Laufe der Zeit zu erhalten oder während der Übertragung als kleinere. Vor kurzem fand ich zu meinem Entsetzen, das Windows nicht das überhaupt gut umgehen kann, wie ich explorer über 2TB über ein paar hundert Dateien auf ein angeschlossenes NAS-Gerät zu kopieren verwendet und fand 2-3 Dateien auf jedes Exemplar beschädigt wurden (nicht vollständig kopiert).

Eine Kennung für die Art der Datei wäre nützlich, wenn Sie andere Strukturen werden später in binären Dateien geschrieben. Vielleicht könnte dies eine kurze Zeichenfolge, so dass Sie durch einen Blick in die Datei (über Hex-Editor) sehen können, was es enthält.

Wenn sie so groß, ich einen gesunden Brocken behalten würde (64K?) Platz am Anfang der Datei und legen Sie die Metadaten dort im XML-Format, gefolgt von einem End-of-Datei Zeichen (Strg-Z für DOS / Windows, ctrl-D für Unix?). Auf diese Weise können Sie für XML-Metadaten mit der breiten Palette von Toolset dort untersuchen und analysieren.

Ansonsten gehe ich mit dem, was andere Leute haben schon gesagt: Zeitstempel für Dateierstellung, Kennung für die Maschine auf erstellt wird, im Grunde alles, was Sie für diagnostische Zwecke denken. Und im Idealfall würden Sie die Definition der Struktur Format selbst umfassen. Wenn Sie die Struktur oft ändern, es ist ein großer Schmerz die richtige Version von Code zu pflegen um verschiedene Formate von alten Datendateien zu lesen.

Ein großer Vorteil von HDF5 als @highpercomp erwähnt hat, ist, dass Sie gerade nicht brauchen, um Veränderungen in der Struktur Format kümmern, solange Sie einige Konvention von dem, was die Namen und Datentypen sind. Die Strukturnamen und Datentypen sind alle in der Datei selbst gespeichert, so können Sie Ihren C-Code in tausend Stücke blasen und es spielt keine Rolle, Sie noch Daten aus einer HDF5 Datei abrufen können. Es lässt Sie machen sich weniger Sorgen über die Format von Daten und mehr auf die Struktur von Daten, dh ich über die Folge von Bytes nicht kümmern, das ist HDF5 das Problem, aber ich Sie kümmern sich um die Feldnamen und dergleichen.

Ein weiterer Grund, warum ich HDF5 mag, ist, Sie Komprimierung verwendet werden können wählen, die eine sehr geringe Menge an Zeit in Anspruch nimmt und Sie können sehr große Gewinne in Stauraum geben, wenn die Daten langsam ändernden oder meist die gleichen, außer für ein paar verirrten Blips von Interestingness.

@rstevens sagte ‚eine Kennung für die Art der Datei‘ ... fundierte Beratung. Herkömmlicherweise ist, dass eine magische Zahl, und in einer Datei mit dem Namen, kein Schimpfwort ist (anders als in Code, wo es ein Schimpfwort ist). Im Grunde ist es eine Zahl - in der Regel mindestens 4 Bytes, und ich sicher, in der Regel, dass mindestens eine dieser Bytes ASCII nicht -, dass Sie verwenden können, zu bestätigen, dass die Datei des Typs ist, dass Sie mit einer geringen Wahrscheinlichkeit erwarten verwirrt das Seins . Sie können auch eine Regel in / etc / magic (oder lokale äquivalent) schreiben zu können, dass Dateien Ihre magische Zahl sind Ihr spezieller Dateityp enthalten.

Sie sollten eine Dateiformat Versionsnummer enthalten. Allerdings würde ich empfehlen, die SVN-Nummer des Codes nicht verwendet wird. Der Code kann sich ändern, wenn das Dateiformat nicht.

Zusätzlich zu allen Informationen Sie Schema Versionierung benötigen, fügen Sie Details, die von Wert sein, wenn Sie ein Problem beheben möchten. Zum Beispiel:

  • Zeitstempel, wann die Datei erstellt wurde und Update (falls zutreffend).
  • die Versionszeichenfolge aus dem Build (idealerweise eine Version Zeichenfolge haben, die auf jeder ‚offiziellen‘ Auto erhöht wird, bauen ... das ist anders als die Dateischema Version).
  • der Name des Systems Erstellen der Datei, und vielleicht andere Statistiken, die für Ihre Anwendung relevant sind

Wir finden dies sehr nützlich ist, (a) in Informationen bekommen wir sonst die Kunden bitten, müssen zur Verfügung zu stellen und (b) korrekte Informationen bekommen - es ist erstaunlich, wie viele Kunden berichten, dass sie eine andere Version der Software ausgeführt werden zu dem, was die Daten Ansprüche!

Sie betrachten könnten eine Datei in einer festen Position in dem Kopfversatz setzen, die Sie sagt, wo die eigentlichen Daten in der Datei beginnt. Dies würde lassen Sie die Größe des Headers ändern, wenn nötig.

In ein paar Fällen habe ich den Wert 0x12345678 in den Kopf, so dass ich, wenn das Dateiformat erkennen, entsprach dem endianism der Maschine, die es verarbeitet wurde.

Wie meine Erfahrung mit Telekommunikationsgeräten Konfiguration und Firmware-Upgrades zeigt Sie nur wirklich mehr vordefinierte Bytes am beginnen müssen (das ist wichtig), die sie von Version beginnt (festen Teil des Header). Rest des Headers ist optional, durch die richtige Version anzeigt, dass Sie immer zeigen, wie es zu verarbeiten. Wichtig dabei ist, dass Sie ‚Variable‘ Teil-Header am Ende der Datei einen besseren Ort würde. Wenn Sie Operationen auf Kopf planen, ohne dabei selbst Dateiinhalt zu ändern. Auch diese Abläufe zu vereinfachen ‚anhängen‘, die variable Kopfteil neu berechnet werden sollte.

Nizza Funktionen für feste Größe Header haben (zu Beginn):

  • Allgemein 'Länge' Feld (einschließlich Header).
  • So etwas wie CRC32 (einschließlich Header).

OK, für variable Teil XML oder ein paar ziemlich erweiterbares Format in Header ist eine gute Idee, aber ist es wirklich nötig? Ich hatte viel Erfahrung mit ASN-Codierung ... in den meisten Fällen ihre Nutzung überschritten wurde.

Nun, vielleicht werden Sie zusätzliches Verständnis haben, wenn Sie an Dingen wie TPKT Format suchen, die in

Wenn Sie eine Versionsnummer im Header setzen können Sie diese Version, wann immer Sie brauchen ändern Sie die POD-Struktur zu ändern oder neue Felder der Kopfzeile hinzuzufügen.

So fügen Sie nicht Sachen in den Header jetzt, weil es interessant sein könnte. Sie erstellen nur Code, den Sie pflegen müssen, aber das hat wenig realen Wert.

Für große Dateien, können Sie Datendefinitionen hinzuzufügen, so dass Ihr Dateiformat wird selbsterklärend.

Meine Variation kombiniert Roddy und Jason S die Ansätze.

Zusammengefasst -. Setzen formatierten Text-Metadaten am Ende der Datei mit einer Art und Weise seiner Länge an anderer Stelle gespeichert, um zu bestimmen

1) Setzen Sie am Anfang der Datei ein Längenfeld, so dass Sie die Länge der Metadaten am Ende wissen, anstatt eine feste Länge angenommen. Auf diese Weise Sie die Metadaten zu bekommen habe gerade gelesen, dass mit fester Länge Anfangsfeld und dann von dem Ende der Datei, die Metadaten Klecks erhalten.

2) Verwenden Sie XML oder YAML oder JSON für die Metadaten. Dies ist besonders nützlich / sicher, wenn die Metadaten am Ende angehängt wird, weil niemand die Datei gelesen wird automatisch denken, es ist alles XML, nur weil es mit XML beginnt.

Der einzige Nachteil bei diesem Ansatz ist, wenn Ihre Metadaten wachsen Sie sowohl den Kopf der Datei und den Schwanzes zu aktualisieren, aber es ist wahrscheinlich, dass andere Teile werden auf jeden Fall aktualisiert wurden. Wenn es nur ist Trivia wie ein letztes Zugriffsdatum dann die Metadaten Länge wird mich nicht ändern, so dass es nur braucht ein Update an Ort und Stelle zu aktualisieren.

scroll top