¿Cuál es la diferencia entre YAML y JSON?


736

¿Cuáles son las diferencias entre YAML y JSON, considerando específicamente las siguientes cosas?

  • Rendimiento (tiempo de codificación / decodificación)
  • Consumo de memoria
  • Claridad de expresión
  • Disponibilidad de la biblioteca, facilidad de uso (prefiero C)

Estaba planeando usar uno de estos dos en nuestro sistema integrado para almacenar archivos de configuración.

Relacionado:

¿Debo usar YAML o JSON para almacenar mis datos de Perl?


26
Tenga en cuenta que JSON puede considerarse un subconjunto de YAML: en.wikipedia.org/wiki/JSON#YAML
Charles

2
@Charles, sí, pero tienen una sutil diferencia: ajaxian.com/archives/json-yaml-its-getting-closer-to-truth
pierrotlefou

1
Dado que YAML (aproximadamente) es un superconjunto de JSON, la cuestión del rendimiento no puede responderse sin suponer si usará esa expresividad. Si no lo necesita: ¿qué tan rápido son los analizadores YAML para leer JSON? Si lo necesita: ¿cuánto más lentos son los analizadores JSON cuando permite una representación JSON posiblemente más larga de la misma idea?
Poolie

@jokoon supongo que "preferiría una biblioteca C" (por ejemplo, libyaml)
dbr

44
Los documentos de YAML pueden ser complejos y difíciles de leer. Un ataque de "Billion risas" es posible con YAML. Por otro lado, los objetos complejos, gráficos y otras estructuras se pueden serializar de manera eficiente en YAML. Para formatos de intercambio y estructuras simples, se prefiere JSON. Para la serialización de objetos complejos, o para definiciones gramaticales, se puede preferir YAML.
Erik Aronesty

Respuestas:


657

Técnicamente, YAML es un superconjunto de JSON. Esto significa que, al menos en teoría, un analizador YAML puede entender JSON, pero no necesariamente al revés.

Consulte las especificaciones oficiales, en la sección titulada "YAML: Relación con JSON" .

En general, hay ciertas cosas que me gustan de YAML que no están disponibles en JSON.

  • Como señaló @jdupont , YAML es visualmente más fácil de ver. De hecho, la página de inicio de YAML es YAML válida, sin embargo, es fácil de leer para un humano.
  • YAML tiene la capacidad de hacer referencia a otros elementos dentro de un archivo YAML utilizando "anclas". Por lo tanto, puede manejar información relacional como se podría encontrar en una base de datos MySQL.
  • YAML es más robusto acerca de incrustar otros formatos de serialización como JSON o XML dentro de un archivo YAML.

En la práctica, ninguno de estos dos últimos puntos probablemente importará para las cosas que usted o yo hacemos, pero a largo plazo, creo que YAML será un formato de serialización de datos más robusto y viable.

En este momento, AJAX y otras tecnologías web tienden a usar JSON. Actualmente, YAML se está utilizando más para procesos de datos fuera de línea. Por ejemplo, se incluye de manera predeterminada en el paquete de visión por computadora OpenCV basado en C, mientras que JSON no.

Encontrará bibliotecas C para JSON y YAML. Las bibliotecas de YAML tienden a ser más nuevas, pero no he tenido problemas con ellas en el pasado. Ver por ejemplo Yaml-cpp .


199
json no es un subconjunto (aunque está cerca), y las incompatibilidades son irritantes cuando las alienta. Las bibliotecas json son generalmente más rápidas ... ( stackoverflow.com/questions/2451732/… ). Los defensores de YAML insistirán en que es un subconjunto. Si la legibilidad es una preocupación, use yaml. Si la interoperabilidad y la velocidad son una preocupación, use JSON.
Erik Aronesty

66
YAML es un superconjunto de una forma particular de sintaxis JSON. Es decir, si usa JSON de una manera compatible con YAML, entonces es un subconjunto adecuado. Como Pierr comentó anteriormente, las especificaciones son [apuntando hacia la compatibilidad] (ajaxian.com/archives/json-yaml-its-getting-closer-to-truth).
naught101

120
También YAML admite comentarios, lo cual es útil.
Den

59
@ErikAronesty JSON estaba cerca de un subconjunto de YAML 1.1, pero desde YAML 1.2 ahora es un verdadero subconjunto. YAML 1.2 se lanzó principalmente para resolver las últimas incompatibilidades entre las dos especificaciones.
00prometheus

