¿Por qué debería usar un formato de archivo legible por humanos?

Depende completamente de la situación.

Beneficios de un formato legible por humanos:

• Puedes leerlo en su formato "nativo"
• Puede escribirlo usted mismo, por ejemplo, para pruebas unitarias, o incluso para contenido real, dependiendo de para qué sirve

Beneficios probables de un formato binario:

• Más fácil de analizar (en términos de código)
• Más rápido para analizar
• Más eficiente en términos de espacio
• Más fácil de controlar (en cualquier momento que necesite texto allí, puede asegurarse de que está codificado en UTF-8, y longitud prefijada, etc.)
• Es más fácil incluir datos binarios opacos de manera eficiente (imágenes, etc., con un formato de texto que estaría ingresando en base64)

No olvide que siempre puede implementar un formato binario, pero también producir herramientas para convertir a/desde un formato legible por humanos. Eso es lo que hace el framework Protocol Buffers - en realidad es bastante raro que IME necesite analizar una versión de texto de un búfer de protocolo, pero es muy útil poder escríbelo como texto.

EDITAR: En caso de que esto termine siendo una respuesta aceptada, también debe tener en cuenta el punto hecho por starblue: Las formas legibles por humanos son mucho mejores para diffing. Sospecho que sería factible diseñar un formato binario que sea apropiado para el diffing (y donde se pueda generar un diff legible por humanos), pero el soporte listo para usar de las herramientas de diff existentes será mejor para el texto.

El control de versiones es más fácil con los formatos de texto, porque los cambios se pueden ver y combinar fácilmente.

Especialmente MS-Word nos está dando pena en este sentido.

• Formato abierto {sin malabares de bits binarios
• Legibilidad:)
• Intercambio entre plataformas
• Ayuda de depuración
• Fácilmente analizado (y fácilmente convertido a cualquier formato)

Un punto importante: escribes un analizador una vez, pero lees la salida muchas veces. Eso inclina la balanza a favor de HRF.

Una razón importante es que si alguien necesita leer los datos, digamos, dentro de 30 años, se puede averiguar el formato legible por humanos. Binario es mucho más difícil.

Si tiene grandes conjuntos de datos que son binarios por naturaleza (por ejemplo, imágenes), obviamente no pueden almacenarse en ninguna otra forma que no sea binaria. Pero incluso entonces, los metadatos podrían (¡y deberían!) ser legible por humanos.

Hay algo llamado El Arte de la Programación Unix.

No diré que sea bueno o malo, pero es bastante famoso. Tiene un capítulo entero llamado Textuality en el que el autor afirma que el formato de archivo legible por humanos es una parte importante de la forma de programación de Unix.

Abren la posibilidad de ser creados/editados con herramientas distintas a las originales. Nuevas y mejores herramientas pueden ser desarrolladas por otros, la integración en aplicaciones de terceros se hace posible. Piense en los archivos binariosal, por ejemplo, ¿el formato habría sido un éxito?

Aparte de eso: Los archivos legibles por humanos mejoran la capacidad de depurar o, para el usuario inteligente, al menos encontrar la razón de un error.

Pros para binario:

• rápido para analizar
• datos generalmente más pequeños
• fácil de escribir un analizador para

Pros para la lectura humana:

• más fácil de entender mientras se lee-no "el campo X se establece en 4 487, lo que significa que el reactor debe apagarse AHORA"
• si se utiliza algo como XML fácil de escribir una herramienta que analizará cualquier archivo

He tenido que lidiar con ambos tipos. Si estás enviando datos y quieres que sean pequeños binario es bueno. Si esperas que la gente lo lea, entonces la lectura humana es buena.

La lectura humana generalmente también se documenta a sí misma. Y con binario es bery fácil de cometer errores-y difícil de detectar.

• Editable
• Legible (duh!)
• Imprimible
• Bloc de notas y vi habilitados

Lo más importante, su función se puede deducir del contenido (bien principalmente)

Porque usted es un humano, y tarde o temprano usted (o uno de sus clientes) será capaz de leer los datos.

Solo usamos formato binario si la velocidad es un problema. E incluso entonces la depuración es problemática, por lo que agregamos un equivalente legible por humanos.

La interoperabilidad es el argumento estándar, es decir, una forma legible por humanos es más fácil de tratar para los desarrolladores de sistemas dispares, por lo que confiere alguna ventaja.

Personalmente creo que eso no es cierto, y los beneficios de rendimiento de los archivos binarios deberían superar ese argumento, especialmente si publica su protocolo. Sin embargo, la ubicuidad de los marcos basados en XML/HTTP para las interacciones de la máquina significa que es más fácil de adoptar.

XML se utiliza demasiado.

Solo una ilustración rápida donde el formato de documento legible por humanos puede ser una mejor opción:

Documentos utilizados para desplegar aplicaciones en producción

