Binaire vs. ASCII-bestandsgrootte

Als je je alleen zorgen maakt over de bestandsgrootte, dan wil je binaire bestanden. Laten we voor een illustratief voorbeeld aannemen dat u 1 drijvende-kommagetal met dubbele precisie naar een bestand schrijft. Laten we aannemen dat het bestandssysteem dit perfect aankan en dat het bestand, de kopteksten en de padding allemaal 0 zijn.

Voor een binair bestand zou dat nummer de exacte grootte hebben van het nummer in RAM, of 8 bytes.

In ASCII-formaat zou het bevatten:

• 16 cijfers van de basis
• 1 punt voor het decimaalteken
• 1 char om de exponent af te bakenen
• 1 char voor het teken van de exponent
• 2-3 char voor de exponent

Ervan uitgaande het gebruikt slechts 1 byte voor een teken, dat is 22 bytes om hetzelfde nummer vast te houden. Dit telt niet de tekens die nodig zijn om tussen de nummers te verdunnen (meestal ten minste 1). Daarom zal de bestandsgrootte voor ASCII-indeling ongeveer 3 keer groter zijn.

U kunt de bestandsgrootte inruilen voor de precisie in de opgeslagen bestanden (bewaar alleen 5-6 cijfers in de basis), maar dat hangt af van wat u gebruikt ze voor. Het belangrijkste voordeel van ASCII is het opsporen van fouten of het produceren van door mensen leesbare gegevens.

Opmerkingen

• Ook belangrijk in de wetenschappelijke arena is archivering op lange termijn en betrouwbaar delen, en dat is de reden waarom, ondanks de ‘ s inefficiënties, ASCII CSV zo veel voorkomt en aanbevolen (PDF) .
• Een ander nuttig punt is dat hoewel ASCII CSV-codering niet ‘ t erg efficiënt is, het gebruik van een hulpprogramma voor bestandscompressie (zoals zip, gzip, enz.) op uw ascii bestand zal de bestandsgrootte meestal terugbrengen tot iets dat lijkt op de grootte van een binair bestand.
• Wees voorzichtig, want sommige invoer- / uitvoerbibliotheken zijn ‘ t niet voorzichtig genoeg om bit voor bit reproduceerbaarheid te krijgen terwijl je IEEE Double Precision-getallen uitvoert in ASCII en ze vervolgens weer inleest. In mijn ervaring is het gebruik van 17 of 18 decimale cijfers soms noodzakelijk voor de veiligheid.
• Betreffende horchler ‘ s opmerking: ik ‘ weet zeker dat veelgebruikte, gestandaardiseerde open binaire formaten zoals HDF5 nog lang zullen bestaan. Dat ‘ is wat ik ‘ persoonlijk aanbeveel.
• + Ik blijf waar mogelijk bij binair, voor nauwkeurigheid, compactheid, gemoedsrust en (vooral) snelheid. Als ik dan meer compactheid nodig heb, kan ik hem dichtritsen. Als ik de inhoud visueel moet kunnen lezen, kan ik daar een klein programma voor schrijven. Aan de andere kant, als het ‘ belangrijker is om visueel te zijn en gemakkelijk kan worden doorgegeven aan willekeurige programmas zoals Excel, R, etc., dan is CSV de juiste keuze.

In de praktijk heb je zelden gegevens nodig in visualisatiebestanden die nauwkeuriger zijn dan bijvoorbeeld 3 geldige cijfers. In dat geval is ASCII – misschien verrassend – vaak compacter dan binaire vorm. Als je aan archivering overweegt, zal het bzippen van deze ASCII-bestanden waarschijnlijk de kleinste bestanden opleveren die je kunt krijgen.

Dat gezegd hebbende, leest Paraview het VTU-formaat dat een gecomprimeerde binaire vorm heeft (XML-gebaseerd, maar de gegevens worden eerst libz-gecomprimeerd en vervolgens opnieuw gecodeerd om ASCII-tekst te verkrijgen). Op typische bestanden bespaart dit een factor 4-10. Voor grote bestanden is dit absoluut de juiste keuze.

Opmerkingen

• Ik heb dit gestemd vanwege het contrast met het andere antwoord. Ik heb in beide gevallen geen ‘ een uitgesproken mening, maar ‘ is hier een goed punt te vinden.
• Alternatief, expliciet de lage bits op nul zetten en het binaire bestand comprimeren.
• Wauw, dat zou nogal wat gehannes vereisen. Of zijn er functies die dat doen? (Anders dan casten om te zweven en terug naar dubbel.)

tl; dr – bestanden opslaan in utf8 . Als het in tabelvorm is, gebruik dan door TAB gescheiden waarden.

Het lijkt mij dat de juiste opties zijn:

1. utf8 tekst ( niet ASCII . We zijn niet allemaal Amerikaans-Engelse sprekers)
2. binair

ASAICT het enige echte voordeel van binaire bestanden is de prestatie. Het is veel sneller om een geheugendump in het geheugen te laden dan tekst te genereren op de weg naar buiten of deze tijdens de weg naar binnen te ontleden.

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

Of hier: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Dit is niet wetenschappelijk en bespreekt de algehele prestaties, met als grote verschillen de hoeveelheid verzonden gegevens en de parseertijd in een case die is gericht op tekstuele gegevens. )

De kans dat een binair bestandsformaat Unicode-tekst correct ondersteunt, is klein, dus als je om gegevensintegriteit geeft, gebruik dan geen binair . Heb je ook gehoord over endian-problemen? Verschillende binaire representaties van ondertekende gehele getallen en floats?

Tekstweergaven van -100000 en -1e + 6 veranderen niet van waarde afhankelijk op uw CPU (in ieder geval in utf-8 en ASCII).

De kans dat een programma dat een binair bestand begrijpt het nog steeds begrijpt of over 50 jaar nog draait, is onbekend, waarschijnlijk niet goed . Als u om een lang leven geeft, “gebruik dan geen binair div

Het is vaak moeilijk om binaire gegevens uit een ander programma te lezen, dus als je om interoperabiliteit geeft, gebruik dan geen binair .

Terzijde: CSV is een verschrikkelijk bestandsformaat . Het is eenvoudig, maar slecht gedefinieerd en vereist een stateful parser. Gebruik geen CSV. Gebruik TSV als het moet. Het is eenvoudiger maar beter gedefinieerd en eenvoudig te ontleden.

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

Als je je zorgen maakt over de grootte, comprimeer dan .

(Ik kwam hier op zoek naar studies over de relatieve grootte-efficiëntie van gecomprimeerde binaire representatie versus gecomprimeerde tekst. Ik heb naast dit onderzoek nog steeds geen goede informatie over VRML gevonden, maar ik weet niet eens zeker of het een vergelijking is van met base64 gecodeerd binair versus binair. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)