64
De la especificación YAML 1.2 : "El objetivo principal de esta revisión es lograr que YAML cumpla con JSON como un subconjunto oficial".
Rich C

205

Diferencias:

  1. YAML, dependiendo de cómo lo use, puede ser más legible que JSON
  2. JSON es a menudo más rápido y probablemente aún sea interoperable con más sistemas
  3. Es posible escribir un analizador JSON "suficientemente bueno" muy rápidamente
  4. Las claves duplicadas, que son JSON potencialmente válidas, definitivamente son YAML inválidas.
  5. YAML tiene un montón de características, incluidos comentarios y anclas relacionales. La sintaxis de YAML es, por lo tanto, bastante compleja y puede ser difícil de entender.
  6. Es posible escribir estructuras recursivas en yaml:, {a: &b [*b]}que se repetirá infinitamente en algunos convertidores. Incluso con detección circular, todavía es posible una "bomba yaml" (ver bomba xml ).
  7. Debido a que no hay referencias, es imposible serializar estructuras complejas con referencias de objetos en JSON. La serialización de YAML puede, por lo tanto, ser más eficiente.
  8. En algunos entornos de codificación, el uso de YAML puede permitir que un atacante ejecute código arbitrario .

Observaciones:

  1. Los programadores de Python son generalmente grandes admiradores de YAML, debido al uso de sangría, en lugar de sintaxis entre corchetes, para indicar niveles.
  2. Muchos programadores consideran que el apego del "significado" a la sangría es una mala elección.
  3. Si el formato de datos abandona el entorno de una aplicación, se analiza dentro de una interfaz de usuario o se envía en una capa de mensajería, JSON podría ser una mejor opción.
  4. YAML se puede usar, directamente, para tareas complejas como definiciones gramaticales, y a menudo es una mejor opción que inventar un nuevo lenguaje.

99
Está. El propósito completo de Yaml 1.2 era resolver las pocas diferencias de compatibilidad para hacer de JSON un subconjunto estricto. Si cree que la especificación no logró su propósito, Erik, señale un ejemplo en algún lugar de JSON válido que viole la especificación YAML y / o rompa un analizador YAML verificado compatible con 1.2.
SFEley

32
@SFEley La especificación YAML dice que hay archivos JSON potencialmente válidos que serían YAML no válidos. Pero no es probable que se use realmente. "El RFC4627 de JSON requiere que las claves de asignación simplemente" DEBEN "ser únicas, mientras que YAML insiste en que" DEBEN "serlo. Técnicamente, YAML cumple con la especificación JSON, eligiendo tratar los duplicados como un error. En la práctica, ya que JSON no dice nada semántica de tales duplicados, los únicos archivos JSON portátiles son aquellos con claves únicas, que por lo tanto son archivos YAML válidos ". - yaml.org/spec/1.2/spec.html#id2759572
David C. Bishop

99
Para comentar sobre el uso de sangría; bueno, creo que eso podría requerir acostumbrarse y no a todos les gustaría. Por ejemplo, soy un chico .NET. Estaba mirando un archivo travis.yml y me preguntaba por qué había un problema. Descubrí que tenía una pestaña donde no estaba. No todos están acostumbrados a que las cosas exploten debido a las preferencias de espacio / tabulación / nuevas líneas.
Phil

10
Las pestañas simplemente no están permitidas como caracteres de sangría. En mi humilde opinión, ese es un buen estilo de codificación en todos los idiomas, con o sin sangría sintáctica.
00prometheus

66
@Wyrmwood Personalmente me gustan Python y YAML y literalmente los uso todos los días. Tiendo a usar YAML para cosas que la gente tiene que editar a menudo y JSON para cosas que la gente "podría" necesitar mirar. He sido objeto de críticas válidas por parte de desarrolladores de C ++ que consideran que la sangría es confusa ... especialmente si hay varios niveles o bloques de funciones más largos. Por supuesto ... un buen código comprobable no tiene esas cosas, por lo que generalmente no es un problema. Esta es mi observación personal, pero cualquier búsqueda casual en Google arrojará muchos resultados ... así que es trivial de verificar.
Erik Aronesty

89

Sin pasar por la teoría esotérica

