Binær vs. ASCII filstørrelse

Hvis din eneste bekymring er filstørrelse, vil du ha binære filer. For et illustrerende eksempel, kan vi anta at du skriver 1 flytende punktnummer med dobbel presisjon til en fil. La oss anta at filsystemet kan håndtere dette perfekt og holde filen, overskrifter og polstring alle 0.

For en binær fil, ville dette tallet ta den nøyaktige størrelsen på tallet i RAM eller 8 byte.

I ASCII-format vil det inneholde:

• 16 sifre i basen
• 1 periode for desimalen
• 1 tegn for å avgrense eksponenten
• 1 tegn for eksponentens tegn
• 2-3 tegn for eksponenten

Forutsatt den bruker bare 1 byte for et tegn, det vil si 22 byte for å ha det samme tallet. Dette teller ikke de tegnene som kreves for å skille mellom tallene (vanligvis minst 1). Derfor vil filstørrelsen for ASCII-format være omtrent 3 ganger større.

Du kan bytte inn filstørrelse for presisjonen i de lagrede filene (bare ha 5-6 sifre i basen), men det avhenger av hva du bruker dem til. Den viktigste fordelen med ASCII er for feilsøking eller produksjon av lesbare data.

Kommentarer

• Også viktig på det vitenskapelige området er langsiktig arkivering og pålitelig deling, og til tross for at ‘ er ineffektivitet, er ASCII CSV så utbredt og anbefales (PDF) .
• Et annet nyttig poeng er at selv om ASCII CSV-koding ikke er ‘ t veldig effektiv, bruker du et filkomprimeringsverktøy (som zip, gzip, etc.) på ascii filen vil vanligvis bringe filstørrelsen ned til noe som ligner størrelsen på en binær fil.
• Vær forsiktig fordi noen inndata / utdatabiblioteker ikke er ‘ t nøye nok for å få litt reproduserbarhet når du sender ut IEEE Double Precision-tall i ASCII og deretter leser dem tilbake. Etter min erfaring er det noen ganger nødvendig å bruke 17 eller 18 desimaltegn for sikkerhet.
• Når det gjelder horchler ‘ s kommentar: Jeg ‘ er sikker på at velbrukte, standardiserte åpne binære formater som HDF5 vil være i lang tid. At ‘ er det jeg ‘ personlig anbefaler.
• + Jeg holder meg til binær når det er mulig, for nøyaktighet, kompaktitet, sjelefred og (spesielt) hastighet. Så hvis jeg trenger ytterligere kompakthet, kan jeg gli det. Hvis jeg trenger å kunne lese innholdet visuelt, kan jeg skrive et lite program for det. På den annen side, hvis det ‘ er viktigere å være visuell, og lett overføres til tilfeldige programmer som Excel, R osv., Så er CSV veien å gå.

I praksis trenger du sjelden data i visualiseringsfiler som er mer nøyaktige enn for eksempel 3 gyldige I så fall er ASCII – kanskje overraskende – ofte mer kompakt enn binær form. Hvis du tenker på å arkivere, vil sannsynligvis bzip -ing av disse ASCII-filene gi de minste filene du kan få.

Når det er sagt, leser Paraview VTU-format som har en komprimert binær form (XML-basert, men dataene blir først libz-komprimert og deretter uu-kodet igjen for å gi ASCII-tekst). På typiske filer sparer dette en faktor på 4-10. For store filer er dette absolutt veien å gå.

Kommentarer

• Jeg stemte dette opp for kontrasten til det andre svaret. Jeg har ikke ‘ uansett, men det er ‘ et godt poeng å få her.
• Alternativt kan du eksplisitt nullstille de lave bitene og komprimere den binære.
• Wow, det vil kreve ganske litt fiddling. Eller er det funksjoner som gjør det? (Annet enn å kaste for å flyte og tilbake til dobbelt.)

tl; dr – lagre filer i utf8 . Hvis det er i tabell, bruk TAB-atskilte verdier.

Det ser ut til at de riktige alternativene er:

1. utf8 tekst ( ikke ASCII . Vi er ikke alle amerikansk engelsktalende)
2. binær

ASAICT er den eneste reelle fordelen med binære filer ytelse. Det er mye raskere å laste en minnedump i minnet enn å generere tekst på vei ut eller analysere den på vei inn.

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

Eller her: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Dette er ikke vitenskapelig, og diskuterer den generelle ytelsen, hvor de store forskjellene er mengden overførte data og analyseringstiden i en sak som er partisk mot tekstdata. )

Sjansene for at et binært filformat vil støtte unicode-tekst riktig er dårlig, så Hvis du bryr deg om dataintegritet, ikke bruk binær . Har du også hørt om endianproblemer? Ulike binære representasjoner av signerte heltall og floater?

Tekstrepresentasjoner på -100000 og -1e + 6 endrer ikke verdi avhengig av på CPUen din (i det minste i utf-8 og ASCII).

Sjansene for at et program som forstår en binær fil fremdeles vil forstå det eller fortsatt kjøre 50 år fra nå er ukjent, sannsynligvis ikke bra . Hvis du bryr deg om lang levetid, bruk ikke binær .

Det er ofte vanskelig å lese binære data fra et annet program, så Hvis du bryr deg om interoperabilitet, ikke bruk binær .

Bortsett fra: CSV er et forferdelig filformat . Det er enkelt, men likevel dårlig definert og krever en stateful parser. Ikke bruk CSV. Hvis du må, bruk TSV. Det er enklere, men bedre definert og trivielt å analysere.

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

Hvis du er bekymret for størrelsen, komprimerer du .

(Jeg kom hit og lette etter studier av den relative størrelseseffektiviteten til komprimert binær representasjon vs. komprimert tekst. Jeg har fremdeles ikke funnet god informasjon bortsett fra denne studien om VRML, men jeg er ikke engang sikker på om det er en sammenligning av base64-kodet binær vs. binær. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)