JSON

"Json" vuelve a dirigir aquí. Para personas con nombres similares, consulte J Son.

Notación de objetos JavaScript
JSON vector logo.svg
Extensión de nombre de archivo . json
Tipo de medio de Internet aplicación / json
Código de tipo TEXTO
Identificador de tipo uniforme (UTI) public.json
Tipo de formato Intercambio de datos
Extendido desde JavaScript
Estándar STD 90 ( RFC   8259 ), ECMA-404, ISO / IEC 21778: 2017
¿ Formato abierto ?
Sitio web json.org

JSON ( JavaScript Object Notation, pronunciado / dʒ eɪ s ən / ; también / dʒ eɪ ˌ s ɒ n / ) es un estándar abierto de formato de archivo y el intercambio de datos de formato que utiliza legible de texto para almacenar y transmitir datos de objetos que consiste en pares y matrices de atributo-valor (u otros valores serializables ). Es un formato de datos común con una amplia gama de funciones en el intercambio de datos, incluida la comunicación 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 archivo JSON usan la extensión .json.

Douglas Crockford originalmente especificó el formato JSON a principios de la década de 2000.

Contenido
  • 1 Denominación y pronunciación
  • 2 Normas
  • 3 Historia
  • 4 sintaxis
    • 4.1 Codificación de caracteres
    • 4.2 Tipos de datos
    • 4.3 Semántica
  • 5 Metadatos y esquema
  • 6 usos
  • 7 Comparación con otros formatos
    • 7.1 YAML
    • 7.2 XML
  • 8 Derivados
  • 9 Véase también
  • 10 referencias
  • 11 Enlaces externos

Naming y pronunciación

El acrónimo se originó en State Software, una empresa cofundada por Douglas Crockford y otros en marzo de 2001.

Los 2017 estándar internacional (ECMA-404 e ISO / IEC 21778: 2017) especifica "pronunciado / dʒ eɪ. S ə n /, como en ' Jason y los argonautas ' ". La primera edición (2013) de ECMA-404 no abordó la pronunciación. 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". Crockford dijo en 2011: "Hay muchas discusiones sobre cómo se pronuncia eso, pero estrictamente no me importa".

Estándares

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. RFC   8259, publicado en 2017, es la versión actual del estándar de Internet STD 90 y sigue siendo coherente con ECMA-404. Ese mismo año, JSON también se estandarizó como ISO / IEC 21778: 2017. Los estándares ECMA e ISO describen solo la sintaxis permitida, mientras que el RFC cubre algunas consideraciones de seguridad e interoperabilidad.

Historia

Douglas Crockford en el edificio de Yahoo (2007)

JSON surgió de la necesidad de un protocolo de comunicación de servidor a navegador sin estado y en tiempo real sin utilizar complementos de navegador como Flash o subprogramas de Java, los métodos dominantes utilizados a principios de la década de 2000.

Se usó un precursor de las bibliotecas JSON en un proyecto de juego de intercambio de activos digitales para niños llamado Cartoon Orbit en Communities.com (en el que los cofundadores de State Software habían trabajado anteriormente) para Cartoon Network, que usó un complemento del lado del navegador con un formato de mensajería patentado para manipular elementos HTML dinámicos (este sistema también es propiedad de 3DO). 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, obteniendo aplicaciones web ricas en tiempo real utilizando solo las capacidades estándar de HTTP, HTML y JavaScript. de Netscape 4.0.5+ e IE 5+.

Crockford primero especificó y popularizó el formato JSON. Los cofundadores de State Software acordaron construir un sistema que usaba capacidades de navegador estándar y proporcionaba 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 reciclarlos antes de que se agoten los tiempos de espera estándar del navegador si no se intercambiaron 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 el tipo de licencia para que esté disponible. Chip Morningstar desarrolló la idea del marco de aplicación estatal en State Software.

El sistema se vendió a Sun Microsystems, Amazon.com y EDS. El sitio web JSON.org se lanzó en 2002. En diciembre de 2005, Yahoo! comenzó a ofrecer algunos de sus servicios web en JSON.

JSON se basó en un subconjunto del lenguaje de scripting JavaScript (específicamente, Standard ECMA -262 3rd Edition — December 1999) 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. Ese mismo año, RFC   7158 usó ECMA-404 como referencia. En 2014, RFC   7159 se convirtió en la principal referencia para los usos de Internet de JSON, 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 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.

Crockford agregó una cláusula a la licencia JSON que establece que "el software se utilizará 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 dio lugar a problemas de compatibilidad de licencias de la licencia JSON con otras licencias de código abierto, ya que el software de código abierto y el software libre generalmente no implican restricciones en el propósito de uso.

Sintaxis

El siguiente ejemplo muestra una posible representación JSON que describe a una persona.

{ "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 27, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021-3100" }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "office", "number": "646 555-4567" } ], "children": [], "spouse": null }

