Archivos JSON

¿Qué es un archivo .JSON?

Los archivos .json normalmente consisten en JavaScript Object Notation, que es una serialización de texto plano independiente del lenguaje que se usa para crear pares nombre/valor. ECMA-404 y el RFC 8259 del IETF especifican hoy su uso después de la adopción generalizada de JSON durante los años 2000, cuando Douglas Crockford introdujo su especificación. El RFC 8259 define un texto .json como no necesariamente estructurado de forma fija en el nivel raíz, ya que la entidad JSON de nivel superior podría ser cualquier objeto, una secuencia ordenada, una cadena, un número, un valor Boolean o un valor null. Por lo tanto, las extensiones de archivo .json existen en API web, configuración de aplicaciones, paquetes de software, registros, archivos de exportación, partidas guardadas de juegos, entre otros.

Varios formatos similares también hacen uso de esta extensión. Los archivos JSON-LD podrían usar .json cuando contienen términos de datos enlazados como "@context", "@id" y "@type", y prefieren otra extensión llamada .jsonld. Los datos GeoJSON podrían almacenarse tanto con .json como con otra extensión común llamada .geojson, pero deberían contener algunos términos clave como type, Feature, FeatureCollection, geometry, coordinates, properties, etc. Otro formato llamado JSON Text Sequences del IETF incluye cada texto JSON precedido por el byte específico 0x1E (record separator) en cada texto, así que estos datos se transmiten en flujo, no se editan manualmente.

Esto significa que, para este grupo de extensiones, abrir un archivo en el editor de texto y examinar las palabras clave específicas del dominio es una de las formas más rápidas.

Cómo abrir un archivo .JSON

Detalles técnicos

En esencia el formato JSON es un archivo de texto plano y no binario. Los archivos .json aleatorios no tienen ningún valor de números mágicos; no pueden tener ninguna estructura de encabezado/pie de archivo fijo; no tienen compatibilidad con una jerarquía de carpetas incorporada; y tampoco tienen funciones de compresión de la estructura de archivos. El tipo MIME típico para JSON es: application/json. Formatos de archivos relacionados con JSON son: application/ld+json (JSON-LD); application/geo+json (GeoJSON); y application/json-seq (Secuencias de texto JSON).

El modelo de datos para JSON según RFC 8259: objetos, arreglos, cadenas, números, verdadero, falso y nulo. Todas las claves para los miembros de un objeto se almacenan únicamente como cadenas. Se aceptan espacios en blanco fuera de las comillas: generalmente espacios en blanco (espacios, tabulaciones, etc). Los comentarios y las comas finales están prohibidos en el formato JSON; se pueden especificar secuencias de escape de los caracteres por: \t, ", \\, \uXXXX, \n. La representación a través del uso del valor de punto de código en UTF-8 también está apoyada en los datos de cadena de un formato de archivo. Los números apoyan representaciones de literales numéricos decimales. Sólo. No NaN/Infinitos en JSON.

Mediante RFC 8259 el intercambio de datos entre sistemas usando JSON tiene que realizarse usando la codificación de caracteres UTF-8. Aunque, analizadores más antiguos podrían poder analizar texto en formatos como: UTF-16, UTF-32 siempre y cuando se utilice correctamente la Marca de Orden de Bytes para determinar la codificación correcta. Debido al hecho de que los archivos .json de JSON carecen de una estructura de encabezado-pie fijo no hay forma de indicar el primer byte significativo. Las Secuencias de texto JSON emplean el uso del carácter RS y como resultado el archivo puede comenzar con el valor de byte 0x1E cuando el primer elemento se coloque justo después de este separador en una secuencia.

El formato JSON no ofrece ningún esquema específico del archivo ni un área de metadatos y tampoco contiene información de versión. Debido a RFC 8259 y la segunda edición de las especificaciones ECMA-404 JSON se considera como una sintaxis estable y existen perfiles de JSON con respecto a JSON-LD 1.1 y el formato GeoJSON. Las implementaciones de analizadores pueden usar las siguientes políticas diferentes para el apoyo de miembros de objetos duplicados, la precisión de la representación numérica y los rangos de enteros. También dependiendo de los casos de uso el tamaño de un archivo JSON puede abarcar desde varios bytes hasta varios gigabytes.