Esto responde al título, no a los detalles, ya que la mayoría solo leyó el título de un resultado de búsqueda en Google como yo, así que sentí que era necesario explicarlo desde la perspectiva de un desarrollador web .

  1. YAML usa sangría de espacio, que es un territorio familiar para los desarrolladores de Python.
  2. Los desarrolladores de JavaScript adoran JSON porque es un subconjunto de JavaScript y se puede interpretar y escribir directamente dentro de JavaScript, junto con el uso de una forma abreviada de declarar JSON, que no requiere comillas dobles en las teclas cuando se usan nombres de variables típicos sin espacios.
  3. Hay una gran cantidad de analizadores que funcionan muy bien en todos los idiomas para YAML y JSON.
  4. El formato de espacio de YAML puede ser mucho más fácil de ver en muchos casos porque el formato requiere un enfoque más legible para los humanos.
  5. La forma de YAML, aunque es más compacta y más fácil de ver, puede ser engañosamente difícil de editar a mano si no tiene un formato de espacio visible en su editor. Las pestañas no son espacios, por lo que se confunde aún más si no tiene un editor para interpretar sus pulsaciones de teclas en espacios.
  6. JSON es mucho más rápido para serializar y deserializar debido a que tiene muchas menos características que YAML para verificar, lo que permite que un código más pequeño y ligero procese JSON.
  7. Un error común es que YAML necesita menos puntuación y es más compacto que JSON, pero esto es completamente falso. El espacio en blanco es invisible, por lo que parece que hay menos caracteres, pero si cuenta el espacio en blanco real que es necesario para que YAML se interprete correctamente junto con la sangría adecuada, encontrará que YAML realmente requiere más caracteres que JSON. JSON no utiliza espacios en blanco para representar la jerarquía o la agrupación y se puede aplanar fácilmente con espacios en blanco innecesarios eliminados para un transporte más compacto.

El elefante en la habitación: el propio internet

JavaScript domina tan claramente la web por un amplio margen y los desarrolladores de JavaScript prefieren usar JSON como el formato de datos de manera abrumadora junto con las API web populares, por lo que se hace difícil discutir el uso de YAML sobre JSON cuando se realiza la programación web en el sentido general, ya que es probable que sea votado en un ambiente de equipo De hecho, la mayoría de los programadores web ni siquiera saben que YAML existe, y mucho menos consideran usarlo.

Si está haciendo una programación web, JSON es el camino predeterminado porque no se necesita ningún paso de traducción cuando se trabaja con JavaScript, por lo que debe encontrar un argumento mejor para usar YAML sobre JSON en ese caso.


10
No estoy de acuerdo con que los desarrolladores de Python prefieran YAML. Pythons dict es básicamente JSON, la lista de dictos también es básicamente JSON. Python tiene compilación en json lib. En una nota al margen, soy un desarrollador de Python y prefiero JSON (la mayoría de los desarrolladores de Python que conozco prefieren JSON).
karantan

66
Lo único que realmente me molesta sobre el espacio en blanco es lo fácil que es confundirse y equivocarse, ya que la sangría o no puede significar que está anidado o en el mismo nivel y también es muy fácil confundirlo si no lo hace Tener una regla de guía. Es como los Oops ocultos, este no es realmente el tipo de escenario fácil que nadie dice al editar yaml. Nunca tuve ese problema con JSON.
Jason Sebring

66
@JasonSebring. Casi te preguntarías por qué YAML fue con espacios. Mi primer 'chapuzón en el océano' de YAML condujo a una aplicación rota ... todo debido a los espacios. ¡Habría pensado que tal vez usar una sangría que no use caracteres sin impresión hubiera tenido mucho más sentido! (Es decir, ¿por qué demonios no eligieron '.' En lugar de ''?) Para entender YAML tienes que ir a las especificaciones. Para entender JSON no necesita eso. (He estado en el primero, y nunca en el segundo). Esto para mí indica un formato que no es realmente 'legible para humanos'
cmroanirgo

77
@cmroanirgo yah esta fue mi experiencia. Mi jefe nos obligó a usar YAML sobre JSON e hizo que las cosas fueran innecesariamente malas para editar e ingerir. Escribí esto debido a que esperar votos me vindicaría.
Jason Sebring

3
Problemas con las pestañas en YAML significa que (a) no lee el mensaje de error y (b) tiene un editor que no resalta las pestañas. Ambos problemas son fácilmente rectificables, por lo que no entiendo las quejas.
toolforger

38