Codificación de caracteres

Aunque Crockford originalmente afirmó y creía que JSON es un subconjunto estricto de JavaScript y ECMAScript, su especificación realmente 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. Esto es una consecuencia de JSON que no permite solo "caracteres de control". Para una máxima portabilidad, estos caracteres deben tener un escape de barra invertida.

El intercambio JSON en un ecosistema abierto debe estar codificado en UTF-8. La codificación admite el conjunto completo de caracteres Unicode, incluidos los caracteres fuera del plano multilingüe básico (U + 10000 a U + 10FFFF). Sin embargo, si se escapa, esos caracteres deben escribirse utilizando pares sustitutos UTF-16. Por ejemplo, para incluir el carácter Emoji U + 1F610 😐 NEUTRAL FACE en JSON:

{ "face": "😐" } // or { "face": "\uD83D\uDE10" }

JSON se convirtió en un subconjunto estricto de ECMAScript a partir de la revisión de 2019 del idioma.

Tipos de datos

Los tipos de datos básicos de JSON son:

  • Número: un número decimal con signo que puede contener una parte fraccionaria y puede usar notación E exponencial, pero no puede incluir no números como NaN. El formato no distingue entre entero y punto flotante. JavaScript usa un formato de punto flotante de doble precisión para todos sus valores numéricos (hasta más adelante también es compatible con BigInt ), pero otros lenguajes que implementan JSON pueden codificar números de manera diferente.
  • Cadena : una secuencia de cero o más caracteres Unicode. Las cadenas están delimitadas con comillas dobles y admiten una sintaxis de escape de barra invertida.
  • Booleano : cualquiera de los valores trueofalse
  • Array : una lista ordenada de cero o más elementos, cada uno de los cuales puede ser de cualquier tipo. Las matrices utilizan la notación de corchetes con elementos separados por comas.
  • Objeto : una colección de pares de nombre-valor donde los nombres (también llamados claves) son cadenas. Los objetos están destinados a representar matrices asociativas, donde cada clave es única dentro de un objeto. Los objetos se delimitan con llaves y usan comas para separar cada par, mientras que dentro de cada par, el carácter de dos puntos ':' separa la clave o el nombre de su valor.
  • null : un valor vacío, usando la palabra null

Se permiten e 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, salto 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.

Las primeras versiones de JSON (como las especificadas por RFC   4627 ) requerían que un texto JSON válido debe consistir solo 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 un texto JSON se redefinió como cualquier valor serializado.

Los números en JSON son agnósticos 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 dar lugar a problemas de portabilidad. Por ejemplo, ya no se hace ninguna diferenciación entre los valores enteros y de coma flotante, algunas implementaciones pueden tratar 42, 42.0y 4.2E+1como el mismo número, mientras que otros no. El estándar JSON no establece requisitos con respecto a detalles de implementación como desbordamiento, subdesbordamiento, pérdida de precisión, redondeo o ceros con signo, pero recomienda no esperar más que la precisión 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 números en JSON), y viceversa, ya que existen algoritmos publicados para hacer esto exactamente y de forma óptima.

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".

JSON no permite las "comas finales", una coma después del último valor dentro de una estructura de datos. Las comas finales son una característica común de los derivados JSON para mejorar la facilidad de uso.

Semántica

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. 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.

Metadatos y esquema

El tipo oficial de MIME para el texto JSON es " application/json", y la mayoría de las implementaciones modernas lo han adoptado. Muchos proveedores de servicios, navegadores, servidores, aplicaciones web, bibliotecas, marcos y API también admiten el tipo MIME no oficial " text/json" o el tipo de contenido " text/javascript" por motivos heredados. Ejemplos notables incluyen la API de búsqueda de Google, Yahoo !, Flickr, la API de Facebook, el marco Lift y Dojo Toolkit 0.4.

JSON Schema especifica un formato basado en JSON para definir la estructura de 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. JSON Schema se basa en los conceptos de XML Schema (XSD), pero está basado en JSON. Como en XSD, las mismas herramientas de serialización / deserialización se pueden usar 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. Hay varios validadores disponibles para diferentes lenguajes de programación, cada uno con diferentes niveles de conformidad. No hay una extensión de nombre de archivo estándar.

El estándar JSON no admite referencias a objetos, pero existe un borrador de estándar IETF para referencias a objetos basados ​​en JSON. El Dojo Toolkit admite referencias a objetos utilizando JSON estándar; específicamente, el dojox.json.refmódulo proporciona soporte para varias formas de referencia, incluidas referencias circulares, múltiples, entre mensajes y diferidas. Internamente, ambos lo hacen asignando una "$ref"clave para dichas referencias y resolviéndola en tiempo de análisis; el borrador de IETF solo especifica la sintaxis de la URL, pero Dojo permite más. Alternativamente, existen soluciones no estándar como el uso de variables de Sharp de JavaScript de Mozilla. Sin embargo, esta funcionalidad quedó obsoleta con JavaScript 1.8.5 y se eliminó en la versión 12 de Firefox.

