El JSON «roto» es un problema habitual: el archivo parece casi correcto, pero el analizador se niega a leerlo. La causa suele ser un pequeño desliz de sintaxis, y muchas veces ese desliz viene directamente de copiar un número escrito «a la española».
Causas habituales de JSON inválido
- Una coma sobrante antes de un corchete de cierre —
{"a": 1,}—, que JavaScript tolera pero un analizador JSON estricto no. - Comillas simples en vez de dobles: un error habitual al copiar de un objeto literal de JavaScript.
- Claves sin comillas —
{name: "Ana"}en vez de{"name": "Ana"}. - Comentarios — la especificación de JSON no admite comentarios en absoluto, a diferencia de JSON5 o JSONC.
- Salida cortada — si la respuesta de una API o un archivo de log se corta a la mitad, el documento queda sin cerrar.
La coma decimal: un problema silencioso al pegar precios
En España y en la mayor parte de Hispanoamérica, la coma separa los decimales y el punto agrupa los miles: «1.234,50» es un precio perfectamente normal en una hoja de cálculo. Pegado tal cual en un campo JSON, {"precio": 1.234,50} no es un número decimal para el analizador, sino un número (1.234) seguido de una coma fuera de lugar y otro token suelto (50). Una herramienta de reparación puede intentar adivinar dónde termina el número, pero no puede saber con certeza si el valor real era 1234,50 o 1.234 — es el tipo de ambigüedad que conviene revisar a mano antes de confiar en el resultado.
Cómo funciona la reparación automática
Una herramienta de reparación de JSON aplica heurísticas: añade comillas que faltan, elimina comas sobrantes, cierra corchetes sin cerrar según el contexto. Esto funciona bien para errores típicos y comunes, pero no es magia: la herramienta no puede adivinar qué valor se pretendía si los datos están más gravemente dañados.
Los límites de lo posible
La reparación automática corrige la sintaxis, no la semántica. Si falta un campo entero, o un valor está mal lógicamente, la herramienta no lo detectará; el resultado sigue necesitando una revisión manual, sobre todo cuando el origen fue un número copiado de una hoja de cálculo en formato regional.
Cuándo la reparación es ambigua
Algunos daños admiten varias correcciones igual de plausibles. Por ejemplo, una cadena cortada como {"a": 1, "b": 2 puede cerrarse simplemente con un corchete — y perder datos si en realidad faltaba otro campo. En esos casos, la heurística de reparación hace la suposición «menos destructiva», pero eso es una conjetura, no una garantía de restaurar la intención original.