JSON ( Notación de objetos JavaScript , pronunciado / ˈ dʒ eɪ s ən / ; también / ˈ dʒ eɪ ˌ s ɒ n / ) es un formato de archivo estándar abierto y un formato de intercambio de datos que utiliza texto legible por humanos para almacenar y transmitir objetos de datos que consisten en pares y matrices atributo-valor (u otros valores serializables ). Es un formato de datos comúnmente utilizado con diversos usos en el intercambio electrónico de datos , incluido el de aplicaciones web con servidores .
JSON es un formato de datos independiente del idioma . Se derivó de JavaScript , pero muchos lenguajes de programación modernos incluyen código para generar y analizar datos en formato JSON. Los nombres de archivos JSON usan la extensión .json.
Douglas Crockford especificó originalmente el formato JSON a principios de la década de 2000. [1] Él y Chip Morningstar enviaron el primer mensaje JSON en abril de 2001.
El estándar internacional de 2017 (ECMA-404 e ISO/IEC 21778:2017) especifica que "JSON" se "pronuncia / ˈ dʒ eɪ . s ə n / , como en ' Jason y los argonautas ' ". [2] [3] La primera edición (2013) de ECMA-404 no abordó la pronunciación. [4] El Manual de administración de sistemas UNIX y Linux establece que " Douglas Crockford , quien nombró y promovió el formato JSON, dice que se pronuncia como el nombre Jason. Pero de alguna manera, "JAY-sawn" parece haberse vuelto más común en la comunidad técnica. ". [5] Crockford dijo en 2011: "Hay muchas discusiones sobre cómo se pronuncia eso, pero a mí no me importa en absoluto". [6]
Después de que RFC 4627 estuvo disponible como su especificación "informativa" desde 2006, JSON se estandarizó por primera vez en 2013, como ECMA -404. [7] RFC 8259, publicado en 2017, es la versión actual del estándar de Internet STD 90 y sigue siendo consistente con ECMA-404. [8] Ese mismo año, JSON también fue estandarizado como ISO / IEC 21778:2017. [2] Los estándares ECMA e ISO / IEC describen solo la sintaxis permitida, mientras que el RFC cubre algunas consideraciones de seguridad e interoperabilidad. [9]
JSON surgió de la necesidad de un protocolo de comunicación de sesión de servidor a navegador en tiempo real sin utilizar complementos de navegador como Flash o subprogramas Java , los métodos dominantes utilizados a principios de la década de 2000. [10]
Crockford fue el primero en especificar y popularizar el formato JSON. [11] El acrónimo se originó en State Software, una empresa cofundada por Crockford y otros en marzo de 2001. Los cofundadores acordaron construir un sistema que utilizaba capacidades de navegador estándar y proporcionaba una capa de abstracción para que los desarrolladores web crearan aplicaciones web con estado. que tenía una conexión dúplex persistente a un servidor web al mantener abiertas dos conexiones de Protocolo de transferencia de hipertexto (HTTP) y reciclarlas antes de que se agotara el tiempo de espera estándar del navegador si no se intercambiaban más datos. Los cofundadores mantuvieron una mesa redonda y votaron si llamar al formato de datos JSML (JavaScript Markup Language) o JSON (JavaScript Object Notation), así como bajo qué tipo de licencia ponerlo a disposición. El sitio web JSON.org [12] se lanzó en 2001. En diciembre de 2005, Yahoo! comenzó a ofrecer algunos de sus servicios web en JSON. [13]
Se utilizó un precursor de las bibliotecas JSON en un proyecto de juego de comercio de activos digitales para niños llamado Cartoon Orbit en Communities.com [ cita necesaria ] (todos los cofundadores estatales habían trabajado en esta empresa anteriormente) para Cartoon Network [ cita necesaria ] , que utilizó un complemento del lado del navegador con un formato de mensajería propietario para manipular elementos DHTML (este sistema también es propiedad de 3DO [ cita requerida ] ). Tras el descubrimiento de las primeras capacidades de Ajax , digiGroups, Noosh y otros utilizaron marcos para pasar información al campo visual de los navegadores de los usuarios sin actualizar el contexto visual de una aplicación web, creando aplicaciones web enriquecidas en tiempo real utilizando solo las capacidades estándar HTTP, HTML y JavaScript. de Netscape 4.0.5+ e IE 5+. Crockford luego descubrió que JavaScript podría usarse como formato de mensajería basado en objetos para dicho sistema. El sistema se vendió a Sun Microsystems , Amazon.com y EDS .
JSON se basó en un subconjunto del lenguaje de secuencias de comandos JavaScript (específicamente, el estándar ECMA -262, tercera edición, diciembre de 1999 [14] ) y se usa comúnmente con JavaScript, pero es un formato de datos independiente del lenguaje . El código para analizar y generar datos JSON está disponible en muchos lenguajes de programación . El sitio web de JSON enumera las bibliotecas JSON por idioma.
En octubre de 2013, Ecma International publicó la primera edición de su estándar JSON ECMA-404. [7] Ese mismo año, RFC 7158 utilizó ECMA-404 como referencia. En 2014, RFC 7159 se convirtió en la principal referencia para los usos de JSON en Internet, reemplazando a RFC 4627 y RFC 7158 (pero conservando ECMA-262 y ECMA-404 como referencias principales). En noviembre de 2017, ISO/IEC JTC 1/SC 22 publicó ISO/IEC 21778:2017 [2] como estándar internacional. El 13 de diciembre de 2017, el Grupo de Trabajo de Ingeniería de Internet dejó obsoleto el RFC 7159 cuando publicó el RFC 8259, que es la versión actual del Estándar de Internet STD 90. [15] [16]
Crockford agregó una cláusula a la licencia JSON que establece que "El software se usará para el bien, no para el mal", con el fin de abrir las bibliotecas JSON mientras se burla de los abogados corporativos y de aquellos que son demasiado pedantes. Por otro lado, esta cláusula generó problemas de compatibilidad de la licencia JSON con otras licencias de código abierto , ya que el software de código abierto y el software libre no suelen implicar restricciones en el propósito de uso. [17]
El siguiente ejemplo muestra una posible representación JSON que describe a una persona.
{ "first_name" : "John" , "last_name" : "Smith" , "is_alive" : verdadero , "edad" : 27 , "dirección" : { "street_address" : "21 2nd Street" , "ciudad" : "Nuevo York" , "estado" : "NY" , "código_postal" : "10021-3100" }, "números_teléfonos" : [ { "tipo" : "casa" , "número" : "212 555-1234" }, { " tipo" : "oficina" , "número" : "646 555-4567" } ], "hijos" : [ "Catherine" , "Thomas" , "Trevor" ], "cónyuge" : nulo } Aunque Crockford afirmó originalmente que JSON es un subconjunto estricto de JavaScript y ECMAScript, [18] su especificación en realidad permite documentos JSON válidos que no son JavaScript válidos; JSON permite que los terminadores de línea Unicode U+2028 LINE SEPARATOR y U+2029 PARAGRAPH SEPARATOR aparezcan sin escape en cadenas entre comillas, mientras que ECMAScript 2018 y versiones anteriores no lo hacen. [19] [20] Esto es una consecuencia de que JSON no permite solo "caracteres de control". Para una máxima portabilidad, estos caracteres deben tener caracteres de escape con barra invertida.
El intercambio JSON en un ecosistema abierto debe codificarse en UTF-8 . [8] La codificación admite el conjunto completo de caracteres Unicode, incluidos aquellos caracteres fuera del plano multilingüe básico (U+0000 a U+FFFF). Sin embargo, si se utilizan caracteres de escape, esos caracteres deben escribirse utilizando pares sustitutos UTF-16 . Por ejemplo, para incluir el carácter Emoji U+1F610 😐 CARA NEUTRA en JSON:
{ "cara" : "😐" } // o { "cara" : "\uD83D\uDE10" } JSON se convirtió en un subconjunto estricto de ECMAScript a partir de la revisión de 2019 del lenguaje. [20] [21]
Los tipos de datos básicos de JSON son:
trueofalsenull: un valor vacío, usando la palabranullSe permiten espacios en blanco que se ignoran alrededor o entre elementos sintácticos (valores y puntuación, pero no dentro de un valor de cadena). Para este propósito, se consideran espacios en blanco cuatro caracteres específicos: espacio , tabulación horizontal , avance de línea y retorno de carro . En particular, la marca de orden de bytes no debe ser generada por una implementación conforme (aunque puede aceptarse al analizar JSON). JSON no proporciona sintaxis para comentarios . [24]
Las primeras versiones de JSON (como las especificadas en RFC 4627) requerían que un texto JSON válido consistiera únicamente en un objeto o un tipo de matriz, que podría contener otros tipos dentro de ellos. Esta restricción se eliminó en RFC 7158, donde se redefinió un texto JSON como cualquier valor serializado.
Los números en JSON son independientes con respecto a su representación dentro de los lenguajes de programación. Si bien esto permite serializar números de precisión arbitraria , puede generar problemas de portabilidad. Por ejemplo, dado que no se hace ninguna diferenciación entre valores enteros y de punto flotante, algunas implementaciones pueden tratar a 42, 42.0y 4.2E+1como el mismo número, mientras que otras no. El estándar JSON no exige requisitos con respecto a detalles de implementación como desbordamiento , desbordamiento insuficiente , pérdida de precisión, redondeo o ceros con signo , pero recomienda no esperar más que la precisión IEEE 754 binario64 para una "buena interoperabilidad". No hay pérdida de precisión inherente al serializar una representación binaria a nivel de máquina de un número de punto flotante (como binario64) en una representación decimal legible por humanos (como números en JSON) y viceversa, ya que existen algoritmos publicados para hacer esto exactamente. y de forma óptima. [25]
Los comentarios se excluyeron intencionalmente de JSON. En 2012, Douglas Crockford describió su decisión de diseño de la siguiente manera: "Eliminé los comentarios de JSON porque vi que la gente los usaba para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad". [24]
JSON no permite "comas finales", una coma después del último valor dentro de una estructura de datos. [26] Las comas finales son una característica común de los derivados JSON para mejorar la facilidad de uso. [27]
Si bien JSON proporciona un marco sintáctico para el intercambio de datos, el intercambio de datos inequívoco también requiere un acuerdo entre el productor y el consumidor sobre la semántica del uso específico de la sintaxis JSON. [28] Un ejemplo de dónde es necesario dicho acuerdo es la serialización de tipos de datos definidos por la sintaxis de JavaScript que no forman parte del estándar JSON, por ejemplo, Fecha, Función, Expresión regular y undefined. [29]
RFC 8259 describe ciertos aspectos de la sintaxis JSON que, si bien son legales según las especificaciones, pueden causar problemas de interoperabilidad.
En 2015, el IETF publicó RFC7493, que describe el "Formato de mensaje I-JSON", un perfil restringido de JSON que restringe la sintaxis y el procesamiento de JSON para evitar, en la medida de lo posible, estos problemas de interoperabilidad.
El tipo MIME oficial para texto JSON es " application/json", [30] y la mayoría de las implementaciones modernas lo han adoptado. El tipo MIME no oficial " text/json" o el tipo de contenido " text/javascript" también son compatibles por motivos heredados con muchos proveedores de servicios, navegadores, servidores, aplicaciones web, bibliotecas, marcos y API. Ejemplos notables incluyen la API de búsqueda de Google, [31] Yahoo!, [31] [32] Flickr, [31] API de Facebook, [33] Lift framework , [34] y Dojo Toolkit 0.4. [35]
JSON Schema especifica un formato basado en JSON para definir la estructura de los datos JSON para validación, documentación y control de interacción. Proporciona un contrato para los datos JSON requeridos por una aplicación determinada y cómo se pueden modificar esos datos. [36] El esquema JSON se basa en los conceptos del esquema XML (XSD), pero está basado en JSON. Al igual que en XSD, se pueden utilizar las mismas herramientas de serialización/deserialización tanto para el esquema como para los datos, y es autodescriptivo. Se especifica en un borrador de Internet en el IETF, actualmente en borrador 2020-12, que se publicó el 28 de enero de 2021. [37] Hay varios validadores disponibles para diferentes lenguajes de programación, [38] cada uno con diferentes niveles de conformidad. La extensión de nombre de archivo estándar es .json. [39]
El estándar JSON no admite referencias a objetos , pero existe un borrador de estándar del IETF para referencias a objetos basados en JSON. [40]
JSON-RPC es un protocolo de llamada a procedimiento remoto (RPC) construido en JSON, como reemplazo de XML-RPC o SOAP . Es un protocolo simple que define solo un puñado de tipos de datos y comandos. JSON-RPC permite que un sistema envíe notificaciones (información al servidor que no requiere respuesta) y múltiples llamadas al servidor que pueden responderse fuera de orden.
JavaScript asíncrono y JSON (o AJAJ) se refieren a la misma metodología de página web dinámica que Ajax , pero en lugar de XML , JSON es el formato de datos. AJAJ es una técnica de desarrollo web que proporciona la capacidad de una página web de solicitar nuevos datos después de haberlos cargado en el navegador web . Normalmente, genera nuevos datos del servidor en respuesta a las acciones del usuario en esa página web. Por ejemplo, lo que el usuario escribe en un cuadro de búsqueda , el código del lado del cliente lo envía al servidor, que responde inmediatamente con una lista desplegable de elementos coincidentes de la base de datos .
JSON ha visto un uso ad hoc como lenguaje de configuración . Sin embargo, no admite comentarios . En 2012, Douglas Crockford, creador de JSON, dijo lo siguiente sobre los comentarios en JSON cuando se usan como lenguaje de configuración: "Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así. Supongamos que estás usando JSON para mantener archivos de configuración, que le gustaría anotar. Continúe e inserte todos los comentarios que desee. Luego, canalícelos a través de JSMin [41] antes de entregárselos a su analizador JSON". [24]
MongoDB utiliza datos similares a JSON para su base de datos orientada a documentos .
Algunas bases de datos relacionales, como PostgreSQL y MySQL, han agregado soporte para tipos de datos JSON nativos. Esto permite a los desarrolladores almacenar datos JSON directamente en una base de datos relacional sin tener que convertirlos a otro formato de datos.
El hecho de que JSON sea un subconjunto de JavaScript puede llevar a la idea errónea de que es seguro pasar textos JSON a la eval()función de JavaScript. Esto no es seguro debido a que ciertos textos JSON válidos, específicamente aquellos que contienen U+2028 LINE SEPARATOR o U+2029 PARAGRAPH SEPARATOR , no son código JavaScript válido hasta que las especificaciones de JavaScript se actualizaron en 2019, por lo que es posible que los motores más antiguos no lo admitan. [42] Para evitar los muchos problemas causados por la ejecución de código arbitrario desde Internet, se agregó por primera vez una nueva función a la quinta edición de ECMAScript, [43] que a partir de 2017 es compatible con todos los principales navegadores. Para los navegadores no compatibles, Douglas Crockford proporciona una biblioteca JavaScript compatible con API . [44] Además, la propuesta TC39 "Subsume JSON" convirtió a ECMAScript en un superconjunto JSON estricto a partir de la revisión de 2019 del lenguaje. [20] [21]
Varias implementaciones de analizadores JSON han sufrido ataques de denegación de servicio y vulnerabilidades de asignación masiva . [45] [46] JSON.parse()
JSON se promociona como una alternativa económica a XML, ya que ambos formatos tienen un amplio soporte para la creación, lectura y decodificación en las situaciones del mundo real en las que se utilizan habitualmente. [47] Además de XML, los ejemplos podrían incluir CSV y superconjuntos de JSON. Los buffers de protocolo de Google pueden cumplir esta función, aunque no es un lenguaje de intercambio de datos. CBOR tiene un superconjunto de tipos de datos JSON, pero no está basado en texto.
XML se ha utilizado para describir datos estructurados y serializar objetos. Existen varios protocolos basados en XML para representar el mismo tipo de estructuras de datos que JSON para el mismo tipo de fines de intercambio de datos. Los datos se pueden codificar en XML de varias formas. La forma más amplia que utiliza pares de etiquetas da como resultado una representación mucho mayor (en número de caracteres) que JSON, pero si los datos se almacenan en atributos y en forma de 'etiqueta corta' donde la etiqueta de cierre se reemplaza con />, la representación suele tener aproximadamente el mismo tamaño. como JSON o simplemente un poco más grande. Sin embargo, un atributo XML sólo puede tener un valor único y cada atributo puede aparecer como máximo una vez en cada elemento.
XML separa "datos" de "metadatos" (mediante el uso de elementos y atributos), mientras que JSON no tiene ese concepto.
Otra diferencia clave es el tratamiento de los valores. JSON tiene objetos con una simple asignación de "clave" a "valor", mientras que en XML el direccionamiento ocurre en "nodos", todos los cuales reciben una identificación única a través del procesador XML. Además, el estándar XML define un atributo común xml:id, que puede ser utilizado por el usuario, para establecer una ID explícitamente.
Los nombres de etiquetas XML no pueden contener ninguno de los caracteres !"#$%&'()*+,/;<=>?@[\]^`{|}~, ni un carácter de espacio, y no pueden comenzar con -, .o un dígito numérico, mientras que las claves JSON sí pueden (incluso si se deben usar comillas y barras invertidas). [48]
Los valores XML son cadenas de caracteres , sin seguridad de tipos incorporada . XML tiene el concepto de esquema , que permite tipificación segura, tipos definidos por el usuario, etiquetas predefinidas y estructura formal, lo que permite la validación formal de una secuencia XML. JSON tiene varios tipos integrados y tiene un concepto de esquema similar en JSON Schema.
XML admite comentarios, mientras que JSON no. [49] [24]
Se ha considerado útil la compatibilidad con comentarios y otras funciones, lo que ha llevado a la creación de varios superconjuntos JSON no estándar. Entre ellos se encuentran HJSON, [50] HOCON y JSON5 (que a pesar de su nombre, no es la quinta versión de JSON). [51] [52]
YAML versión 1.2 es un superconjunto de JSON; Las versiones anteriores no eran estrictamente compatibles. Por ejemplo, escapar de una barra /con una barra invertida \es válido en JSON, pero no en YAML. [53] YAML admite comentarios, mientras que JSON no. [53] [51] [24]
CSON ("notación de objetos de escritura cursiva") se define como pequeñas adiciones gramaticales a la gramática ABNF de JSON especificada por RFC 4627. Al igual que YAML, es un superconjunto estricto de JSON. A diferencia de YAML, todos los datos CSON se pueden traducir a JSON de un lado a otro, por lo que se puede seguir usando una biblioteca que solo entiende JSON y no es necesario traducir el JSON existente. Además de dicha equivalencia JSON, las consideraciones de diseño fueron: [54]
Existen bibliotecas para C, JavaScript, Python y Rust.
HOCON ("Notación de objetos de configuración optimizada para humanos" es un formato para datos legibles por humanos y un superconjunto de JSON. [55] Los usos de HOCON son:
JSON5 ("Formato de intercambio de datos JSON5") es una extensión de la sintaxis JSON que, al igual que JSON, también es una sintaxis JavaScript válida. La especificación se inició en 2012 y finalizó en 2018 con la versión 1.0.0. [66] Las principales diferencias con la sintaxis JSON son:
La sintaxis JSON5 es compatible con algunos programas como extensión de la sintaxis JSON, por ejemplo en SQLite . [67]
JSONC (JSON con comentarios) es un subconjunto de JSON5 y lo utiliza principalmente Microsoft:
//) y comentarios en bloque ( /* */)Se han creado varios formatos de serialización a partir de la especificación JSON. Ejemplos incluyen
{{cite journal}}: Citar diario requiere |journal=( ayuda )En 1996, Macromedia lanza la tecnología Flash que ocupa el espacio dejado por Java y ActiveX, convirtiéndose en el estándar de facto para la animación en el lado del cliente.
Se basa en un subconjunto del lenguaje de programación JavaScript, estándar ECMA-262, tercera edición, diciembre de 1999.
2017-12-13 [...] RFC publicado
Tipo: RFC - Estándar de Internet (diciembre de 2017; Erratas);
Obsoleto RFC 7159;
También conocido como ETS 90.
JSON es un subconjunto de la notación literal de objetos de JavaScript.
La sintaxis JSON no impone ninguna restricción a las cadenas utilizadas como nombres, no requiere que las cadenas de nombres sean únicas y no asigna ningún significado al orden de los pares nombre/valor.
Eliminé los comentarios de JSON porque vi que la gente los usaba para mantener directivas de análisis, una práctica que habría destruido la interoperabilidad.
Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así.
Suponga que está utilizando JSON para guardar archivos de configuración que le gustaría anotar.
Continúe e inserte todos los comentarios que desee.
Luego, canalícelo a través de
JSMin
antes de entregárselo a su analizador JSON.
La sintaxis JSON no es una especificación de un intercambio de datos completo.
El intercambio de datos significativo requiere un acuerdo entre un productor y un consumidor sobre la semántica asociada a un uso particular de la sintaxis JSON.
Lo que JSON sí proporciona es el marco sintáctico al que se puede adjuntar dicha semántica.
JSMin [2001] es una herramienta de minificación que elimina comentarios y espacios en blanco innecesarios de archivos JavaScript.
para la representación de datos, puede elegir uno de los siguientes: YAML, YAMLEX, JSON, JSON5, HJSON o incluso Python puro
El objetivo principal es: mantener la semántica (estructura de árbol; conjunto de tipos; codificación/escapado) de JSON, pero hacerlo más conveniente como formato de archivo de configuración editable por humanos.
Definiciones de Wikcionario
Medios de los comunes
Libros de texto de Wikilibros