Tamaño de archivo binario vs.ASCII

Si su única preocupación es el tamaño del archivo, entonces quiere archivos binarios. Para un ejemplo ilustrativo, supongamos que está escribiendo 1 número de punto flotante de precisión doble en un archivo. Supongamos que el sistema de archivos puede manejar esto perfectamente y que mantener el archivo, los encabezados y el relleno son todos 0.

Para un archivo binario, ese número tomaría el tamaño exacto del número en RAM, o 8 bytes.

En formato ASCII, tendría:

• 16 dígitos de la base
• 1 punto para el decimal
• 1 carácter para delimitar el exponente
• 1 carácter para el signo del exponente
• 2-3 caracteres para el exponente

Suponiendo utiliza sólo 1 byte para un carácter, es decir, 22 bytes para contener el mismo número. Esto no cuenta los caracteres necesarios para diluir entre números (normalmente al menos 1). Por lo tanto, el tamaño del archivo para el formato ASCII será aproximadamente 3 veces mayor.

Puede cambiar el tamaño del archivo por la precisión en los archivos almacenados (solo mantenga 5-6 dígitos en la base), pero eso depende de qué los está utilizando para. La principal ventaja de ASCII es la depuración o la producción de datos legibles por humanos.

Comentarios

• También es importante en el ámbito científico el archivado a largo plazo y la fiabilidad compartir, razón por la cual, a pesar de sus ‘ ineficiencias, ASCII CSV es tan frecuente y recomendado (PDF) .
• Otro punto útil es que, aunque la codificación ASCII CSV no es ‘ t muy eficiente, el uso de una utilidad de compresión de archivos (como zip, gzip, etc.) en su ascii file normalmente reducirá el tamaño del archivo a algo similar al tamaño de un archivo binario.
• Tenga cuidado porque algunas bibliotecas de entrada / salida no son ‘ t suficientemente cuidadosas para obtener reproducibilidad bit por bit a medida que genera números IEEE Double Precision en ASCII y luego los vuelve a leer. En mi experiencia, el uso de 17 o 18 dígitos decimales a veces es necesario por razones de seguridad.
• Concerniente a horchler ‘ s comentario: Estoy ‘ seguro de que los formatos binarios abiertos estandarizados y bien utilizados, como HDF5, existirán durante mucho tiempo. Eso ‘ es lo que ‘ recomiendo personalmente.
• + Me atengo al binario siempre que sea posible, para mayor precisión, compacidad, tranquilidad y (especialmente) rapidez. Luego, si necesito más compacidad, puedo comprimirlo. Si necesito poder leer visualmente el contenido, puedo escribir un pequeño programa para eso. Por otro lado, si ‘ es más importante ser visual y pasar fácilmente a programas aleatorios como Excel, R, etc., entonces CSV es el camino a seguir.

En la práctica, rara vez se necesitan datos en archivos de visualización que sean más precisos que, digamos, 3 válidos En ese caso, ASCII es, tal vez sorprendentemente, a menudo más compacto que el formato binario. Si está pensando en archivar, entonces bzip estos archivos ASCII probablemente producirá los archivos más pequeños que pueda obtener.

Dicho esto, Paraview lee el formato VTU que tiene un formato binario comprimido (basado en XML, pero los datos primero se comprimen en libz y luego se codifican en uuencoded para producir texto ASCII). En archivos típicos, esto ahorra un factor de 4 a 10. Para archivos grandes, este es definitivamente el camino a seguir.

Comentarios

• Voté esto por el contraste con la otra respuesta. No ‘ no tengo una opinión fuerte de ninguna manera, pero hay ‘ un buen punto aquí.
• Alternativamente, ponga a cero explícitamente los bits bajos y comprima el binario.
• Vaya, eso requeriría bastante manipulación de bits. ¿O hay funciones que hacen eso? (Aparte de lanzar para flotar y volver a doblar).

tl; dr – almacenar archivos en utf8 . Si es tabular, use valores separados por TAB.

Me parece que las opciones correctas son:

1. utf8 texto ( no ASCII . No todos hablamos inglés americano)
2. binario

ASAICT, la única ventaja real de los archivos binarios es el rendimiento. Es mucho más rápido cargar un volcado de memoria en la memoria que generar texto al salir o analizarlo al entrar.

p. Ej. https://www.cfd-online.com/Forums/openfoam/136983-binary-gives-significant-performance-advantage-mesh-solve.html

O aquí: https://auth0.com/blog/beating-json-performance-with-protobuf/ (Esto no es científico y se trata del rendimiento general, con las grandes diferencias en la cantidad de datos transmitidos y el tiempo de análisis en un caso sesgado hacia los datos textuales. )

Las posibilidades de que un formato de archivo binario admita correctamente el texto Unicode son escasas, por lo que si le preocupa la integridad de los datos, no utilice binary . ¿También ha oído hablar de problemas con endian? ¿Diferentes representaciones binarias de enteros con signo y flotantes?

Las representaciones de texto de -100000 y -1e + 6 no cambian el valor según en su CPU (en utf-8 y ASCII, en cualquier caso).

Las posibilidades de que un programa que entiende un archivo binario todavía lo entienda o todavía se ejecute dentro de 50 años son desconocidas, probablemente no sean buenas . Si le importa la longevidad, no utilice .

A menudo es difícil leer datos binarios de otro programa, por lo que si le preocupa la interoperabilidad, no utilice binarios .

Aparte: CSV es un formato de archivo terrible . Es simple, pero mal definido y requiere un analizador con estado. No use CSV. Si debe hacerlo, use TSV. Es más simple pero mejor definido y trivial de analizar.

https://chriswarrick.com/blog/2017/04/07/csv-is-not-a-standard/

https://www.cloudbakers.com/blog/everything-you-didnt-want-to-have-to-know-about-csv

Si le preocupa el tamaño, comprima .

(Vine aquí buscando estudios sobre la eficiencia del tamaño relativo de la representación binaria comprimida vs. texto. Aún no he encontrado buena información aparte de este estudio sobre VRML, pero ni siquiera estoy seguro de si es una comparación entre binario codificado en base64 y binario. https://www.cs.unc.edu/~isenburg/papers/is-bcraf-03.pdf .)