¿Hay una manera adecuada de crear un formato de archivo?

Estoy creando un formato de archivo patentado para una aplicación que escribí en C # .NET para almacenar información guardada y tal vez los activos del proyecto. ¿Hay alguna norma sobre cómo hacer esto de alguna manera? Simplemente iba a Serializemis objetos en binario y creaba un encabezado que me diría cómo analizar el archivo. ¿Es este un mal enfoque?

El método más directo es probablemente serializar su estructura a XML utilizando la XMLSerializerclase. Probablemente no necesite crear una estructura de encabezado y cuerpo separada, sino serializar todos los activos en XML. Esto le permite inspeccionar / editar fácilmente su estructura de archivos fuera de su propio programa, y ​​es fácilmente manejable.

Sin embargo, si la estructura de su archivo es realmente compleja, contiene muchos activos diferentes de diferentes tipos, de modo que serializar toda la estructura a XML es demasiado oneroso, puede considerar serializar cada activo por separado y compilarlos en un solo paquete usando la Packagingbiblioteca en C # . Esto es esencialmente cómo se construyen .docx, .xslx, .pptx y otros formatos de archivos de Office.

De alguien que ha tenido que analizar muchos formatos de archivo, tengo opiniones sobre esto desde un punto de vista diferente a la mayoría.

• Haga que el número mágico sea único para que los detectores de formato de archivo de otras personas no lo identifiquen erróneamente como suyo. Si usa binario, asigne 8 o 16 bytes generados aleatoriamente al comienzo de un formato binario para el número mágico. Si usa XML, asigne un espacio de nombres adecuado en su dominio para que no pueda entrar en conflicto con otras personas. Si usas JSON, que Dios te ayude. Quizás alguien ya haya resuelto una solución para esa abominación de un formato.

• Planifique la compatibilidad con versiones anteriores. Almacene el número de versión del formato de alguna manera para que las versiones posteriores de su software puedan lidiar con las diferencias.

• Si el archivo puede ser grande, o hay secciones de él que la gente quiera omitir por alguna razón, asegúrese de que haya una buena manera de hacerlo. XML, JSON y la mayoría de los otros formatos de texto son particularmente terribles para esto, porque obligan al lector a analizar todos los datos entre el elemento inicial y final, incluso si no les importa. EBML es algo mejor porque almacena la longitud de los elementos, lo que le permite saltar hasta el final. Si crea un formato binario personalizado, existe un diseño bastante común en el que almacena un identificador de fragmento y una longitud como lo primero en el encabezado, y luego el lector puede omitir todo el fragmento.

• Almacene todas las cadenas en UTF-8.

• Si le importa la extensibilidad a largo plazo, almacene todos los enteros en forma de longitud variable.

• Las sumas de verificación son buenas porque le permiten al lector abortar inmediatamente los datos no válidos, en lugar de entrar potencialmente en secciones del archivo que podrían producir resultados confusos.

Bueno, hay veces que lo que describe puede ser un enfoque muy malo. Esto se supone cuando dices 'serializar' que estás hablando de usar la capacidad de un lenguaje / marco para simplemente tomar un objeto y enviarlo directamente a algún tipo de flujo binario. El problema es que las estructuras de clase cambian con los años. ¿Podrás volver a cargar un archivo creado en una versión anterior de tu aplicación si todas tus clases cambian en una nueva?

Para la estabilidad a largo plazo de un formato de archivo, ahora me parece mejor remangarse un poco y escribir específicamente sus propios métodos de 'serialización' / 'transmisión' dentro de sus clases. es decir, manejar manualmente la escritura de valores en una secuencia. Escriba un encabezado como indica que describe la versión del formato, y luego los datos que desea guardar en el orden en que lo desea. En el lado de la lectura, manejar diferentes versiones del formato de archivo se vuelve mucho más fácil.

La otra opción, por supuesto, es XML o JSON. No necesariamente el mejor para contenido pesado binario, pero simple y legible para humanos ... una gran ventaja para la viabilidad a largo plazo.

También me encantaría escuchar las respuestas a esta pregunta de personas con años de experiencia más que yo.

Personalmente, he implementado varios formatos de archivo para mi trabajo, y he pasado a usar un formato de archivo XML. Mis requisitos y el hardware con el que interactúo cambian todo el tiempo, y no se sabe qué necesitaré agregar al formato en el futuro. Una de las principales ventajas de XML es que está semiestructurada . Por esta razón, generalmente evito la serialización XML automática que proporciona .NET porque creo que lo obliga a esperar un formato exacto.

Mi objetivo era crear un formato XML que permitiera agregar nuevos elementos y atributos en el futuro y que el orden de las etiquetas no importara siempre que fuera posible. Si está seguro de que puede cargar todo su archivo en la memoria, entonces XPATH es probablemente una buena opción.

Si está tratando con archivos particularmente grandes, o por otras razones no puede cargar el archivo de una sola vez, entonces probablemente se quede con un XmlStreamReader y escanee en busca de elementos conocidos y recurra a esos elementos con ReadSubtree y escanee nuevamente ...