Binaarinen vs. ASCII-tiedostokoko

Jos ainoa huolesi on tiedostokoko, haluat binääritiedostot. Oletetaan esimerkkinä, että kirjoitat tiedostoon yhden kaksinkertaisen tarkkuuden liukuluvun numeron. Oletetaan, että tiedostojärjestelmä pystyy käsittelemään tämän täydellisesti, ja tiedoston, otsikkojen ja täytteiden pitäminen ovat kaikki 0.

Binaaritiedostossa kyseinen numero vie tarkan määrän RAM-muistissa, tai 8 tavua.

ASCII-muodossa se mahtaisi:

• 16 numeroa perustaa
• 1 jakso desimaalille
• 1 merkki eksponentin rajaamiseksi
• 1 char eksponentin merkille
• 2-3 char eksponentille

Olettaen se käyttää vain 1 tavua merkille, eli 22 tavua pitämään samaa numeroa. Tämä ei laskea merkkejä, joita tarvitaan lukujen erottamiseen toisistaan (yleensä vähintään 1). Siksi ASCII-muodon tiedostokoko on noin 3 kertaa suurempi.

Voit vaihtaa tiedostokokoa tallennettujen tiedostojen tarkkuuden vuoksi (säilytä vain 5-6 numeroa kannassa), mutta se riippuu käytät niitä. ASCII: n tärkein etu on ihmisten luettavissa olevan tiedon virheenkorjaus tai tuottaminen.

Kommentit

• Tieteellisellä areenalla on tärkeää myös pitkäaikainen arkistointi ja luotettavuus jakaminen, minkä vuoksi ' tehottomuudesta huolimatta ASCII CSV on niin yleistä ja suositeltavaa (PDF) . tiedosto yleensä vähentää tiedoston koon samankaltaiseksi kuin binaaritiedoston koko.
• Ole varovainen, koska jotkut tulo- / lähtökirjastot eivät ole ' riittävän varovaisia saada bittiä bittitiedostojen toistettavuudeksi, kun syötät IEEE Double Precision -numeroita ASCII-muodossa ja luet ne sitten takaisin. Kokemukseni mukaan 17 tai 18 desimaalin tarkkuuden käyttäminen on joskus turvallisuuden kannalta välttämätöntä.
• Horchler ' s kommentti: Olen ' varma, että hyvin käytettyjä, standardoituja avoimia binaarimuotoja, kuten HDF5, on vielä pitkään. Tätä ' s mitä suosittelen henkilökohtaisesti. ' d.
• + Pysyn binaarista aina kun mahdollista tarkkuuden vuoksi, kompakti, mielenrauha ja (erityisesti) nopeus. Sitten, jos tarvitsen vielä pienikokoisuutta, voin vetää sen. Jos minun on pystyttävä lukemaan sisältö visuaalisesti, voin kirjoittaa siihen pienen ohjelman. Toisaalta, jos ' on tärkeämpää olla visuaalinen ja siirtää helposti satunnaisille ohjelmille, kuten Excel, R jne., CSV on oikea tapa edetä.

Käytännössä tarvitset harvoin visualisointitiedostoissa tietoja, jotka ovat tarkempia kuin esimerkiksi 3 kelvollista numeroita. Tällöin ASCII on – ehkä yllättävän – usein pienempi kuin binaarimuoto. Jos ajattelet arkistointia, näiden ASCII-tiedostojen bzip-pakkaus tuottaa todennäköisesti pienimmät tiedostot, joita saat.

Tästä huolimatta Paraview lukee VTU-muodon, jolla on pakattu binaarimuoto (XML-pohjainen, mutta data ensin pakataan libz-muodossa ja koodataan sitten uudestaan ASCII-tekstin tuottamiseksi). Tyypillisissä tiedostoissa tämä säästää kerrointa 4-10. Suurten tiedostojen kohdalla tämä on ehdottomasti oikea tapa edetä.

Kommentit

• Äänestin tämän vastauksen vuoksi toiseen vastaukseen. Minulla ei ' ole kumpaakaan vahvaa mielipidettä, mutta ' on hyvä asia olla täällä.
• Vaihtoehtoisesti nollata matalat bitit nimenomaisesti ja pakata binääritiedosto.
• Vau, se vaatii melko vähän bittilähtöä. Vai onko toimintoja, jotka tekevät sen? (Muu kuin heittäminen kellumaan ja takaisin kaksinkertaiseksi.)

tl; dr – tallentaa tiedostot utf8 . Jos se on taulukkomuotoinen, käytä sarkaimilla erotettuja arvoja.

Minusta tuntuu, että oikeat vaihtoehdot ovat:

1. utf8 teksti ( ei ASCII . Emme ole kaikki amerikkalaiset englanninkieliset)
2. binaarinen

ASAICT binaaritiedostojen ainoa todellinen etu on suorituskyky. Muistikannan lataaminen muistiin on paljon nopeampi kuin tekstin luominen ulosmenossa tai jäsentäminen tullessaan.

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

Tai tässä: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Tämä ei ole tieteellistä, ja siinä keskustellaan yleisestä suorituskyvystä, suurten erojen ollessa lähetetyn datan määrä ja jäsentämisaika tapauksessa, joka on puolueellinen kohti tekstidataa. )

Mahdollisuus, että binaaritiedostomuoto tukee kunnolla unicode-tekstiä, on huono, joten jos välität tietojen eheydestä, älä käytä binääristä . Oletko myös kuullut endian-ongelmista? Allekirjoitettujen kokonaislukujen ja kelluvien eri binaariset esitykset?

-100000: n ja -1e + 6: n tekstiesitykset eivät muuta arvoa suorittimellasi (joka tapauksessa utf-8: ssa ja ASCII: ssa).

Mahdollisuudet, että ohjelma, joka ymmärtää binaaritiedoston, silti ymmärtää sen tai toimii edelleen 50 vuoden kuluttua, on tuntematon, luultavasti ei hyvä . Jos välität pitkäikäisyydestä, älä käytä binaarista .

Binaaritietoja on usein vaikea lukea toisesta ohjelmasta, joten jos välität yhteentoimivuudesta, älä käytä binääriä .

Lisäksi: CSV on kauhea tiedostomuoto . Se on yksinkertainen, mutta määrittelemätön ja vaatii tilallisen jäsentimen. Älä käytä CSV: tä. Käytä tarvittaessa TSV: tä. Se on yksinkertaisempi, mutta paremmin määritelty ja triviaali jäsentää.

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

Jos olet huolissasi koosta, pakkaa .

(Tulin tänne etsimään tutkimuksia pakatun binääriesityksen suhteellisen koon tehokkuudesta pakattuun tekstiä. En ole vieläkään löytänyt hyvää tietoa tämän tutkimuksen lisäksi VRML: stä, mutta en ole edes varma, vertaako se base64-koodattua binaaria vs. binaaria. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)