Errores comunes en JSON y cómo corregirlos

Actualizado:

JSON es el formato que usan muchas API, archivos de configuración y aplicaciones web para intercambiar datos, y su gramática cabe en una sola página. Por eso mismo no perdona: un texto o es JSON válido o no lo es, y basta una coma fuera de lugar para que un analizador (parser) lo rechace entero. La mayoría de los errores provienen siempre de los mismos pocos hábitos, muchos de ellos heredados de JavaScript o de otros lenguajes. Esta guía recoge las reglas, los errores que más a menudo las incumplen, cómo leer el mensaje de error y algunos casos que son JSON válido pero aun así causan problemas.

Las reglas que JSON tiene de verdad

Las definiciones vigentes son el RFC 8259, publicado en diciembre de 2017, y ECMA-404. Ambas describen la misma sintaxis:

Entre tokens solo se admiten cuatro caracteres de espacio en blanco: el espacio, la tabulación, el avance de línea y el retorno de carro.

Los errores más comunes

Un analizador estándar rechaza todos estos ejemplos. La descripción indica cómo corregir cada uno.

Formateador y conversor JSON

Cómo leer el mensaje de error

Un analizador lee el texto de izquierda a derecha y se detiene en el primer carácter que no puede aceptar, así que la posición que indica el mensaje de error es el punto en que se rindió, que a menudo está justo después del error real. Con una coma final, el analizador se queja de la llave de cierre, porque después de una coma espera otro nombre de propiedad. Si falta un corchete o una llave, el error puede aparecer al final mismo del texto, lejos de donde debería haber estado.

La redacción cambia según el navegador y el lenguaje, y muchos mensajes indican una posición, aunque no todos, ya sea como número de caracteres desde el principio o como línea y columna. Por ejemplo, el motor de JavaScript de Chrome informa así de {"name":"Ana",}:

Cuando la posición no sea evidente, fíjate en el carácter justo anterior y comprueba que cada corchete, llave o comilla que se abre antes de ese punto tenga su pareja. Con un editor que resalte las parejas de corchetes y llaves, a menudo es fácil detectar la que falta.

JSON válido que aun así da problemas

JSON no es JavaScript

La sintaxis de JSON se tomó de los literales de objeto de JavaScript, y por eso es tan fácil confundirlos. Un literal de objeto de JavaScript acepta comillas simples, nombres sin comillas, comas finales, comentarios y valores como undefined; JSON no acepta ninguno de ellos. Así, un código que funciona al pegarlo en un script puede fallar como archivo JSON.

Algunas herramientas aceptan formatos ampliados, como JSON5 o «JSON con comentarios» en archivos de configuración. Son prácticos allí donde se admiten, pero no son JSON, y un analizador estándar, incluido el formateador de nTools, los rechazará.

Preguntas frecuentes

¿Puede JSON tener comentarios?

No. La especificación no tiene sintaxis para comentarios. Si necesitas notas en los datos, ponlas en una propiedad como "_comment", o usa un formato que admita comentarios allí donde las herramientas lo permitan.

¿Por qué mi JSON funciona en JavaScript pero falla en un validador?

Porque un literal de objeto de JavaScript permite cosas que JSON no admite, como comillas simples, comas finales y nombres sin comillas. Pegado en el código, se ejecuta; guardado como JSON, no es válido.

¿Cómo mantengo exacto un número muy grande?

Envíalo como cadena, por ejemplo "9007199254740993", y conviértelo en el lado receptor con un tipo capaz de contenerlo, como BigInt en JavaScript.

¿El formateador de nTools envía mi JSON a algún sitio?

No. Se analiza y se formatea en tu navegador, y cuando el navegador indica una posición, el formateador la muestra como línea y columna.

Guías relacionadas