Solíamos tener nuestras notas de la versión en formato word, pero ese documento de notas de la versión tenía que abrirse en varios entornos (Linux, Solaris) en la plataforma de preproducción y producción.
También tuvo que ser analizado para extraer varios datos.

Al final, cambiamos a una sintaxis basada en wiki, todavía se muestra muy bien en HTML a través de un wiki, pero todavía se utiliza como un archivo de texto simple en otra situación.

Como complemento a esto, hay diferentes niveles de legibilidad humana, y todos se mejoran mediante el uso de un buen editor o visor con coloreado de código, plegado o navegación.

Por ejemplo,

• JSON es bastante legible incluso en texto plano
• XML tiene el impuesto de corchetes pero es utilizable cuando se utiliza un buen editor
• INI es en su mayoría legible por humanos
• CSV puede ser legible, pero es mejor cuando se carga en una hoja de cálculo.

Nadie dijo, así que lo haré: la legibilidad humana no es realmente una propiedad de un formato de archivo (todos los archivos son binarios después de todo), sino más bien de una combinación de formato de archivo y aplicación de visor.

Los llamados formatos legibles por humanos se basan en la parte superior de la capa de abstracción adicional de una de las codificaciones de texto existentes. Y los programas de visualización (a menudo también sirven como un editor) que son capaces de representar estas codificaciones en una forma legible por los seres humanos son muy comunes.

Los estándares de codificación de texto son generalizada y bastante madura, lo que significa que es poco probable que evolucionen mucho en el futuro previsible.

Por lo general, encima de la capa de codificación de texto del formato encontramos una capa de sintaxis que es razonablemente intuitiva dado el conocimiento del usuario objetivo y el trasfondo cultural.

De ahí los beneficios de los formatos "legibles por humanos":

• Ubicuidad de los espectadores y editores adecuados.

• Atemporalidad (dado que las convenciones culturales no cambiarán mucho).

• Facilidad para aprender, leer y modificar.

La dependencia de la capa de abstracción adicional hace que los archivos de texto codificados:

• Hambriento de espacio.

• Más lento de procesar.

Los archivos"binarios" no recurren a la capa de abstracción de codificación de texto como base (o denominador común), pero pueden o no usar algún tipo de abstracción adicional más adecuada para su propósito y, por lo tanto, pueden ser mucho mejores optimizado para una tarea específica en cuestión, lo que significa:

• Procesamiento más Rápido.

• Huella más pequeña.

Por otro lado:

• Los visores y editores son específicos para un formato binario en particular y dificultan la interoperabilidad.

• Los espectadores de cualquier formato dado están menos difundidos, porque son más especializados.

• Los formatos pueden evolucionar significativamente o dejar de usarse con el tiempo: el principal beneficio es ser muy adecuado para una tarea en particular y a medida que la tarea o los requisitos de la tarea evolucionan, también lo hace el formato.

Tómese un momento y piense en otras aplicaciones que no sean el desarrollo web.

La suposición de que: A) Tiene un significado que es "obvio" en formato de texto es falso. Cosas como los sistemas de control para una fábrica de acero, o planta de fabricación no suelen tener ninguna ventaja en ser legible por humanos. El software para esos tipos de entornos normalmente tendrá rutinas para mostrar los datos de una manera gráficamente significativa.

B) La salida en texto es más fácil. Innecesario las conversiones que realmente requieren más código hacen que un sistema sea MENOS robusto. El hecho del asunto si no está utilizando un lenguaje que trata todas las variables como cadenas, entonces el texto legible por humanos es una conversión adicional. Es decir, Código adicional significa más código para ser verificado, probado y más oportunidades para introducir errores en la aplicación.

C) Tienes que analizarlo de todos modos. Es muchos casos para los sistemas DSP he trabajado en (Es decir, NO hay interfaz legible por humanos para empezar.) Los datos se transmiten de la sistema en paquetes de tamaño uniforme. Registrar los datos para su análisis y posterior procesamiento es simplemente una cuestión de señalar el comienzo de un búfer y escribir un múltiplo del tamaño del bloque en el sistema de registro de datos. Esto me permite analizar los datos "intactos" ya que el sistema del cliente los vería donde, una vez más, convertirlos a un formato diferente resultaría en posiblemente introducir errores. No solo eso, si solo guarda los "datos convertidos", puede perder información en el traducción que puede ayudarle a diagnosticar un problema.

D) El texto es un formato natural para los datos. Ningún hardware que haya visto utiliza una interfaz de "TEXTO". (Mi primer trabajo fuera de la universidad fue escribir un controlador de dispositivo para una cámara de escaneo de línea de cámara.) La construcción del sistema en la parte superior de lo hace PODRÍA, pero para cada "PC".