Cómo convertir archivos .JSON

La impresión legible y la minimización de valores JSON no provocan pérdida de información, ya que solo alteran el espacio en blanco de esos archivos. Si hace falta para validación o para revisión, se podría usar python -m json.tool input.json output.json para lo mismo en Python, mientras que jq -c . input.json > output.json funcionaría para reducir el espacio en blanco innecesario y obtener tamaños más pequeños.

El archivo CSV se puede producir fácilmente si la entrada es un arreglo de objetos con un solo nivel. También se podría hacer mediante el siguiente patrón: jq -r '(.[] | keys_unsorted) as $keys | $keys, (.[] | [.[$keys[]]]) | @csv' input.json > output.csv. El uso de YAML sería una buena solución, ya que el formato admite JSON de forma nativa como subconjunto de YAML versión 1.2.

Con yq -P -o=yaml input.json > output.yaml se reescribiría toda la estructura de datos, mientras que no hay forma de añadir anclajes ni comentarios a YAML a partir de una fuente en formato JSON. También es posible realizar la conversión al formato XML usando la biblioteca necesaria, aunque los arreglos, los espacios de nombres, los atributos o el contenido mixto requerirían una regla de mapeo aparte. Eso podría llevar a una pérdida de información durante el proceso de traducción de vuelta.

Las siguientes herramientas podrían usarse para traducir a GeoPackage, KML, Shapefile, PostGIS, entre otros formatos: ogr2ogr. JSON-LD podría reescribirse como Turtle, N-Quads, expanded, compacted y RDF/XML usando el software correspondiente. Para convertir un archivo JSON a Excel, primero debería normalizarse como una tabla rectangular, ya que cambiar solo los nombres no ayudaría en absoluto.

Problemas comunes y soluciones

La mayoría de los errores comunes de JSON suelen significar que algo está mal con la sintaxis. En JavaScript, el error "unexpected token" suele significar que hay algunos JSON no válidos, como páginas de error HTML con extensión .json, comentarios o una coma final después del último elemento. El error “Expecting property name enclosed in double quotes” suele significar que tu archivo no se escribió como JSON, sino como JavaScript Object Literal, sin poner comillas a las claves de las cadenas, lo cual está prohibido por la sintaxis de RFC 8259.

Los errores "Extra Data" y "Multiple JSON Values" aparecen cuando algún parser espera solo un JSON completo y estás trabajando con un archivo JSON con una entrada por línea o con un archivo JSON Text Sequences (RFC 7464). Para corregir este problema, solo encuentra otro parser que pueda reconocer estos formatos, o simplemente divide esos registros antes de importarlos. A veces aparecen problemas de codificación por el reemplazo de caracteres, un error de análisis alrededor de la marca BOM y cosas como caracteres de control en las cadenas. Intenta volver a guardar los archivos en formato UTF-8 y eliminar esos bytes ilegales, como marcas de tabulación, saltos de línea y demás.

Cuando .json es bastante grande, puede congelar algunos programas (Visual Studio Code, Chrome, Firefox, online file-viewer, etc.), así que intenta usar herramientas como jq, algunas funciones de procesamiento en streaming del lenguaje Python, algunas utilidades de bases de datos para importar el contenido del archivo JSON sin abrirlo en una GUI, o dividir el archivo JSON. La mayoría de los parsers aceptan la clave duplicada de un objeto, pero conservan solo la última, así que valida la fuente antes del procedimiento de importación. Cuando se trata de GeoJSONs, puede abrirse correctamente, pero las coordenadas de los objetos de ese archivo podrían ser incorrectas por el orden erróneo de latitud y longitud o por un CRS incompatible.

Consideraciones de seguridad