Usos

JSON-RPC es un protocolo de llamada a procedimiento remoto (RPC) construido sobre 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 una respuesta) y múltiples llamadas al servidor que se pueden responder fuera de servicio.

JavaScript asincrónico 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 para solicitar nuevos datos después de que se haya cargado en el navegador web. Por lo general, 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.

Si bien JSON es un formato de serialización de datos, se ha utilizado ad hoc como lenguaje de configuración. En este caso de uso, se ha considerado útil la compatibilidad con comentarios y otras características, lo que ha llevado a la creación de varios superconjuntos JSON no estándar. Entre ellos se encuentran HJSON, HOCON y JSON5 (que a pesar de su nombre, no es la quinta versión de JSON). El objetivo principal de la versión 1.2 de YAML era convertir el formato no estándar en un superconjunto JSON estricto.

En 2012, Douglas Crockford dijo lo siguiente sobre los comentarios en JSON cuando se usa como lenguaje de configuración: "Sé que la falta de comentarios entristece a algunas personas, pero no debería ser así. Suponga que está usando JSON para mantener los archivos de configuración, que le gustaría hacer anotaciones. Continúe e inserte todos los comentarios que desee. Luego, envíelo a través de JSMin antes de entregárselo a su analizador JSON ".

JSON está diseñado como un formato de serialización de datos. Sin embargo, su diseño como un subconjunto de JavaScript puede llevar a la idea errónea de que es seguro pasar textos JSON a la función JavaScript. Esto no es seguro, debido a ciertos textos JSON válidos, especialmente los que contienen U + 2028 línea de separación o U + 2029 separador de párrafos, no siendo válida hasta el código JavaScript especificaciones de JavaScript se actualizaron en 2019, por lo que los motores más antiguos no sean compatibles con ella. Para evitar las muchas trampas causadas 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, que a partir de 2017 es compatible con todos los principales navegadores. Para los navegadores no compatibles, Douglas Crockford proporciona una biblioteca de JavaScript compatible con API. Además, la propuesta de TC39 "Subsume JSON" convirtió a ECMAScript en un superconjunto JSON estricto a partir de la revisión de 2019 del lenguaje. eval() JSON.parse()

Varias implementaciones de analizador JSON han sufrido ataques de denegación de servicio y vulnerabilidad de asignación masiva.

Comparación con otros formatos

Ver también: Comparación de formatos de serialización de datos

JSON se promociona como una alternativa de bajo costo para XML, ya que ambos formatos tienen un soporte generalizado para la creación, lectura y decodificación en situaciones del mundo real donde se usan comúnmente. Además de XML, los ejemplos podrían incluir CSV y YAML (un superconjunto de JSON). Además, los búferes de protocolo de Google pueden cumplir esta función, aunque no es un lenguaje de intercambio de datos.

YAML

YAML versión 1.2 es un superconjunto de JSON; las versiones anteriores no eran estrictamente compatibles. Por ejemplo, escapar de una barra inclinada /con una barra invertida \es válido en JSON, pero no lo era en YAML. YAML admite comentarios, mientras que JSON no.

XML

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 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 más grande que JSON, pero si los datos se almacenan en atributos y en forma de 'etiqueta corta' donde se reemplaza la etiqueta de cierre /gt;, la representación suele tener aproximadamente el mismo tamaño que JSON o simplemente una un poco más grande. Sin embargo, un atributo XML solo 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 tal concepto.

Otra diferencia clave es el direccionamiento de 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 un ID de forma explícita.

Nombres de las etiquetas XML no puede contener ninguno de los caracteres !"#$%amp;'()*+,/;lt;=gt;?@[\]^`{|}~, ni un carácter de espacio, y no pueden comenzar con -, .o un dígito numérico, mientras que las teclas pueden JSON (incluso si comillas y barra invertida deben escaparse).

Los valores XML son cadenas de caracteres, sin seguridad de tipos incorporada. XML tiene el concepto de esquema, que permite tipado fuerte, tipos definidos por el usuario, etiquetas predefinidas y estructura formal, lo que permite la validación formal de un flujo XML. JSON tiene una escritura fuerte incorporada y tiene un concepto de esquema similar en JSON Schema.

XML admite comentarios, mientras que JSON no.

Derivados

Se han creado varios formatos de serialización a partir de la especificación JSON. Los ejemplos incluyen GeoJSON, JSON-LD, Smile (formato de intercambio de datos), UBJSON, JSON-RPC, JsonML y JSON → URL.

Ver también

Referencias

enlaces externos

Contactos: mail@wikibrief.org
El contenido está disponible bajo la licencia CC BY-SA 3.0 (a menos que se indique lo contrario).