Para las páginas web donde la información tiene un significado "natural" en formato de texto, así que seguro que te gusta. Para procesar código fuente es una obviedad, por supuesto. Pero el entornos informáticos generalizados donde incluso el refrigerador y el cepillo de DIENTES van a tener un procesador incorporado, no tanto. Simplemente sobrecargar este tipo de sistemas con la sobrecarga de agregar la capacidad de procesar texto introduce complejidad innecesaria. Usted no va a vincular "printf" en el software para un micro de 8 bits que controla un ratón. (Y sí, alguien tiene que escribir ese software también.)

El mundo no es un lugar blanco y negro donde las únicas formas de computación que deben tenerse en cuenta las PC y los servidores web.

Incluso en un PC, si puedo cargar directamente los datos directamente en una estructura de datos usando una sola llamada de lectura del sistema operativo y terminar con ella sin escribir rutinas de serialización y deserialización, eso es fantástico, comprobar un trabajo de CRC de bloques done hecho en el siguiente problema.

Uhm because ¿porque los formatos de archivo legibles por humanos pueden ser leídos por humanos? Me parece una buena razón.

(Bueno, para los archivos de configuración es inevitable que se lean (y editen!) por humanos. Los archivos para almacenamiento persistente de algún tipo u otro realmente no necesitan ser leídos o editados por humanos.)

¿Por qué debería usar un archivo legible por humanos formatear en preferencia a uno binario? ¿Hay alguna vez una situación en la que este no es el caso?

Sí, los volúmenes comprimidos (zip, jpeg, mp3, etc.) serían subóptimos si fueran legibles por humanos.

Supongo que no es bueno en la mayoría de las situaciones, probablemente. Creo que la razón principal de estos formatos como JSON y XML es debido al desarrollo web, y el uso general en la web donde necesita ser capaz de procesar datos en el lado del usuario y no necesariamente puede leer binario. Un buen ejemplo de un mal caso para usar un formato legible por humanos sería cualquier cosa no textual como imágenes, video, audio. He notado el uso de formatos no binarios que se utilizan en el desarrollo web donde no hace sentido, me siento culpable!

A menudo los archivos se convierten en parte de su interfaz humana, por lo que deben ser amigables con los humanos (no solo con el programador)

La única vez que uso un flujo binario para archivos que no son archivos es cuando quiero ocultar cosas del observador casual. Por ejemplo, si estoy creando archivos temporales que solo mi aplicación debería editar, usaré binario.

No es un intento de ofuscar, sino que solo desalienta al usuario de editar el archivo a mano (lo que podría romper la aplicación).

Una instancia donde esto sería una buena idea es almacenar / guardar datos en ejecución sobre vaya juego.. es decir, para guardar su juego y continuar más tarde. Otros escenarios describirían archivos intermedios, pero estos son típicamente compilados binarios / bytes de todos modos.

¿Por qué debería usar un archivo legible por humanos formatear en preferencia a uno binario?

Depende del contenido y el contexto, es decir, de dónde vienen y van los datos. Si los datos son típicamente escritos directamente por un humano, almacenarlos en un formato que pueda ser manipulado a través de un editor de texto es una buena idea. Por ejemplo, el código fuente del programa normalmente se almacenará como legible por humanos con una buena razón. Sin embargo, si lo estamos archivando, o compartiéndolo usando una versión sistema de control, nuestra estrategia de almacenamiento cambiará.

El formato humano es más simple para analizar y depurar si tiene un problema con un campo (ejemplo: un campo contiene un número donde la especificación dice que este campo debe ser una cadena), también el formato humano es closier al dominio del problema.

Prefiero el formato binario con muchos datos Y estoy seguro de que tengo el software para analizarlo:)

Al leer la disertación de Fielding sobre el DESCANSO, me gustó mucho el concepto de " Propiedades Arquitectónicas"; uno que se pegó fue "Visibilidad". De eso es de lo que estamos hablando aquí: poder " ver " los datos. Enormes beneficios al depurar el sistema.

Un aspecto que me falta en las otras respuestas: aplicar la semántica.

Desde el momento en que se va para ser legible por humanos, se permite que el usuario tonto bloc de notas para crear datos para ser alimentados en el sistema. Ninguna forma de garantizar estos datos tiene sentido. No hay forma de garantizar que el sistema responda de manera sensata.

Por lo tanto, en el caso de que no necesite inspeccionar sus datos con el bloc de notas, y desee hacer cumplir los datos válidos (por ejemplo, mediante el uso de una API) en lugar de validarlos primero, es mejor evitar los datos legibles por humanos. Si la capacidad de depuración es un problema (la mayoría de las veces lo es), la inspección de los datos también se puede realizar mediante la API.

Human readable no es igual a más fácil de analizar por código máquina.

Tomemos como ejemplo el lenguaje natural humano. :) El análisis automático del lenguaje humano sigue siendo un problema pendiente por resolver.

Así que estoy de acuerdo con https://stackoverflow.com/a/714111/2727173 que tiene una visión mucho más profunda sobre esta cuestión.