Binäre vs. ASCII-Dateigröße

Wenn Ihre einzige Sorge die Dateigröße ist, möchten Sie Binärdateien. Nehmen wir als anschauliches Beispiel an, Sie schreiben 1 Gleitkommazahl mit doppelter Genauigkeit in eine Datei. Nehmen wir an, dass das Dateisystem dies perfekt handhaben kann und die Datei, die Header und das Auffüllen alle 0 sind.

Für eine Binärdatei würde diese Zahl die genaue Größe der Zahl im RAM annehmen. oder 8 Bytes.

Im ASCII-Format würde es Folgendes enthalten:

• 16 Stellen der Basis
• 1 Punkt für die Dezimalzahl
• 1 Zeichen zur Begrenzung des Exponenten
• 1 Zeichen für das Vorzeichen des Exponenten
• 2-3 Zeichen für den Exponenten

Angenommen Es wird nur 1 Byte für ein Zeichen verwendet. Das sind 22 Byte, um dieselbe Nummer zu speichern. Dies zählt nicht die Zeichen, die zum Dilimitieren zwischen Zahlen erforderlich sind (normalerweise mindestens 1). Daher ist die Dateigröße für das ASCII-Format etwa dreimal so groß.

Sie können die Dateigröße gegen die Genauigkeit der gespeicherten Dateien eintauschen (behalten Sie nur 5-6 Stellen in der Basis bei), aber das hängt davon ab, was Sie verwenden sie für. Der Hauptvorteil von ASCII besteht in der Fehlerbehebung oder Erstellung von lesbaren Daten.

Kommentare

• Ebenfalls wichtig im wissenschaftlichen Bereich ist die langfristige Archivierung und Zuverlässigkeit Teilen, weshalb ASCII CSV trotz der Ineffizienzen von ‚ so weit verbreitet ist und empfohlen (PDF) .
• Ein weiterer nützlicher Punkt ist, dass die ASCII-CSV-Codierung ‚ nicht sehr effizient ist, wenn Sie ein Dienstprogramm zur Dateikomprimierung (wie zip, gzip usw.) auf Ihrem ASCII verwenden Durch eine Datei wird die Dateigröße normalerweise auf eine Größe reduziert, die der Größe einer Binärdatei ähnelt.
• Seien Sie vorsichtig, da einige Eingabe- / Ausgabebibliotheken ‚ nicht vorsichtig genug sind Um Bit-für-Bit-Reproduzierbarkeit zu erhalten, während Sie IEEE Double Precision-Zahlen in ASCII ausgeben und dann wieder einlesen. Nach meiner Erfahrung ist es aus Sicherheitsgründen manchmal erforderlich, 17 oder 18 Dezimalstellen zu verwenden.
• In Bezug auf horchler ‚ s Kommentar: Ich ‚ bin mir sicher, dass es gut verwendete, standardisierte offene Binärformate wie HDF5 noch lange geben wird. Das ‚ ist das, was ich ‚ persönlich empfehlen würde.
• + Ich halte mich aus Gründen der Genauigkeit, wann immer möglich, an die Binärdatei. Kompaktheit, Seelenfrieden und (besonders) Geschwindigkeit. Wenn ich dann weitere Kompaktheit benötige, kann ich sie mit einem Reißverschluss schließen. Wenn ich den Inhalt visuell lesen muss, kann ich dafür ein kleines Programm schreiben. Wenn es andererseits ‚ wichtiger ist, visuell zu sein und leicht an zufällige Programme wie Excel, R usw. weitergegeben zu werden, ist CSV der richtige Weg.

In der Praxis benötigen Sie selten Daten in Visualisierungsdateien, die genauer sind als beispielsweise 3 gültig In diesem Fall ist ASCII – vielleicht überraschend – oft kompakter als die Binärform. Wenn Sie über die Archivierung nachdenken, führt das Bzipen dieser ASCII-Dateien wahrscheinlich zu den kleinsten Dateien, die Sie erhalten können.

Das heißt, Paraview liest das VTU-Format, das eine komprimierte Binärform hat (XML-basiert, aber die Daten werden zuerst libz-komprimiert und dann erneut uuencodiert, um ASCII-Text zu erhalten). Bei typischen Dateien spart dies einen Faktor von 4-10. Bei großen Dateien ist dies definitiv der richtige Weg.

Kommentare

• Ich habe dies für den Kontrast zur anderen Antwort gewählt. Ich id id = „176282109a“>

tl; dr – speichert Dateien in utf8 . Wenn es tabellarisch ist, verwenden Sie TAB-getrennte Werte.

Es scheint mir, dass die richtigen Optionen sind:

1. utf8 Text ( nicht ASCII . Wir sprechen nicht alle amerikanisches Englisch)
2. binär

ASAICT Der einzige wirkliche Vorteil von Binärdateien ist die Leistung. Es ist viel schneller, einen Speicherauszug in den Speicher zu laden, als auf dem Weg nach draußen Text zu generieren oder auf dem Weg nach innen zu analysieren.

z. https://www.cfd-online.com/Forums/openfoam/136983-binary-gives-significant-performance-advantage-mesh-solve.html

Oder hier: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Dies ist nicht wissenschaftlich und diskutiert die Gesamtleistung, wobei die großen Unterschiede in der Menge der übertragenen Daten und der Analysezeit in einem auf Textdaten ausgerichteten Fall bestehen. )

Die Wahrscheinlichkeit, dass ein Binärdateiformat Unicode-Text ordnungsgemäß unterstützt, ist gering. Wenn Sie sich für die Datenintegrität interessieren, verwenden Sie kein binäres . Haben Sie auch von Endian-Problemen gehört? Verschiedene binäre Darstellungen von vorzeichenbehafteten Ganzzahlen und Gleitkommazahlen?

Textdarstellungen von -100000 und -1e + 6 ändern den Wert nicht abhängig auf Ihrer CPU (jedenfalls in utf-8 und ASCII).

Die Wahrscheinlichkeit, dass ein Programm, das eine Binärdatei versteht, diese noch versteht oder in 50 Jahren noch ausgeführt wird, ist unbekannt, wahrscheinlich nicht gut . Wenn Sie Wert auf Langlebigkeit legen, verwenden Sie keine binären .

Es ist oft schwierig, Binärdaten aus einem anderen Programm zu lesen. Wenn Sie Wert auf Interoperabilität legen, verwenden Sie keine Binärdaten .

Nebenbei: CSV ist ein schreckliches Dateiformat . Es ist einfach, aber schlecht definiert und erfordert einen Stateful Parser. Verwenden Sie kein CSV. Wenn Sie müssen, verwenden Sie TSV. Es ist einfacher, aber besser definiert und trivial zu analysieren.

https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/

https://www.cloudbakers.com/blog/everything-you-didnt-want-to-have-to-know-about-csv

Wenn Sie sich Sorgen um die Größe machen, komprimieren Sie .

(Ich habe hier nach Studien zur relativen Größeneffizienz der komprimierten binären Darstellung im Vergleich zur komprimierten gesucht Abgesehen von dieser Studie über VRML habe ich noch keine guten Informationen gefunden, bin mir aber nicht einmal sicher, ob es sich um einen Vergleich von Base64-codierter Binärdatei mit Binärdatei handelt. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)