Esiste un modo corretto per creare un formato di file?

Sto creando un formato di file proprietario per un'applicazione che ho scritto in C # .NET per archiviare informazioni di salvataggio e forse risorse del progetto. Esiste uno standard su come farlo in qualche modo? Stavo semplicemente andando ai Serializemiei oggetti in binario e creavo un'intestazione che mi avrebbe spiegato come analizzare il file. È un cattivo approccio?

Il metodo più diretto è probabilmente serializzare la struttura in XML usando la XMLSerializerclasse. Probabilmente non è necessario creare un'intestazione e una struttura del corpo separate, ma serializzare tutte le risorse in XML. Ciò consente di ispezionare / modificare facilmente la struttura dei file al di fuori del proprio programma ed è facilmente gestibile.

Tuttavia, se la struttura dei file è davvero complessa, contenente molte risorse diverse di tipi diversi, in modo tale che la serializzazione dell'intera struttura in XML sia troppo onerosa, è possibile esaminare la serializzazione di ciascuna risorsa separatamente e la loro compilazione in un singolo pacchetto utilizzando la Packaginglibreria in C # . Questo è essenzialmente il modo in cui sono costruiti .docx, .xslx, .pptx e altri formati di file di Office.

Da qualcuno che ha dovuto analizzare molti formati di file, ho opinioni su questo da un punto di vista diverso rispetto alla maggior parte.

• Rendi il numero magico univoco in modo che i rilevatori di formato di file delle persone per altri formati non lo identificino erroneamente come tuo. Se usi il binario, alloca 8 o 16 byte generati casualmente all'inizio di un formato binario per il numero magico. Se usi XML, alloca uno spazio dei nomi appropriato nel tuo dominio in modo che non possa scontrarsi con altre persone. Se usi JSON, dio ti aiuti. Forse qualcuno ha risolto una soluzione per quell'abominio di un formato ormai.

• Pianificare la compatibilità con le versioni precedenti. Memorizza il numero di versione del formato in qualche modo in modo che le versioni successive del tuo software possano gestire le differenze.

• Se il file può essere di grandi dimensioni o se ci sono sezioni che le persone potrebbero voler saltare per qualche motivo, assicurati che ci sia un buon modo per farlo. XML, JSON e la maggior parte degli altri formati di testo sono particolarmente terribili per questo, perché costringono il lettore a analizzare tutti i dati tra l'elemento iniziale e quello finale anche se non gli interessano. EBML è in qualche modo migliore perché memorizza la lunghezza degli elementi, permettendoti di saltare fino alla fine. Se si crea un formato binario personalizzato, esiste un design abbastanza comune in cui si memorizza un identificatore di blocco e una lunghezza come prima cosa nell'intestazione, quindi il lettore può saltare l'intero blocco.

• Memorizza tutte le stringhe in UTF-8.

• Se ti interessa l'estensione a lungo termine, archivia tutti i numeri interi in un formato a lunghezza variabile.

• I checksum sono utili perché consentono al lettore di interrompere immediatamente i dati non validi, anziché potenzialmente passare a sezioni del file che potrebbero produrre risultati confusi.

Bene, ci sono volte che ciò che descrivi può essere un pessimo approccio. Questo presuppone che quando si dice "serializza" si sta parlando dell'abilità di un linguaggio / framework di prendere semplicemente un oggetto e inviarlo direttamente a una sorta di flusso binario. Il problema è che le strutture di classe cambiano nel corso degli anni. Sarai in grado di ricaricare un file creato in una versione precedente dell'app se tutte le tue classi cambiano in una nuova?

Per la stabilità a lungo termine di un formato di file, ho trovato meglio rimboccarmi le maniche un po 'ora e in particolare scrivere i tuoi metodi di "serializzazione" / "streaming" all'interno delle tue classi. vale a dire, gestire manualmente la scrittura di valori in un flusso. Scrivi un'intestazione mentre dichiari che descrive la versione del formato, quindi i dati che desideri vengano salvati nell'ordine in cui li desideri. Sul lato di lettura, gestire diverse versioni del formato del file diventa molto più semplice.

L'altra opzione ovviamente è XML o JSON. Non necessariamente il massimo per i contenuti binari pesanti, ma semplice e leggibile dall'uomo ... un grande vantaggio per la fattibilità a lungo termine.

Vorrei anche piacerebbe sentire le risposte a questa domanda da parte di persone con gli anni più esperienza di me stesso.

Ho implementato personalmente diversi formati di file per il mio lavoro e sono passato all'utilizzo di un formato di file XML. I miei requisiti e hardware con cui interagisco cambiano continuamente, e non si può dire cosa dovrò aggiungere al formato in futuro. Uno dei principali vantaggi di XML è che è semi-strutturato . Per questo motivo, in genere evito la serializzazione XML automatica fornita da .NET perché credo che lo costringa ad aspettarsi un formato esatto.

Il mio obiettivo era quello di creare un formato XML che consentisse di aggiungere nuovi elementi e attributi in futuro e che l'ordine dei tag non importasse quando possibile. Se sei sicuro di poter caricare l'intero file in memoria, XPATH è probabilmente una buona scelta.

Se hai a che fare con file particolarmente grandi, o per altri motivi non puoi caricare il file tutto in una volta, allora probabilmente ti rimane con l'uso di un XmlStreamReader e la scansione di elementi noti e la ricorrenza in quegli elementi con ReadSubtree e la scansione di nuovo ...