Dimensiunea fișierului binar vs.ASCII

Dacă singura grijă este dimensiunea fișierului, atunci doriți fișiere binare. Pentru un exemplu ilustrativ, să presupunem că scrieți un număr cu virgulă mobilă de dublă precizie într-un fișier. Să presupunem că sistemul de fișiere poate rezolva acest lucru perfect și că țineți fișierul, antetele și căptușeala sunt toate 0.

Pentru un fișier binar, acel număr ar lua dimensiunea exactă a numărului din RAM, sau 8 octeți.

În format ASCII, ar conține:

• 16 cifre ale bazei
• 1 perioadă pentru zecimal
• 1 caracter pentru a delimita exponentul
• 1 caracter pentru semnul exponentului
• 2-3 caractere pentru exponent

Presupunând folosește doar 1 octet pentru un caracter, adică 22 de octeți pentru a deține același număr. Aceasta nu contează caracterele necesare pentru a dilimita între numere (de obicei cel puțin 1). Prin urmare, dimensiunea fișierului pentru formatul ASCII va fi de aproximativ 3 ori mai mare.

Puteți schimba dimensiunea fișierului pentru precizia fișierelor stocate (păstrați doar 5-6 cifre în bază), dar asta depinde de ce le folosiți pentru. Principalul avantaj al ASCII este pentru depanarea sau producerea de date lizibile de către om.

Comentarii

• De asemenea, important în arena științifică este arhivarea pe termen lung și fiabilitatea partajare, motiv pentru care, în ciuda ineficiențelor ‘, ASCII CSV este atât de răspândit și recomandat (PDF) .
• Un alt punct util este că, deși codificarea ASCII CSV nu este ‘ t foarte eficientă, folosind un utilitar de compresie a fișierelor (cum ar fi zip, gzip etc.) pe ascii fișierul va reduce dimensiunea fișierului la ceva similar cu dimensiunea unui fișier binar.
• Aveți grijă, deoarece unele biblioteci de intrare / ieșire nu sunt suficient de atente ‘ pentru a obține reproductibilitatea biților pentru biți pe măsură ce scoateți numerele IEEE Double Precision în ASCII și apoi le citiți din nou. Din experiența mea, folosirea a 17 sau 18 cifre zecimale este uneori necesară pentru siguranță.
• În ceea ce privește horchler ‘ s comentariu: Sunt ‘ sigur că formatele binare deschise standardizate, bine folosite, precum HDF5, vor fi prezente mult timp. ‘ este ceea ce ‘ recomand personal.
• + Rămân la binar ori de câte ori este posibil, pentru acuratețe, compactitate, liniște sufletească și (în special) viteză. Apoi, dacă am nevoie de compacitate suplimentară, o pot fermifica. Dacă trebuie să pot citi vizual conținutul, pot scrie un mic program pentru asta. Pe de altă parte, dacă este ‘ mai important să fii vizual și să treci ușor către programe aleatorii precum Excel, R etc., atunci CSV este calea de urmat.

În practică, rareori aveți nevoie de date în fișierele de vizualizare care să fie mai precise decât, să zicem, 3 valide cifre. În acest caz, ASCII este – poate surprinzător – adesea mai compact decât forma binară. Dacă vă gândiți la arhivare, atunci bziparea acestor fișiere ASCII va produce probabil cele mai mici fișiere pe care le puteți obține.

Acestea fiind spuse, Paraview citește formatul VTU care are o formă binară comprimată (bazată pe XML, dar datele sunt mai întâi comprimate libz și apoi uuencodificate din nou pentru a produce text ASCII). Pe fișierele tipice, acest lucru economisește un factor de 4-10. Pentru fișierele mari, acesta este cu siguranță calea de urmat.

Comentarii

• Am votat acest lucru pentru contrastul cu celălalt răspuns. ‘ nu am o părere puternică în niciun fel, dar ‘ este un punct bun care trebuie avut aici.
• Ca alternativă, zero în mod explicit biții mici și comprimați binarul.
• Uau, asta ar necesita destul de puțin. Sau există funcții care fac asta? (Altele decât aruncarea pentru a pluti și a reveni la dublu.)

tl; dr – stochează fișiere în utf8 . Dacă este tabelar, utilizați valori separate de TAB.

Mi se pare că opțiunile corecte sunt:

1. utf8 text ( nu ASCII . Nu suntem toți vorbitorii de engleză americană)
2. binar

ASAICT, singurul avantaj real al fișierelor binare este performanța. „Este mult mai rapid să încărcați o memorie în memorie decât să generați text la ieșire sau să-l analizați la intrare.

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

Sau aici: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Acest lucru nu este științific și discută despre performanța generală, diferențele mari fiind cantitatea de date transmise și timpul de analiză într-un caz orientat spre date textuale. )

Șansele ca un format de fișier binar să accepte text unicode sunt slabe, deci dacă vă pasă de integritatea datelor, nu utilizați binar . Ați auzit, de asemenea, despre problemele endiene? Diferite reprezentări binare ale numerelor întregi și flotante semnate?

Reprezentările text ale -100000 și -1e + 6 nu modifică valoarea în funcție de pe CPU (în utf-8 și ASCII, în orice caz).

Șansele ca un program care înțelege un fișier binar să îl înțeleagă sau să ruleze în continuare peste 50 de ani sunt necunoscute, probabil că nu sunt bune . Dacă vă pasă de longevitate, nu utilizați binar .

Este adesea greu să citești date binare dintr-un alt program, deci dacă îți pasă de interoperabilitate, nu folosi binar .

În afară de: CSV este un format de fișier teribil . Este simplu, dar nu este bine definit și necesită un analizor de stare. Nu folosiți CSV. Dacă trebuie, utilizați TSV. Este mai simplu, dar mai bine definit, și banal de analizat.

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

Dacă vă îngrijorează dimensiunea, comprimați .

(Am venit aici în căutarea de studii privind eficiența relativă a dimensiunii reprezentării binare comprimate vs. text. Încă nu am găsit informații bune în afară de acest studiu despre VRML, dar nici măcar nu sunt sigur dacă este o comparație între codul bazat pe codul binar și cel binar. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)