JSON ( JavaScript Object Notation , pronunciado / ˈdʒeɪsən / o / ˈ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 nombre-valor y matrices (u otros valores serializables ). Es un formato de datos de uso común 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 lenguaje . 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 archivo 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 'Jasón 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 afirma : " Douglas Crockford , quien nombró y promovió el formato JSON, dice que se pronuncia como el nombre Jason. Pero de alguna manera, 'JAY-sawn' [a] parece haberse vuelto más común en la comunidad técnica". [5] Crockford dijo en 2011: "Hay mucha discusión sobre cómo se pronuncia eso, pero estrictamente no me importa". [1]
Después de que RFC 4627 estuviera disponible como su especificación "informativa" desde 2006, JSON se estandarizó por primera vez en 2013, como ECMA -404. [4] RFC 8259, publicada en 2017, es la versión actual del estándar de Internet STD 90, y sigue siendo coherente con ECMA-404. [6] Ese mismo año, JSON también se estandarizó como ISO/IEC 21778:2017. [2] Los estándares ECMA e ISO/IEC describen solo la sintaxis permitida, mientras que RFC cubre algunas consideraciones de seguridad e interoperabilidad. [7]
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 applets de Java , los métodos dominantes utilizados a principios de la década de 2000. [8]
Crockford fue el primero en especificar y popularizar el formato JSON. [1] 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 utilizara las capacidades estándar de los navegadores y proporcionara una capa de abstracción para que los desarrolladores web crearan aplicaciones web con estado que tuvieran una conexión dúplex persistente a un servidor web manteniendo abiertas dos conexiones de Protocolo de transferencia de hipertexto (HTTP) y reciclelas antes de que se agotaran los tiempos de espera estándar de los navegadores si no se intercambiaban más datos. Los cofundadores tuvieron una mesa redonda y votaron sobre si llamar al formato de datos JSML (lenguaje de marcado de JavaScript) o JSON (notación de objetos de JavaScript), así como bajo qué tipo de licencia hacerlo disponible. El sitio web JSON.org [9] se lanzó en 2001. En diciembre de 2005, Yahoo! comenzó a ofrecer algunos de sus servicios web en JSON. [10]
Un precursor de las bibliotecas JSON se utilizó en un proyecto de juego de intercambio de activos digitales para niños llamado Cartoon Orbit en Communities.com [ cita requerida ] (los cofundadores de State habían trabajado todos en esta empresa anteriormente) para Cartoon Network [ cita requerida ] , 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 del usuario sin actualizar el contexto visual de una aplicación web, logrando aplicaciones web enriquecidas en tiempo real utilizando solo las capacidades estándar HTTP, HTML y JavaScript de Netscape 4.0.5+ e Internet Explorer 5+. Luego, Crockford descubrió que JavaScript podía usarse como un 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 programación JavaScript (específicamente, Standard ECMA -262 3rd Edition—December 1999 [11] ) 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 lenguaje.
En octubre de 2013, Ecma International publicó la primera edición de su estándar JSON ECMA-404. [4] Ese mismo año, RFC 7158 utilizó ECMA-404 como referencia. En 2014, RFC 7159 se convirtió en la referencia principal 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 RFC 7159 cuando publicó RFC 8259, que es la versión actual del Estándar de Internet STD 90. [12] [13]
Crockford añadió una cláusula a la licencia JSON que establecía que "el software se utilizará para el bien, no para el mal", con el fin de convertir en código abierto las bibliotecas JSON y, al mismo tiempo, burlarse de los abogados corporativos y de aquellos que son demasiado pedantes. Por otra parte, esta cláusula provocó 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 normalmente no implican restricciones en cuanto al propósito de uso. [14]
El siguiente ejemplo muestra una posible representación JSON que describe a una persona.
{ "nombre" : "John" , "apellido" : "Smith" , "está vivo" : verdadero , "edad" : 27 , "dirección" : { "dirección de la calle" : "21 2nd Street" , "ciudad" : "Nueva York" , "estado" : "NY" , "código postal" : "10021-3100" }, "números de teléfono" : [ { "tipo" : "casa" , "número" : "212 555-1234" }, { "tipo" : "oficina" , "número" : "646 555-4567" } ], "hijos" : [ "Catherine" , "Thomas" , "Trevor" ], "cónyuge" : null } Aunque Crockford afirmó originalmente que JSON es un subconjunto estricto de JavaScript y ECMAScript , [15] su especificación en realidad permite documentos JSON válidos que no son JavaScript válido; 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 anteriores no lo hacen. [16] [17] Esto es una consecuencia de que JSON solo prohíbe los "caracteres de control". Para una máxima portabilidad, estos caracteres deben estar escapados por una barra invertida.
El intercambio de JSON en un ecosistema abierto debe estar codificado en UTF-8 . [6] 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 escapan, esos caracteres deben escribirse utilizando pares sustitutos UTF-16 . Por ejemplo, para incluir el carácter Emoji U+1F610 😐 NEUTRAL FACE en JSON:
{ "cara" : "😐" } // o { "cara" : "\uD83D\uDE10" } JSON se convirtió en un subconjunto estricto de ECMAScript a partir de la revisión del lenguaje de 2019. [17] [18]
Los tipos de datos básicos de JSON son:
trueofalsenull: un valor vacío, utilizando la palabranullSe permiten y se ignoran los espacios en blanco alrededor o entre elementos sintácticos (valores y puntuación, pero no dentro de un valor de cadena). Cuatro caracteres específicos se consideran espacios en blanco para este propósito: 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 . [21]
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 podía contener otros tipos dentro de ellos. Esta restricción se eliminó en RFC 7158, donde un texto JSON se redefinió como cualquier valor serializado.
Los números en JSON son independientes de su representación en los lenguajes de programación. Si bien esto permite serializar números de precisión arbitraria42 , 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 , 42.0, y 4.2E+1como el mismo número, mientras que otras no. El estándar JSON no establece requisitos con respecto a los detalles de implementación, como desbordamiento , desbordamiento insuficiente , pérdida de precisión, redondeo o ceros con signo , pero sí recomienda no esperar una precisión mayor que la de IEEE 754 binary64 para una "buena interoperabilidad". No hay una 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 binary64) en una representación decimal legible por humanos (como los números en JSON) y viceversa, ya que existen algoritmos publicados para hacer esto de manera exacta y óptima. [22]
Los comentarios se excluyeron intencionalmente de JSON. En 2012, Douglas Crockford describió su decisión de diseño de esta manera: "Eliminé los comentarios de JSON porque vi que la gente los estaba usando para contener directivas de análisis, una práctica que habría destruido la interoperabilidad". [21]
JSON no permite "comas finales", una coma después del último valor dentro de una estructura de datos. [23] Las comas finales son una característica común de los derivados de JSON para mejorar la facilidad de uso. [24]
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ó el RFC 7493, que describe el "Formato de mensaje I-JSON", un perfil restringido de JSON que restringe la sintaxis y el procesamiento de JSON para evitar, tanto como sea posible, estos problemas de interoperabilidad.
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. [25] Un ejemplo de dónde es necesario dicho acuerdo es la serialización de tipos de datos que no son parte del estándar JSON, por ejemplo, fechas y expresiones regulares .
El tipo MIME oficial para texto JSON es application/json, [26] y la mayoría de las implementaciones modernas lo han adoptado. Los tipos MIME heredados incluyen text/json, text/x-json, y text/javascript. [27] La extensión de nombre de archivo estándar es .json. [28]
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. [29] JSON Schema se basa en los conceptos de XML Schema (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, y la última versión a partir de 2024 es "Draft 2020-12". [30] Hay varios validadores disponibles para diferentes lenguajes de programación, [31] cada uno con distintos niveles de conformidad.
El estándar JSON no admite referencias a objetos , pero existe un borrador de estándar IETF para referencias a objetos basadas en JSON. [32]
JSON-RPC es un protocolo de llamada a procedimiento remoto (RPC) basado en JSON, que reemplaza a XML-RPC o SOAP . Es un protocolo simple que define solo unos pocos tipos de datos y comandos. JSON-RPC permite que un sistema envíe notificaciones (información al servidor que no requiere una respuesta) y múltiples llamadas al servidor que pueden responderse sin orden.
El JavaScript asincrónico y JSON (o AJAJ) se refieren a la misma metodología de páginas web dinámicas 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 para solicitar nuevos datos después de que se hayan cargado en el navegador web . Por lo general, muestra 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 de la base de datos que coinciden .
JSON ha sido utilizado ad hoc como lenguaje de configuración . Sin embargo, no admite comentarios . En 2012, Douglas Crockford, el creador de JSON, dijo lo siguiente sobre los comentarios en JSON cuando se utiliza como lenguaje de configuración: "Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así. Supongamos que está utilizando JSON para guardar archivos de configuración que le gustaría anotar. Siga adelante e inserte todos los comentarios que desee. Luego, páselos por JSMin [33] antes de entregárselos a su analizador JSON". [21]
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 compatibilidad con 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 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 eran código JavaScript válido hasta que se actualizaron las especificaciones de JavaScript en 2019, por lo que es posible que los motores más antiguos no lo admitan. [34] Para evitar los numerosos 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, [35] que a partir de 2017 es compatible con todos los navegadores principales. Para los navegadores no compatibles, Douglas Crockford proporciona una biblioteca JavaScript compatible con API . [36] 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. [17] [18] Varias implementaciones de analizadores JSON han sufrido ataques de denegación de servicio y vulnerabilidades de asignación masiva . [37] [38] JSON.parse()
JSON se promociona como una alternativa de bajo consumo de recursos 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 comúnmente. [39] Además de XML, los ejemplos podrían incluir CSV y superconjuntos de JSON. Google Protocol Buffers puede cumplir esta función, aunque no es un lenguaje de intercambio de datos. CBOR tiene un superconjunto de los tipos de datos JSON, pero no está basado en texto. Ion también es un superconjunto de JSON, con una gama más amplia de tipos primarios, anotaciones, comentarios y permite comas finales. [40]
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 propósitos de intercambio de datos. Los datos se pueden codificar en XML de varias maneras. La forma más expansiva que utiliza pares de etiquetas da como resultado una representación mucho más grande (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 por />, la representación suele tener aproximadamente el mismo tamaño que JSON o solo un poco más grande. Sin embargo, un atributo XML solo puede tener un único valor y cada atributo puede aparecer como máximo una vez en cada elemento.
XML separa los "datos" de los "metadatos" (mediante el uso de elementos y atributos), mientras que JSON no tiene ese concepto.
Otra diferencia clave es el direccionamiento de los valores. JSON tiene objetos con una simple asignación de "clave" a "valor", mientras que en XML el direccionamiento se produce en "nodos", que reciben todos un identificador único 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 un identificador de forma explícita.
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 las comillas y la barra invertida deben escaparse). [41]
Los valores XML son cadenas de caracteres sin seguridad de tipos incorporada . XML tiene el concepto de esquema , que permite tipificación estricta, tipos definidos por el usuario, etiquetas predefinidas y estructura formal, lo que permite la validación formal de un flujo XML. JSON tiene varios tipos incorporados y tiene un concepto de esquema similar en JSON Schema.
XML admite comentarios, mientras que JSON no. [42] [21]
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, [43] HOCON y JSON5 (que a pesar de su nombre, no es la quinta versión de JSON). [44] [45]
La versión 1.2 de YAML es un superconjunto de JSON; las versiones anteriores no eran estrictamente compatibles. Por ejemplo, escapar una barra /con una barra invertida \es válido en JSON, pero no lo era en YAML. [46] YAML admite comentarios, mientras que JSON no. [46] [44] [21]
CSON (" CoffeeScript Object Notation") utiliza sangría significativa , claves sin comillas y asume una declaración de objeto externa. Se utilizó para configurar el editor de texto Atom de GitHub . [47] [48] [49]
También existe un proyecto no relacionado llamado CSON ("Cursive Script Object Notation") que es sintácticamente más similar a JSON. [50]
HOCON ("Human-Optimized Config Object Notation") es un formato para datos legibles por humanos y un superconjunto de JSON. [51] Los usos de HOCON son:
JSON5 ("JSON5 Data Interchange Format") es una extensión de la sintaxis JSON que, al igual que JSON, también es una sintaxis válida para JavaScript. La especificación se inició en 2012 y finalizó en 2018 con la versión 1.0.0. [62] Las principales diferencias con la sintaxis JSON son:
La sintaxis JSON5 es compatible con algunos programas como una extensión de la sintaxis JSON, por ejemplo en SQLite . [63]
JSONC (JSON con comentarios) es un subconjunto de JSON5 utilizado en Visual Studio Code de Microsoft : [64]
//) y comentarios de bloque ( /* */)Se han creado varios formatos de serialización a partir de la especificación JSON. Algunos ejemplos incluyen:
{{cite journal}}: Requiere citar revista |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, 3.ª edición, diciembre de 1999.
2017-12-13 [...] RFC publicado
Tipo: RFC - Estándar de Internet (diciembre de 2017; Errata); Obsoleto RFC 7159; También conocido como STD 90
JSON es un subconjunto de la notación literal de objeto de JavaScript.
Eliminé los comentarios de JSON porque vi que la gente los usaba para guardar 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í. Supongamos que está usando JSON para guardar archivos de configuración, que le gustaría anotar. Siga adelante e inserte todos los comentarios que desee. Luego, páselos por
JSMin
antes de entregárselos a su analizador JSON.
JSMin [2001] es una herramienta de minimización que elimina comentarios y espacios en blanco innecesarios de los 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/escape) de JSON, pero hacerlo más conveniente como un formato de archivo de configuración editable por humanos.
Definiciones de Wikcionario
Medios de comunicación de Commons
Libros de texto de Wikilibros