JSON no cuenta con funciones como macros, execs, scripts ni código que se ejecute automáticamente en datos de RFC 8259. Sin embargo, JSON puede volverse peligroso si lo lee un parser vulnerable o una aplicación anfitriona debido a deserialización, contaminación de prototipos, inyección de comandos, inyecciones SQL y otros procedimientos dañinos que agotan los recursos del programa y lo vuelven peligroso. Es necesario usar siempre un parser JSON dedicado para evitar pasar JSON a eval - usa JSON.parse, Python json, Jackson/Gson para programas Java, o usa las bibliotecas serde_json y jq.

Un JSON que sea grande o demasiado profundo puede consumir memoria en exceso, provocar desbordamientos de pila y tardar demasiado en analizarse. Por eso hay que imponer máximos en su profundidad y en el tiempo de validación, y también usar un análisis estricto en caso de que no quieras que se usen funciones JSON desconocidas. El contenido de JSON puede incluir secretos como claves API, tokens de acceso, cookies, contraseñas, coordenadas GPS y muchos otros, y GeoJSON también podría incluir coordenadas, así como rutas de viaje y líneas de límite. JSON-LD podría cargar un contexto malicioso cuando se usan contextos no almacenados en caché.

Historia y versiones

"JSON surgió de la notación de literales de objetos de JavaScript y fue promovido por Douglas Crockford alrededor de 2001 y sirvió como un reemplazo fácil de XML." La descripción de json.org contribuyó en gran medida a la rápida adopción de JSON en la generación inicial de aplicaciones AJAX durante la primera mitad de la década que comenzó en el año 2000. En 2006, RFC 4627 definió application/json y limitó un texto JSON a ser un único objeto o arreglo en el nivel más alto.

"La especificación de 2013 ECMA-404 proporciona una definición compacta y formalmente precisa de la sintaxis de JSON." El documento de 2014 "RFC 7159 removes the top-level restrictions on the JSON text." RFC 8259, publicado más tarde en 2017, reemplaza a RFC 7159 y define JSON en IETF como un estándar en la vía de Internet Standards-track. La especificación de JSON también existe como documento estandarizado en ECMA International con ECMA-404, 2nd edition, actualmente activo. JSON-LD se convirtió en una Recomendación del W3C en 2014, mientras que la versión 1.1 se publicó en 2020. "JSON-LD can represent graph structure as required by the semantic web" junto con anotaciones de schema.org. GeoJSON surgió entonces como una especificación de la comunidad en 2008 y se especificó en IETF en 2016 mediante RFC 7946.

Formatos relacionados

Mientras que los archivos XML usan el Lenguaje de marcado extensible, pueden tener atributos, espacios de nombres y esquemas, y permiten contenido mixto, esas propiedades no están disponibles en los archivos JSON. Sin embargo el tamaño se vuelve un problema .xml incluirá un número mucho mayor de caracteres en comparación con un archivo .json estándar.

Los archivos YAML, que tienen los nombres ya sea de .yaml o .yml ofrecen un formato legible por humanos de codificación, comentarios y anclajes pero tienen una estructura compleja del análisis gramatical y en el pasado tuvieron vulnerabilidades al analizarlos. Los archivos TOML (.toml), principalmente archivos de configuración, permiten codificar usando comentarios también. Los escalares aquí están claramente definidos. Sin embargo los archivos TOML pueden ser mejores para estructuras jerárquicas más que para estructuras profundamente anidadas.

Los archivos CSV (.csv) son buenos para la presentación concisa de la información, tablas rectangulares pueden ser representadas aquí; sin embargo objetos y arreglos anidados no pueden ser incluidos. Por otro lado los archivos de tipo JSON Lines se llaman .jsonl o .ndjson y cada archivo contiene un objeto JSON por línea en lugar del arreglo JSON único habitual de nivel superior.

En el caso de uso de datos geográficos o de datos enlazados es crucial usar formatos especiales: GeoJSON (GIS, .geojson) respectivamente Linked-data/JSON-LD (.jsonld).