Esta pregunta tiene 6 años, pero extrañamente, ninguna de las respuestas realmente aborda los cuatro puntos (velocidad, memoria, expresividad, portabilidad).

Velocidad

Obviamente, esto depende de la implementación, pero debido a que JSON es tan ampliamente utilizado y tan fácil de implementar, ha tendido a recibir un mayor soporte nativo y, por lo tanto, velocidad. Teniendo en cuenta que YAML hace todo lo que JSON hace, más un camión más, es probable que de cualquier implementación comparable de ambos, el JSON sea más rápido.

Sin embargo, dado que un archivo YAML puede ser un poco más pequeño que su homólogo de JSON (debido al menor número "y ,caracteres), es posible que un analizador YAML altamente optimizado podría ser más rápida en circunstancias excepcionales.

Memoria

Básicamente se aplica el mismo argumento. Es difícil ver por qué un analizador YAML alguna vez sería más eficiente en memoria que un analizador JSON, si representan la misma estructura de datos.

Expresividad

Como señalaron otros, los programadores de Python tienden a preferir YAML, los programadores de JavaScript a JSON. Haré estas observaciones:

  • Es fácil memorizar toda la sintaxis de JSON y, por lo tanto, tener mucha confianza para comprender el significado de cualquier archivo JSON. YAML no es realmente entendible por ningún humano. El número de sutilezas y casos extremos es extremo.
  • Debido a que pocos analizadores implementan la especificación completa, es aún más difícil estar seguro sobre el significado de una expresión dada en un contexto dado.
  • La falta de comentarios en JSON es, en la práctica, un verdadero dolor.

Portabilidad

Es difícil imaginar un lenguaje moderno sin una biblioteca JSON. También es difícil imaginar un analizador JSON que implemente algo menos que la especificación completa. YAML tiene un amplio soporte, pero es menos ubicuo que JSON, y cada analizador implementa un subconjunto diferente. Por lo tanto, los archivos YAML son menos interoperables de lo que piensas.

Resumen

JSON es el ganador por el rendimiento (si corresponde) y la interoperabilidad. YAML es mejor para archivos mantenidos por humanos. HJSON es un compromiso decente aunque con una portabilidad muy reducida. JSON5 es un compromiso más razonable, con una sintaxis bien definida.


3
De hecho, pensé que YAML era más pequeño debido a los personajes invisibles que me engañaron como tal. Invisible => No existe, bueno, en realidad no. Si cuenta que los caracteres invisibles tienen que estar allí, especialmente a medida que YAML aumenta su anidamiento, supera rápidamente a JSON. Simplemente pensé que era muy interesante ya que la porción legible por humanos nos engaña a la mayoría de nosotros hasta que realmente lo pensé, ya que puedes aplanar a JSON y YAML, no tanto. También encontré que YAML es muy difícil de editar a mano, no leer, solo editar, ya que necesita activar las guías del editor, confundiendo fácilmente elementos anidados a veces.
Jason Sebring

1
Siento que ninguna de las respuestas aquí dice esto explícitamente: "Para los archivos de configuración / configuración, YAML es mejor (por las razones mencionadas anteriormente por todos). Para la interoperabilidad máquina / máquina, use JSON". En otras palabras: si su público objetivo es humano, YAML es mejor. Si el objetivo es otro programa (pero aún desea que los datos sean legibles por humanos), use JSON.
Florin T.

Eso es cierto, pero la pregunta estableció algunos parámetros bastante específicos sobre cómo querían que los dos fueran comparados. Personalmente, nunca usaría YAML para nada. O usaría JSON para la interoperabilidad, o JSON6 si el mantenimiento humano es importante.
Steve Bennett

29

GIT y YAML

Las otras respuestas son buenas. Lee esos primero. Pero agregaré otra razón para usar YAML a veces: git .

Cada vez más, muchos proyectos de programación usan repositorios git para distribución y archivo. Y, si bien el historial de un repositorio de git puede almacenar archivos JSON y YAML por igual, el método "diff" utilizado para rastrear y mostrar los cambios en un archivo está orientado a líneas. Dado que YAML se ve obligado a estar orientado a la línea, cualquier pequeño cambio en un archivo YAML es más fácil de ver por un humano.

Es cierto, por supuesto, que los archivos JSON pueden "hacerse bonitos" clasificando las cadenas / claves y agregando sangría. Pero esto no es lo predeterminado y soy vago.

Personalmente, generalmente uso JSON para la interacción de sistema a sistema. A menudo uso YAML para archivos de configuración, archivos estáticos y archivos rastreados. (También evito generalmente agregar anclas relacionales YAML. La vida es demasiado corta para cazar bucles).

Además, si la velocidad y el espacio son realmente una preocupación, tampoco lo uso. Es posible que desee mirar BSON.


22

Me parece que YAML es más fácil para la vista: menos paréntesis, "" etc. Aunque existe la molestia de las pestañas en YAML ... pero uno se acostumbra.

En términos de rendimiento / recursos, no esperaría grandes diferencias entre los dos.

Además, estamos hablando de archivos de configuración, por lo que no esperaría una alta frecuencia de actividad de codificación / decodificación, ¿no?


22
Me preguntaba qué querías decir con la molestia de las pestañas . Creo que la cuestión es que los caracteres de tabulación no están permitidos en yaml , lo que personalmente creo que es una buena idea en cualquier archivo fuente .
Poolie

66
@poolie: jldupont probablemente se refiere al espacio en blanco líder sintácticamente significativo en YAML.
naught101

10
Está bien, pero no son pestañas.
poolie

20

Si no necesita ninguna característica que tenga YAML y JSON no, preferiría JSON porque es muy simple y es ampliamente compatible (tiene muchas bibliotecas en muchos idiomas). YAML es más complejo y tiene menos soporte. No creo que la velocidad de análisis o el uso de la memoria sean muy diferentes, y tal vez no sean una gran parte del rendimiento de su programa.


3
¿De qué manera es YAML más complejo?
Accatyyc

18
Por ejemplo, YAML admite anclas, como se ha señalado en otra respuesta. Hay otras características, como los tipos de datos extensibles. Esto hace que el análisis sea más complejo y explica por qué YAML tiene especificaciones más grandes. Puede afectar el rendimiento dependiendo de la implementación del analizador (eche un vistazo a esta pregunta: stackoverflow.com/questions/2451732/… ).
Anton Strogonoff

55
La complejidad es mejor que la simplicidad si esa complejidad le da poder para lograr una mayor simplicidad general. Eso es cierto dependiendo de la complejidad de su modelo de datos.
Jonathan Neufeld

3
Puede que llegue un poco tarde aquí, pero YAML puede agregar comentarios, mientras que JSON no. Para mí es de gran ayuda cuando se trata de la documentación de las especificaciones
Moses Liao GZ

@Accatyyc. Creo que el hecho de que la gente esté haciendo preguntas sobre la diferencia es una señal segura de que YAML no es tan fácil. He nunca se hizo una pregunta sobre JSON (excepto "¿por qué no puedo tener comentarios en él?")
cmroanirgo

15

Técnicamente, YAML ofrece mucho más que JSON (YAML v1.2 es un superconjunto de JSON):

  • comentarios
  • Anclas y herencia: ejemplo de 3 elementos idénticos:

    item1: &anchor_name
      name: Test
      title: Test title
    item2: *anchor_name
    item3:
      <<: *anchor_name
      # You may add extra stuff.
  • ...

La mayoría de las veces las personas no usarán esas características adicionales y la principal diferencia es que YAML usa sangría mientras que JSON usa corchetes . Esto hace que YAML sea más conciso y legible (para el ojo entrenado).

¿Cuál elegir?

  • Las características adicionales de YAML y la notación concisa lo convierten en una buena opción para los archivos de configuración ( archivos no proporcionados por el usuario).
  • Las características limitadas de JSON , el amplio soporte y el análisis más rápido lo convierten en una excelente opción para la interoperabilidad y los datos proporcionados por el usuario .

4

Dado que esta pregunta ahora ocupa un lugar destacado al buscar YAML y JSON, vale la pena señalar una diferencia rara vez citada entre los dos: licencia. JSON pretende tener una licencia a la que deben adherirse los usuarios de JSON (incluido el "legalmente ambiguo" se utilizará para el bien, no para el mal "). YAML no tiene dicho reclamo de licencia, y eso podría ser una diferencia importante (para su abogado, si no para usted).


No uso JSON, uso el equivalente exacto de JSON sin llamarlo JSON. Lo llamo PS-OFF. Me vas a demandar por usar { "": #, [] }???
Andrew

4

A veces no tienes que decidir por uno sobre el otro.

En Go, por ejemplo, puede tener ambos al mismo tiempo:

type Person struct {
    Name string `json:"name" yaml:"name"`
    Age int `json:"age" yaml:"age"`
}

3

De: Arnaud Lauret Libro "El diseño de las API web". :

El formato de datos JSON

JSON es un formato de datos de texto basado en cómo el lenguaje de programación JavaScript describe los datos pero, a pesar de su nombre, es completamente independiente del idioma (consulte https://www.json.org/ ). Con JSON , puede describir objetos que contienen pares de nombre / valor desordenados y también matrices o listas que contienen valores ordenados, como se muestra en esta figura.

ingrese la descripción de la imagen aquí

Un objeto está delimitado por llaves ({}). Un nombre es una cadena entre comillas ("nombre") y está separado de su valor por dos puntos (:). Un valor puede ser una cadena como "valor", un número como 1.23, un valor booleano (verdadero o falso), el valor nulo nulo, un objeto o una matriz. Una matriz está delimitada por corchetes ([]), y sus valores están separados por comas (,). El formato JSON se analiza fácilmente utilizando cualquier lenguaje de programación. También es relativamente fácil de leer y escribir. Es ampliamente adoptado para muchos usos, como bases de datos, archivos de configuración y, por supuesto, API.

Ñame

YAML (YAML Ain't Markup Language) es un formato de serialización de datos amigable para los humanos. Al igual que JSON, YAML ( http://yaml.org ) es un formato de datos clave / valor. La figura muestra una comparación de los dos.

ingrese la descripción de la imagen aquí

Tenga en cuenta los siguientes puntos:

  • No hay comillas dobles ("") alrededor de nombres de propiedad y valores en YAML .

  • Las llaves y comas estructurales ({}) y las comas (,) de JSON se reemplazan por nuevas líneas y sangría en YAML .

  • Los corchetes de matriz ([]) y las comas (,) se reemplazan por guiones (-) y líneas nuevas en YAML .

  • A diferencia de JSON , YAML permite comentarios que comienzan con una marca hash (#). Es relativamente fácil convertir uno de esos formatos en el otro. Sin embargo, tenga en cuenta que perderá comentarios al convertir un documento YAML a JSON .


0

Creo que tanto YAML como JSON son muy efectivos. Las dos únicas cosas que realmente dictan cuando una se usa sobre la otra para mí es una, con qué idioma se usa más popularmente. Por ejemplo, si estoy usando Java, Javascript, usaré JSON. Para Java, usaré sus propios objetos, que son más o menos JSON pero que carecen de algunas características, y lo convertiré a JSON si lo necesito o lo haré en JSON en primer lugar. Lo hago porque eso es algo común en Java y facilita que otros desarrolladores de Java modifiquen mi código. Lo segundo es si lo estoy usando para que el programa recuerde atributos, o si el programa está recibiendo instrucciones en forma de un archivo de configuración, en este caso usaré YAML, porque es muy fácil de leer por humanos, tiene buena buscando sintaxis, y es muy fácil de modificar, incluso si no tienes idea de cómo funciona YAML. Luego, el programa lo leerá y lo convertirá a JSON, o lo que sea preferido para ese idioma.

Al final, honestamente no importa. JSON y YAML son leídos fácilmente por cualquier programador experimentado.


-1
  • JSON no puede manejar datos grandes comparando yml

  • No es adecuado para manejar diferentes formatos multimedia.

  • JSON no tiene una función para admitir 'comentarios'. Esto podría incluirse como un atributo adicional solo.

  • YAML tiene algunas ventajas sobre JSON como autorreferencia, soporte para tipos de datos complejos, literales de bloque incrustados, comentarios y más.

  • JSON solo es legible, mientras que YAML puede ser legible y editable.
  • JSON es un subconjunto de YAML para que los analizadores YAML puedan analizar JSON.
  • YAML no utiliza ningún delimitador adicional, por lo que es más ligero que XML y JSON.

¿Qué quiere decir con los puntos de "datos grandes" y "solo legibles"? JSON es un formato de datos, ¿qué puede tener un concepto abstracto con estas dos limitaciones?
João Farias

44
@ JoãoFarias Digamos que tiene un archivo JSON de 1GB y un archivo CSV de 1GB y tiene 256MB de memoria. Puede procesar el archivo CSV línea por línea, con JSON no es fácilmente posible. Probablemente aún sea más fácil analizar el archivo YAML línea por línea, que analizar JSON.
NeverEndingQueue
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.