Formateador JSON

JSON (JavaScript Object Notation) está definido por dos estándares equivalentes: RFC 8259 (IETF, diciembre 2017) y ECMA-404 (2da edición, 2017). Aunque deriva de la sintaxis de objetos JavaScript, JSON es un formato de datos independiente del lenguaje con reglas estrictas: • Cadenas obligatoriamente con comillas dobles — JSON solo acepta comillas dobles ("clave"). Las comillas simples ('clave') son un error de sintaxis. Este es el error más común al convertir objetos JavaScript a JSON manualmente, ya que JavaScript acepta ambas. JSON.parse("{'key': 'value'}") lanza SyntaxError. • Sin comas finales (trailing commas) — {"a": 1, "b": 2,} es JSON inválido. JavaScript y muchos lenguajes toleran trailing commas en objetos y arrays, pero JSON no. Es frecuente copiar un objeto de código fuente y olvidar eliminar la última coma. • Sin comentarios — JSON no soporta comentarios de ninguna forma (// ni /* */). Esta decisión de diseño de Douglas Crockford fue intencional para mantener la simplicidad del parser. Los archivos de configuración que necesitan comentarios deben usar JSON5 o JSONC (JSON with Comments, formato de VS Code). • Sin undefined ni funciones — JSON solo soporta seis tipos de valores: object, array, string, number, true, false y null. undefined, NaN, Infinity, funciones y símbolos de JavaScript no tienen representación en JSON. JSON.stringify({a: undefined}) omite la clave silenciosamente: produce "{}". • Numeros sin leading zeros ni hexadecimal — 0123 y 0xFF son invalidos en JSON. Los números deben seguir el formato: entero opcional con signo negativo, parte decimal opcional, exponente opcional. No hay distinción entre enteros y flotantes. • Codificación — RFC 8259 específica que JSON transmitido por red debe ser UTF-8. Las codificaciones UTF-16 y UTF-32 ya no son conformes (RFC 8259 elimino el soporte que RFC 7159 permitia). Los caracteres Unicode se pueden representar con escape sequences: \u0041 para "A".

Varios formatos compiten con o extienden JSON para diferentes casos de uso: • JSON5 — Extensión de JSON que añade comentarios (// y /* */), trailing commas, comillas simples, claves sin comillas, números hexadecimales (0xFF), Infinity y NaN. Compatible con toda la sintaxis de ECMAScript 5.1. Util para archivos de configuración editados por humanos. No recomendado para intercambio de datos entre sistemas por falta de estandarización formal y soporte inconsistente en parsers. • JSONC (JSON with Comments) — Subconjunto de JSON5 que solo añade soporte para comentarios (// y /* */). Usado por VS Code para settings.json y tsconfig.json. TypeScript usa JSONC para tsconfig.json, permitiendo documentar opciones del compilador. • YAML — Superset de JSON (todo JSON válido es YAML válido) que usa indentación en lugar de llaves y corchetes. Soporta comentarios, referencias (&anchor/*alias), tipos complejos y multi-line strings. Popular en DevOps (Docker Compose, Kubernetes manifests, GitHub Actions, Ansible). Desventajas: la sensibilidad a indentación causa errores sutiles, el parsing es significativamente más complejo que JSON, y ciertas cadenas se interpretan implícitamente como booleanos (yes/no, on/off en YAML 1.1, corregido parcialmente en YAML 1.2). • TOML — Formato de configuración diseñado para ser leido por humanos, con semántica clara y sin la ambiguedad de YAML. Usado por Cargo (Rust), pyproject.toml (Python), y Hugo. Mejor que JSON para configuración porque soporta comentarios y tipos de datos como fechas nativas. • Protocol Buffers / MessagePack — Formatos binarios para serialización de datos con esquema (Protobuf) o sin esquema (MessagePack). Significativamente más compactos y rápidos de parsear que JSON. Usados en comunicación interna de microservicios y sistemas de alto rendimiento. JSON sigue siendo preferido para APIs públicas por su legibilidad humana y soporte universal.

El manejo de JSON a escala requiere consideraciones de rendimiento y validación: • Parsing de documentos grandes — JSON.parse() en JavaScript carga todo el documento en memoria y lo parsea de forma sincrona, bloqueando el hilo principal. Un JSON de 50 MB puede congelar la UI del navegador durante segundos. Alternativas: Web Workers para parsear en un hilo separado, streaming parsers como clarinet o oboe.js que procesan el JSON incrementalmente, o formatos binarios (MessagePack, CBOR) para datos masivos. • JSON.stringify() y rendimiento — La serialización de objetos grandes con JSON.stringify() puede ser costosa. El parámetro replacer permite filtrar propiedades innecesarias. El parámetro space (2, 4, o "\t") controla la indentación del pretty-print. JSON.stringify() con BigInt lanza TypeError; se necesita un replacer personalizado. Los objetos con referencias circulares también lanzan TypeError. • JSON Schema (draft 2020-12) — Vocabulario de validación que define la estructura esperada de un documento JSON: tipos de datos, propiedades requeridas, patrones de cadenas (regex), rangos numericos, formato de datos (date, email, uri), y composición lógica (allOf, anyOf, oneOf, not). Herramientas como Ajv (JavaScript), jsonschema (Python) y json-schema-validator (Java) implementan la validación. JSON Schema se usa en OpenAPI/Swagger para definir el formato de request/response bodies de APIs REST. • JSON en APIs REST — El Content-Type estándar es application/json (RFC 8259). Las APIs deben devolver objetos JSON (no arrays) en el nivel raíz como medida de seguridad contra JSON hijacking (históricamente, arrays JSON eran vulnerables a robo vía redefinición de Array constructor, corregido en navegadores modernos). Las respuestas de error deben seguir un formato consistente, como RFC 9457 (Problem Details for HTTP APIs): {"type": "...", "title": "...", "status": 404, "detail": "..."}. • JSON Patch (RFC 6902) y JSON Merge Patch (RFC 7396) — Formatos para describir modificaciones parciales a documentos JSON. JSON Patch usa un array de operaciones (add, remove, replace, move, copy, test). JSON Merge Patch envía solo los campos modificados. Ambos se envían con Content-Type específico (application/json-patch+json y application/merge-patch+json) en peticiones HTTP PATCH.