In che modo tipi di file diversi generalmente memorizzano i dati?

Question

In che modo tipi di file diversi generalmente memorizzano i dati?

#1 da (7 voti)

-1

Sto lavorando a un progetto, per il quale voglio creare il mio formato di file per archiviare grandi quantità di dati. Sto cercando di decidere come deve essere costruito quel formato di file per essere il più efficiente possibile.

I dati che voglio memorizzare sono fondamentalmente una grande struttura dati.

L'idea che sto attualmente esaminando è la memorizzazione dei dati in un modo simile a una combinazione di XML e python. Ad esempio:

<Object1>
    <InnerObject1>
        <InnerInnerObject1>
            variable1 = 31415
            variable2 = "Hello World!!!"
        </InnerInnerObject1>
    </InnerObject1>
    <InnerObject2>
        variable1 = "abcd"
        variable2 = 17
    </InnerObject2>
</Object1>

, dove i tag corrispondono ai nomi delle classi e le variabili alle variabili.

Considerando i requisiti di tempo dei parser XML, non sono sicuro che la memorizzazione dei dati in questo modo consentirebbe una lettura abbastanza veloce.

La mia domanda è essenzialmente la seguente: esattamente come funzionano gli altri formati di file che memorizzano quantità significative di dati, ad esempio MP4 o OBJ? E non sto parlando della compressione o qualcosa del genere, ma del modo esatto in cui i dati vengono archiviati, in modo tale che il programma di lettura sappia quali dati mettere in memoria.

Grazie per l'aiuto in anticipo!

data-structures xml file-storage parsing file-formats

posta zomnombom 22.09.2017 - 16:54

fonte

1 risposta

Leggi altre domande sui tag data-structures xml file-storage parsing file-formats

Gli errori della console del browser 'errori del compilatore', 'errori di runtime' o nessuno dei due? Ho appena usato una dichiarazione goto. Va bene? [chiuso]

score 7 · Accepted Answer

La ragione per cui esistono molti formati di file diversi è che ci sono molti obiettivi diversi per il modo in cui i dati sono formattati. Alcuni di questi sono in opposizione l'uno all'altro e alcuni sono ortogonali tra loro. Prima di poterlo fare, devi determinare quali obiettivi desideri raggiungere.

Direi che la prima e più importante decisione è la leggibilità umana rispetto alla dimensione del file. Questi due obiettivi sono grosso modo in opposizione l'uno con l'altro. Con la leggibilità umana, intendo che puoi prendere un editor di testo di base e comprendere i dati. Quello che hai mostrato sopra cadrà nella classificazione altamente leggibile e molto voluminosa. Un esempio all'altra estremità di questo spettro, è qualcosa di simile a Avro .

Quando parli di cose come MP4, questo è un formato specializzato che è completamente non leggibile e progettato per dimensioni estremamente ridotte rispetto alla quantità di dati che contengono. È molto specializzato in quanto dipende dalla realtà che nel video, quasi ogni frame è molto simile a quello che è venuto prima. Per il testo, come nel tuo esempio, questo non è generalmente il caso.

IMO, XML è un ottimo formato per i documenti (ad esempio XHTML) ma uno molto scarso per il trasferimento dei dati. Questo sembra essere un consenso più o meno generale in quanto le persone si stanno muovendo di più su cose come JSON. Non è l'unica ragione, ma è un fattore.

Se vuoi prendere in considerazione l'intera specifica XML, è piuttosto difficile scrivere un parser a causa della sua discendenza da SGML. La maggior parte delle persone non userà mai o incontrerà la maggior parte delle cose pazze che avresti bisogno di supportare per essere in grado di analizzare qualsiasi file XML valido. La roba comune sarebbe facile. JSON è molto facile da analizzare, relativamente parlando.

Scrivere una specifica e un parser per un formato non leggibile dall'uomo non è necessariamente più difficile. Potrebbe anche essere utile per imparare di più sulle strutture dei dati, ecc.