Bináris és ASCII fájlméret

Írnom kell egy számításból származó adatokat, amelyeket később a Paraview (.vtu vagy vtk fájl) olvas el.

Ha a fájlméretről van szó, akkor az ASCII vagy a bináris formátumot kell választanom?

Válasz

Ha az egyetlen gond a fájlméret, akkor bináris fájlokat szeretne. Szemléltető példaként tegyük fel, hogy 1 dupla pontosságú lebegőpontos számot írsz egy fájlba. Tegyük fel, hogy a fájlrendszer ezt tökéletesen tudja kezelni, és a fájl, a fejlécek és a kitöltés mind 0.

Bináris fájl esetén ez a szám pontosan a RAM méretét veszi fel, vagy 8 bájt.

ASCII formátumban a következőket tartaná:

  • az alap 16 számjegye
  • 1 pont a tizedesig
  • 1 karakter a kitevő határolására
  • 1 karakter a kitevő jelére
  • 2-3 karakter a kitevő

Feltételezve csak 1 bájtot használ egy karakterhez, azaz 22 bájtot ugyanarra a számra. Ez nem számolja azokat a karaktereket, amelyek szükségesek a számok közötti dilimációhoz (általában legalább 1). Ezért az ASCII formátum fájlmérete körülbelül háromszor nagyobb lesz.

A fájlmérettel kereskedhet a pontosság érdekében a tárolt fájlokban (csak 5-6 számjegyet tartson az alapban), de ez attól függ, hogy arra használod őket. Az ASCII fő előnye az ember által olvasható adatok hibakeresése vagy előállítása.

Megjegyzések

  • A tudományos színtéren szintén fontos a hosszú távú archiválás és megbízható megosztás, éppen ezért ‘ hatékonysága ellenére az ASCII CSV annyira elterjedt és ajánlott (PDF) .
  • Egy másik hasznos szempont, hogy bár az ASCII CSV kódolás nem ‘ nem túl hatékony, fájltömörítő segédprogramot (például zip, gzip stb.) használ az ascii-n A fájl általában a bináris fájl méretéhez hasonlóra csökkenti a fájl méretét.
  • Legyen óvatos, mert egyes bemeneti / kimeneti könyvtárak ‘ nem eléggé óvatosak hogy megkaphassuk a bitek reprodukálhatóságát, amikor IEEE Double Precision számokat adunk ki az ASCII-ben, majd visszaolvassuk őket. Tapasztalataim szerint a biztonság érdekében néha 17 vagy 18 tizedesjegy használata szükséges.
  • Horchler ‘ s megjegyzés: Én ‘ biztos vagyok benne, hogy a jól használt, szabványosított nyílt bináris formátumok, mint például a HDF5, sokáig rendelkezésre állnak. ‘ amit személyesen ajánlok ‘.
  • + A bináris lehetőségekhez ragaszkodom, amikor csak lehetséges, a pontosság érdekében, tömörség, nyugalom és (különösen) gyorsaság. Aztán ha további tömörségre van szükségem, akkor cipzárral zárhatom. Ha vizuálisan el kell tudnom olvasni a tartalmat, írhatok ehhez egy kis programot. Másrészt, ha ‘ fontosabb, hogy vizuális legyen, és könnyen átadható olyan véletlenszerű programoknak, mint az Excel, R stb., Akkor a CSV a megfelelő út.

Válasz

A gyakorlatban ritkán van szükség olyan adatokra a vizualizációs fájlokban, amelyek pontosabbak, mint mondjuk 3 érvényes számjegy. Ebben az esetben az ASCII – talán meglepő módon – gyakran kompaktabb, mint a bináris forma. Ha az archiválásra gondol, akkor ezeknek az ASCII fájloknak a bzip-beírása valószínűleg a lehető legkisebb fájlokat fogja eredményezni.

A Paraview elolvassa a VTU formátumot, amelynek tömörített bináris formája van (XML-alapú, de az adatokat először libz-formátumban tömörítik, majd újra kódolják, hogy ASCII szöveget kapjanak). A tipikus fájlokon ez 4-10-es tényezőt takarít meg. Nagy fájlok esetében ez mindenképpen a helyes út.

Megjegyzések

  • Ezt a másik válasz ellentétére szavaztam. Nincs ‘ egyik oldalon sem erős véleményem, de ‘ jó szempont lehet itt.
  • Alternatív megoldásként kifejezetten nullázzuk az alacsony biteket, és tömörítsük a bináris fájlokat.
  • Hűha, ehhez meglehetősen kevés fikázásra lenne szükség. Vagy vannak olyan funkciók, amelyek ezt csinálják? (Az úszás és a kettős visszaállítás kivételével.)

Válasz

tl; dr – fájlokat tárol az utf8 fájlban. Ha táblázatos, akkor használja a tabulátorral elválasztott értékeket.

Számomra úgy tűnik, hogy a megfelelő beállítások a következők:

  1. utf8 szöveg ( nem ASCII . Nem vagyunk minden amerikai angolul beszélők)
  2. bináris

ASAICT a bináris fájlok egyetlen igazi előnye a teljesítmény. Sokkal gyorsabban be lehet tölteni egy memóriakiírást a memóriába, mint a kifelé vezető úton szöveget generálni, vagy a belépéskor elemezni.

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

Vagy itt: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Ez nem tudományos, és az általános teljesítményt tárgyalja, a nagy különbségek a továbbított adatok mennyisége és a szöveges adatok felé torzított elemzési idő között vannak. )

Az esély, hogy egy bináris fájlformátum megfelelően támogatja az unicode szöveget, gyenge, ezért ha az adatok integritása érdekli, ne használja a bináris . Hallottál már endian problémákról is? Az aláírt egész számok és lebegők különböző bináris ábrázolása?

-100000 és -1e + 6 szövegábrázolása nem változtat értéket a CPU-n (mindenképp az utf-8 és az ASCII fájlokban).

Az esélye, hogy egy bináris fájlt értő program még mindig meg fogja érteni, vagy 50 év múlva is fut, ismeretlen, valószínűleg nem jó . Ha érdekel a hosszú élettartam, ne használja a bináris .

Gyakran nehéz elolvasni egy másik program bináris adatait, ezért ha fontos az interoperabilitás, ne használja a bináris .

Mellékül: A CSV egy rettenetes fájlformátum . Ez egyszerű, de rosszul definiált és állapotfájl-elemzőt igényel. Ne használjon CSV-t. Ha szükséges, használja a TSV-t. Egyszerűbb, de jobban meghatározható, és elemzése csekély.

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

Ha aggódsz a méret miatt, tömörítsd a tömörítést.

(Ide a tömörített bináris ábrázolás és a tömörítés relatív mérethatékonyságát vizsgáltam szöveg. A VRML vizsgálatán kívül még nem találtam jó információt, de még abban sem biztos, hogy összehasonlítja-e a base64 kódolású bináris és a bináris összehasonlítást. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)

Vélemény, hozzászólás?

Az email címet nem tesszük közzé. A kötelező mezőket * karakterrel jelöltük