Sto costruendo un formato di file proprietario per un'applicazione che ho scritto in C # .NET per archiviare le informazioni di salvataggio e, forse, le risorse del progetto. C'è uno standard su come farlo in qualche modo? Stavo semplicemente andando a Serialize dei miei oggetti in binario e ho creato un'intestazione che mi dicesse come analizzare il file. È un approccio sbagliato?
Il metodo più diretto è probabilmente serializzare la struttura in XML usando XMLSerializer classe. Probabilmente non sarebbe 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 del file al di fuori del proprio programma ed è facilmente gestibile.
Tuttavia, se la struttura del file è davvero complessa, contenente molte risorse diverse di tipi diversi, in modo tale che serializzare l'intera struttura in XML è troppo oneroso, è possibile considerare la serializzazione di ciascuna risorsa separatamente e compilarle in un unico pacchetto utilizzando il Packaging libreria in C #. Questo è essenzialmente il modo in cui vengono creati .docx, .xslx, .pptx e altri formati di file office.
Da qualcuno che ha dovuto analizzare molti formati di file, ho opinioni su questo da un altro punto di vista.
Rendi il numero magico davvero unico in modo che i rilevatori di formati di file delle persone per altri formati non lo identificano erroneamente come il tuo. Se si utilizza il binario, allocare 8 o 16 byte generati casualmente all'inizio di un formato binario per il numero magico. Se si utilizza XML, allocare uno spazio dei nomi appropriato nel dominio in modo che non possa scontrarsi con altre persone. Se usi JSON, che dio ti aiuti. Forse qualcuno ha già risolto una soluzione per questo abominio di un formato.
Pianifica la compatibilità all'indietro. Memorizza in qualche modo il numero di versione del formato in modo che le versioni successive del software possano gestire le differenze.
Se il file può essere di grandi dimensioni o se ci sono sezioni che potrebbero essere saltate per qualche motivo, assicurati che ci sia un buon modo per farlo. XML, JSON e molti 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 gliene importa nulla. 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 una struttura abbastanza comune in cui si memorizzano un identificatore di blocco e una lunghezza come prima cosa nell'intestazione, quindi il lettore può saltare l'intero blocco.
Archivia tutte le stringhe in UTF-8.
Se ti preoccupi dell'estensibilità a lungo termine, archivia tutti gli interi in un formato a lunghezza variabile.
I checksum sono piacevoli perché consentono al lettore di interrompere immediatamente i dati non validi, invece di passare potenzialmente a sezioni del file che potrebbero produrre risultati confusi.
Bene, ci sono volte in cui ciò che descrivi può essere un approccio pessimo. Ciò presuppone che quando si dice "serializzare" si stia parlando dell'utilizzo dell'abilità di un linguaggio / struttura per prendere semplicemente un oggetto e produrre direttamente in 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 della tua app se tutte le tue classi cambiano in una più nuova?
Per la stabilità a lungo termine di un formato di file, ho trovato meglio rimboccarsi le maniche un po 'e scrivere in modo specifico i propri metodi di "serializzazione" / "streaming" all'interno delle classi. vale a dire, gestire manualmente la scrittura di valori in un flusso. Scrivi un'intestazione mentre dichiari che descrive la versione del formato e quindi i dati che desideri vengano salvati nell'ordine in cui desideri. Per quanto riguarda la lettura, gestire diverse versioni del formato di file diventa molto più semplice.
L'altra opzione, ovviamente, è XML o JSON. Non necessariamente il massimo per il contenuto pesante binario, ma semplice e leggibile dall'uomo ... un grande vantaggio per la redditività a lungo termine.
Vorrei anche amare per ascoltare le risposte a questa domanda di persone con anni di esperienza in più rispetto a me.
Ho personalmente implementato diversi formati di file per il mio lavoro e mi sono trasferito a utilizzare un formato di file XML. Le mie esigenze e l'hardware con cui interagisco cambiano continuamente, e non c'è modo di dire cosa avrò bisogno di 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é ritengo che imponga di aspettarsi un formato esatto.
Il mio obiettivo era creare un formato XML che consentisse l'aggiunta di 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 riesci a caricare il file tutto in una volta, probabilmente ti verrà lasciato usare XmlStreamReader e scansionerai elementi conosciuti e ricorsivi in quegli elementi con ReadSubtree e scansionerai di nuovo .. .
Leggi altre domande sui tag c# .net file-structure