JSON: formateo, validación y reparación de lo roto
Pegue una respuesta de API, una configuración o un fragmento de registro y obtendrá una vista legible, un árbol y la lista de todo lo que no cumple el estándar, con la línea y la posición exactas. Todo se analiza en su navegador: los datos no se envían a ninguna parte ni se guardan en ningún sitio.
.json: el archivo se lee localmente. También puede pegar lo que todavía no es JSON válido: un registro, una respuesta de API con comentarios, un fragmento con comas finales.
Las claves y su orden se conservan; la escritura de los números no ha cambiado.
Pegue JSON arriba y pulse «Procesar».
Pegue JSON arriba y pulse «Procesar».
Los datos no salen de su navegador: el análisis y el formateo se ejecutan localmente, sin enviar nada a un servidor.
Cuatro ediciones del estándar y en qué se diferencian
JSON está descrito por varios documentos, y no son idénticos. La elección de la especificación cambia lo que la herramienta considera un error. RFC 4627 (2006): la original. Un documento de nivel superior solo puede ser un objeto o un array; un número o una cadena sueltos no se admiten. Algunas bibliotecas antiguas todavía se apoyan en esta edición. RFC 7159 (2014): permitió cualquier valor en el nivel superior. Desde entonces 42 y «texto» son documentos JSON autosuficientes. RFC 8259 (2017): la vigente. Añadió la exigencia de UTF-8 para el intercambio entre sistemas y fijó que los nombres dentro de un mismo objeto deben ser únicos. ECMA-404: describe solo la sintaxis. No prohíbe las claves duplicadas ni menciona los sustitutos sueltos, así que aquí el conjunto de avisos es el más corto. Si tiene dudas, quédese con RFC 8259: es el más estricto de los conjuntos de reglas vigentes, y lo que lo supera se acepta en todas partes.
Por qué un análisis propio y no el JSON.parse del navegador
El analizador integrado está hecho para la velocidad, no para el diagnóstico. Con los mismos datos calla donde una herramienta debería hablar: Un mensaje sin coordenadas. El navegador dice «Unexpected token» y un desplazamiento en caracteres; aquí se obtiene la línea, la posición y qué se esperaba exactamente. Un solo error para todo el documento. Tras el primer fallo el análisis se recupera y muestra los demás, en vez de obligarle a corregir de uno en uno. Las claves duplicadas pasan en silencio. JSON.parse conserva el último valor y la pérdida se nota ya en producción. Se pierde la escritura de los números. 1.0 pasa a 1, y un entero mayor que nueve mil billones cambia sus últimas cifras: así es exactamente como se rompen los identificadores de una base de datos. El orden de las claves en la salida se mantiene como en el origen mientras usted no pida una ordenación. Aquí los números se emiten por defecto tal como estaban escritos: la herramienta muestra el documento, no el resultado de interpretarlo.
Qué repara exactamente el modo de corrección
Los datos reales rara vez son JSON limpio. El modo de reparación ajusta al estándar lo que llega de configuraciones, registros y API ajenas: los comentarios // y /* */ se eliminan; las comas antes del corchete de cierre se quitan; las comillas simples y tipográficas se unifican en dobles; las claves sin comillas y las numéricas se entrecomillan; True, NULL, None, undefined pasan a true, false, null; NaN e Infinity pasan a null, porque en JSON no hay números sin valor finito; la escritura de los números: un más de más, un punto en el borde, ceros iniciales; los caracteres de control dentro de las cadenas se escapan; el BOM del principio del archivo y la envoltura JSONP se retiran. Ninguna corrección se hace en silencio: cada una entra en la lista con el número de casos. Si el resultado no le convence, desactive la casilla y el documento se comprueba tal cual.