Repara un JSON roto

De dónde sale un JSON roto

Casi nunca de un programa: los programas escriben JSON correcto. Sale de una respuesta de un chat, que lo mete dentro de un bloque de código con una frase antes y otra después, y a veces añade un comentario para explicarte un campo. Sale de un archivo de configuración escrito a mano, donde la coma después del último elemento y los comentarios son normales porque el editor los acepta. Sale de un print de Python, que escribe comillas simples y True, False y None. Y sale de un log, donde cada línea es un objeto aparte, a menudo con la hora o el nombre del servicio delante, y el archivo entero no es un solo JSON sino muchos seguidos.

En todos estos casos el programa que tiene que leerlo se para en el primer error y dice algo como «Unexpected token». Corregir un error a mano se hace; cuarenta repartidos en dos mil líneas, volviendo a lanzarlo cada vez, no. Aquí se pega todo, también con la frase del chat alrededor.

Cada corrección está en la lista, con la línea y la columna

Un reparador que devuelve un JSON válido sin decir qué ha tocado es una caja negra: el archivo ahora se abre, pero no sabes si dentro sigue estando el dato que había antes. Aquí cada intervención tiene una línea en la lista, con el punto exacto del texto que has pegado: línea 14, columna 3, coma final quitada.

Las correcciones no son todas iguales, y la lista lo dice. Quitar un comentario, una coma de más o el bloque de markdown no cambia ningún dato. Otras son decisiones, y están marcadas como tales: NaN e Infinity se convierten en null porque JSON no tiene forma de escribirlos, y JSON.stringify hace lo mismo; un número escrito 007 se convierte en 7, y si era un código postal esos ceros eran un dato; varios objetos seguidos se convierten en una lista, porque un archivo JSON contiene un solo valor.

El caso peligroso: el JSON cortado a mitad

Pasa continuamente con los chats: la respuesta es larga, el modelo llega a su límite y se para en medio de una lista, a menudo en medio de una palabra. El texto que tienes no está mal, está incompleto, y son dos problemas distintos. Volver a poner los cierres que faltan lo hace válido, y aquí se hace; pero un JSON cerrado así contiene menos datos que el original, y un programa que lo lee no tiene ninguna forma de darse cuenta.

Por eso en ese caso la página no dice «válido» y ya está. Dice que el texto está cortado, en qué línea y columna termina, dentro de qué (un texto, un número, una lista todavía abierta), qué cierres ha añadido y qué trozo ha quitado. Y la regla es estricta: para cerrarlo se añaden solo comillas y paréntesis. Lo que se ha quedado a medias y no se puede cerrar sin inventar se quita: el nombre de una clave partido, porque una clave cortada es otra clave; un «tru» que solo podía ser true; una coma que se ha quedado colgando.

Un ejemplo con números: una lista de 50 productos que se interrumpe dentro del nombre del trigésimo octavo sale como una lista de 38 elementos, el último con el nombre truncado, y la página lo señala como valor cortado. Los otros doce no están y nadie puede reconstruirlos: hay que pedirle al chat que siga, o que responda en varios trozos. El archivo que descargas en ese caso lleva la palabra incompleto en el nombre, para que no lo confundas con uno bueno.

Las comillas: rectas, curvas y simples

Las comillas curvas llegan cuando el JSON pasa por Word, por un correo o por el teclado de un móvil, que las «embellece» mientras escribes. Donde hacen de delimitador se convierten en rectas. Dentro de un texto, en cambio, son contenido y se quedan como están: una frase con comillas tipográficas no debe salir distinta de como ha entrado. Lo mismo vale para // y # dentro de una dirección web, que no son comentarios, y para la palabra True dentro de una frase.

Las comillas simples son las de Python y JavaScript. Aquí se reconoce también el apóstrofo dentro del texto, el de rock'n'roll: una comilla simple cierra la cadena solo si después viene algo que puede seguir a un valor, es decir una coma, los dos puntos, un paréntesis o el final de la línea. Las comillas rectas dentro de un texto sin la barra que las protege, en cambio, no se adivinan: ahí la página se para y dice dónde.

Las barras invertidas siguen la misma idea. Si en un texto hay aunque sea una que JSON no conoce, como en C:\Users\anna\new, ese texto lo ha escrito una persona, y todas sus barras son barras de verdad: también la de delante de new, que JSON leería como un salto de línea.

Lo que se queda igual, y cómo se comprueba

Un JSON que ya era válido sale con el mismo valor, solo formateado. Parece obvio y no lo es: muchas herramientas pasan por JSON.parse, que convierte un identificador como 12345678901234567890 en 12345678901234567000, y un identificador redondeado es otro identificador. Aquí los números se quedan como el texto que eran, 1.50 incluido. Se queda también el orden de las claves, y las claves repetidas se quedan las dos, señaladas: casi todos los programas se quedan solo con la última, y elegir cuál tirar te toca a ti.

La prueba de esta herramienta no es un puñado de ejemplos elegidos a mano. Un programa genera cientos de JSON válidos, los rompe de forma conocida apuntando dónde ha puesto cada fallo, y exige que el valor reparado sea exactamente el de partida, releído por la biblioteca estándar de Python, y que la lista diga justo esos fallos, en esos puntos. En los textos cortados exige el trozo más largo que se pueda guardar: nada completo tirado, y los cierres que faltaban, ni uno más.

Lo que no hace

No adivina. Una palabra sin comillas donde hace falta un valor, como estado: activo; una fecha o una versión sin comillas, como 2024-01-15 o 3.5.1, que no son números; un paréntesis cerrado con el que no toca, o uno de más con datos detrás; dos comas seguidas. En estos casos hay más de una reparación posible, y elegir una al azar querría decir entregarte un dato inventado con aspecto de verdadero. La página se para, dice la línea y la columna y te enseña el punto con una flecha. Y no tira datos en silencio: lo que quita antes y después del JSON es solo la frase del chat.

No comprueba que los datos sean correctos. Un JSON reparado es un JSON que se puede leer, no un JSON que dice la verdad: si el chat se ha equivocado en un precio, el precio sigue mal. Y no conoce el esquema que espera tu programa.

No hace los otros trabajos. Para sangrar, compactar u ordenar las claves de un JSON que ya es válido está Formatear y validar JSON. Para convertirlo en una tabla que abrir en Excel está JSON a CSV. Si el archivo es YAML, el formato con sangrías y sin paréntesis, está De YAML a JSON. Y si de la misma respuesta del chat necesitas también los otros bloques de código, está Extrae el código de la IA.