Validar JSON

Un analizador de JSON se para en cuanto encuentra algo que no encaja, y ese punto está a menudo bastante después del error real. Una coma que falta en la línea 12 se descubre en la 13, cuando aparece una comilla donde debería haber una coma; el mensaje señala la 13.

Por eso aquí no sale solo un número sino el fragmento con el punto marcado. Ver el contexto es lo que convierte «columna 4» en «falta la coma de la línea de arriba», y esa es la diferencia entre corregirlo en diez segundos y estar mirando un documento de doscientas líneas.

El mismo documento roto produce mensajes distintos en Chrome, en Firefox y en Safari, porque cada motor de JavaScript escribe los suyos. Algunos dan la posición como un desplazamiento de caracteres, otros no dan posición alguna.

Aquí la línea y la columna se calculan a partir del desplazamiento en lugar de fiarse del texto del mensaje. Así la respuesta es la misma en cualquier navegador, que es lo mínimo que se le puede pedir a una herramienta cuya única función es decirte dónde mirar.

Una coma de más antes de una llave o un corchete de cierre; una coma que falta entre dos elementos; comillas simples en lugar de dobles; y una clave sin comillas. Entre los cuatro se llevan la inmensa mayoría de los documentos rechazados, y los cuatro vienen de escribir JSON como si fuera JavaScript.

El quinto es más traicionero: un carácter invisible al principio del documento, casi siempre la marca de orden de bytes que Excel y algunos editores de Windows ponen delante de todo. El documento se ve perfecto y el analizador falla en la columna 1, que es exactamente el sitio donde nadie mira.

Que un documento sea JSON válido significa que su sintaxis está bien, y nada más. Un campo que debería ser número y llega como cadena, una fecha en un formato que la otra parte no espera o un objeto al que le falta la mitad de las claves pasan esta comprobación sin problema.

Si una API sigue rechazando un documento que aquí sale válido, el problema ya no es de sintaxis: es de esquema. Eso lo comprueba un validador de JSON Schema contra el esquema concreto de esa API, y es una pregunta distinta que empieza justo donde termina esta página.

Contar columnas con tabuladores dentro es ambiguo: un tabulador es un carácter, pero en pantalla ocupa cuatro u ocho según la configuración del editor. Un número de columna calculado sobre caracteres no coincide entonces con lo que se ve.

Aquí se cuentan caracteres, que es lo que hace el analizador, y el fragmento se muestra con los tabuladores expandidos para que el punto marcado caiga donde el ojo lo espera. Es un detalle diminuto y es la diferencia entre una señal que ayuda y una que confunde.

Cuando el documento pasa, sale además su forma: si el nivel superior es un objeto o un array, cuántas claves tiene, cuánto se anida y qué tamaño ocupa. Son los datos que uno mira antes de decidir cómo procesarlo.

La profundidad de anidamiento es la más útil de las cuatro. Muchos analizadores y muchas APIs tienen un límite, y un documento que se genera solo puede pasarlo sin que nadie lo prevea. Es un número que no se mira nunca hasta el día en que explica un error que no tenía sentido.

Si el documento contiene un entero demasiado grande para mantenerse exacto, se dice, aunque el documento sea perfectamente válido. No es un error de sintaxis: es una pérdida silenciosa que ocurre al leerlo, y ocurre igual en cualquier sistema que use un analizador de JavaScript.

Merece un aviso propio porque es el fallo que peor se diagnostica. El documento entra bien, sale bien y en medio un identificador ha cambiado en las últimas cifras — y el sistema que lo recibe no encuentra el registro sin ninguna pista de por qué.

Esta página responde a una pregunta y no dos: dónde falla. Ver el documento con sangrado es lo que hace la página de formatear, que tiene además el selector de sangrado y el orden de claves que aquí no pintan nada.

Es la misma decisión que separa codificar de decodificar en el resto de la sección. Quien llega aquí tiene algo roto y quiere el sitio; quien llega allí tiene algo ilegible y quiere verlo. Juntarlo daría una página con la mitad sobrante para cada uno de los dos.

El documento que algo está rechazando suele ser el documento real: un pedido, un registro de cliente, el cuerpo de un webhook con nombres y direcciones. Como la comprobación ocurre en la página, nada de eso se nos comunica ni queda en ningún registro de peticiones nuestro.

Es exactamente el caso que una política interna quiere impedir — pegar datos personales en un servicio de terceros para depurar — y aquí no se produce, porque no hay servicio de terceros que reciba nada. El panel de red lo enseña mientras la usas.