¿Existe algún peligro al escribir bytes sin procesar en un archivo? [cerrado]

Estoy trabajando en un problema en Programming Pearls, específicamente, la implementación de un programa que clasifica un archivo que contiene, como máximo, 10,000,000 enteros (Columna 1, Problema 3). Dado que el libro no especifica cómo se deben almacenar los datos en el archivo, estoy considerando almacenar los enteros como bytes sin formato (existen otras restricciones que hacen que los bytes sin formato sean una buena opción). Nunca he trabajado en este nivel tan bajo antes, así que quiero saber si hay algo peligroso que deba tener en cuenta. ¿Debo preocuparme por utilizar accidentalmente algún tipo de secuencia de fin de archivo cuando escribo bytes sin formato en un archivo, por ejemplo?

Editar:

Ahora me doy cuenta de cuán amplia era mi pregunta. Realmente quise decir problemas del tipo más catastrófico, como sobrescribir accidentalmente otros archivos en el disco. Lo siento, no estaba más claro originalmente.

El único peligro con el que te encontrarás es pequeño contra gran endianess (si el byte más o menos significativo se escribe primero). Sin embargo, si permanece en el mismo entorno, no habrá problemas. Además de la garantía general de escritura / análisis de ida y vuelta.

El sistema de archivos está diseñado para manejar cualquier secuencia de bytes.

No, de hecho, así es como funcionan muchos formatos de archivo. Ejemplos comunes de archivos binarios como este incluyen imágenes y archivos de música / audio.

Para mantener la integridad del archivo y los datos leídos, asegúrese de seguir estas pautas:

• Siempre abra el archivo (lectura o escritura) usando el mismo modo: texto o binario. La principal diferencia es que el modo de texto se preocupa por las nuevas líneas y puede "cortar" los caracteres de las nuevas líneas al leer un archivo (dependiendo de la biblioteca específica que se utilice). El modo de texto también puede realizar traducciones Unicode que probablemente ahogarán los datos que no sean Unicode.
• Al leer datos que no son cadenas, asegúrese de leer con el mismo tipo de datos que escribe. Por ejemplo, si los primeros cuatro bytes del archivo son un número entero descriptivo, asegúrese de leer y escribir utilizando un método que tome / proporcione un número entero para garantizar que se trate de manera coherente. El mismo tipo de datos puede tener un tamaño diferente en diferentes máquinas, y mezclar tipos de datos en la misma máquina también puede cambiar el significado de los datos (por ejemplo, interpretar un bit en medio de un entero más largo como un bit de signo).
• Endianness: si la biblioteca que está utilizando no maneja esto de manera consistente, es posible que deba manejarlo usted mismo. Por ejemplo, Java siempre usa el orden de bytes de la red (big endian) para los tipos de varios bytes. C y C ++ usan lo que decida el implementador de la biblioteca, generalmente el mismo que el procesador (little endian en Intel, big endian en la mayoría de los demás). Si este es un ejercicio rápido en un sistema, no es tan importante, pero sigue siendo un buen hábito prestar atención a esto y codificarlo si es necesario.

Los detalles específicos variarán según el marco, la plataforma y el idioma, pero esto debería cubrir las "trampas" básicas con el archivo de E / S.

Además de todos los problemas ya mencionados, si está creando un nuevo formato de archivo binario en lugar de leer y escribir datos en un formato existente, es absolutamente vital que incluya un encabezado de archivo : un bloque de datos al principio del archivo que identifica inequívocamente el formato del archivo y registra los metadatos que puedan ser necesarios.

Los buenos encabezados de archivo incluyen al menos tres cosas:

• Un " número mágico ", de al menos cuatro bytes. El número mágico DEBE ^rfc2119 ser los primeros N bytes en el archivo, ^NO DEBE haber sido utilizado para ningún otro formato de archivo que pueda desenterrar, y DEBE contener al menos un byte que no sea un carácter ASCII imprimible. Consulte la especificación PNG para saber cómo diseñar un número mágico realmente completo . Vea el código fuente del file(1)comando para obtener una base de datos de números mágicos existentes que es tan completa como es probable que encuentre.

  El objetivo de un número mágico es etiquetar sin ambigüedad el archivo, en banda, con su formato. Si no incluye un número mágico, o no es lo primero en el archivo, corre el riesgo de que los programas identifiquen erróneamente su archivo como algún otro tipo de archivo, lo que conduce a la pérdida de datos, la detección de virus que escapan y otros catástrofes

• Una indicación de la versión del formato de archivo. Incluso si cree que nunca tendrá que revisar su formato de archivo drásticamente, haga los siguientes dos bytes después del número mágico 00 00y documente que se trata de un número de versión de 16 bits con una definición definitiva (lo que quiera, pero elija uno y manténgalo en todo el archivo ) y se incrementará si el significado de los datos posteriores cambia radicalmente. Tu futuro yo te lo agradecerá.

  (La especificación PNG toma una ruta diferente aquí, especificando que los formatos de fragmentos están congelados, y que todos los cambios futuros al formato tomarán la forma de nuevos tipos de fragmentos. Eso también es válido, pero recomiendo el enfoque de número mágico simple + número de versión para principiantes en el procesamiento de datos binarios. Las personas que diseñaron PNG se basaban en décadas colectivas de experiencia con formatos de imagen).

• Algún tipo de mecanismo para incrustar metadatos arbitrarios en el archivo. Esto puede ser tan simple como hacer que los siguientes dos bytes sean un desplazamiento de 16 bits desde el final del encabezado hasta el comienzo de los datos reales, con todo lo que debe interpretarse como pares clave-valor UTF-8 a la RFC 822 (es decir, " Tag: value\n" - si sigue esta ruta, le recomiendo no permitir el plegado de líneas largas). Nuevamente, PNG es considerablemente más inteligente.

Diferentes arquitecturas tienen diferentes representaciones para enteros. El riesgo principal aquí es guardar la representación de bytes de un número entero en la máquina A y luego intentar leerlo e interpretar los contenidos como números enteros en la máquina B. Si las máquinas A y B tienen tamaños diferentes para números enteros y / o diferente endianness , usted ' Lo más probable es que provoque un comportamiento indefinido (por ejemplo, en C) o una excepción.

Dado que este es solo un ejemplo de programación y no un programa "real", en realidad no es un problema. Si este fuera un programa real, rodar su propio formato binario específico de la aplicación generalmente no es una buena idea; existen mejores soluciones, como SQLite o formatos de serialización basados ​​en cadenas como JSON, YAML, XML, etc. Para valores únicos sería suficiente convertirlo en una cadena; para listas simples, puede guardar una cadena por línea y simplemente dividir la entrada en las nuevas líneas cuando la vuelva a leer.