Herramientas de desarrollo · Formateador y validador JSON
Cómo un validador JSON encuentra la línea y columna exacta de un error
· Cómo funciona
json validación flujo de trabajo del desarrollador
Los motores de navegador informan JSON.parse fallas de manera diferente y algunos solo dan un desplazamiento de caracteres. Esta publicación explica cómo un validador convierte eso en una línea y columna, y por qué la posición marca dónde se detuvo el análisis en lugar de dónde cometió el error.
El mensaje de error que no le dice nada: por qué el 'token inesperado en JSON en la posición 1432' es inútil en un archivo de 400 líneas
Un error como "Token inesperado" es frustrante en una configuración larga porque no ofrece ninguna ubicación que pueda abrir en su editor. JSON.parse es el analizador autorizado del navegador, pero su texto de diagnóstico difiere entre los motores y versiones de JavaScript. ToolAcre no adivina la ubicación al hacer coincidir una cadena de error en inglés inestable. Si JSON.parse falla, un escáner estricto independiente recorre el texto original para identificar el primer carácter que la gramática JSON no puede aceptar.
Lo que realmente hace un analizador JSON mientras lee: un recorrido por la tokenización y la gramática de descenso recursivo que consume un valor a la vez
JSON tiene seis caracteres estructurales (llaves, corchetes, dos puntos y coma) y valores que pueden ser cadenas, números, matrices, objetos, verdadero, falso o nulo. Un escáner necesita saber si está dentro de una cadena entre comillas antes de llamar a una coma un separador: {"note":"A,B"} tiene un valor, no dos. Recorre un valor o un miembro de objeto y comprueba qué puede seguir legalmente a continuación. RFC 8259 define esta gramática y, a diferencia de los literales de objetos de JavaScript, no permite comentarios ni comas finales.
Desde el desplazamiento de caracteres hasta la línea y la columna: contando las nuevas líneas hasta el desplazamiento del error y por qué las terminaciones CRLF y los caracteres multibyte complican el recuento
Un escáner normalmente comienza con un desplazamiento de base cero en la cadena JavaScript original. Para que esto sea útil, cuente los saltos de línea antes del desplazamiento y encuentre qué tan lejos se encuentra la falla desde el último salto. CRLF debe tratarse como el final de una línea visual, no como dos líneas; las posiciones en cadenas de JavaScript cuentan unidades de código UTF-16, no UTF-8 bytes en el disco. Un emoji que no sea BMP puede ocupar dos unidades de código en un editor que muestra visualmente un glifo. La interfaz de usuario muestra una línea, una columna y un extracto para que pueda comparar el cursor con el archivo que pegó.
Donde se detiene el análisis no es donde está el error: se informa que falta una coma en la siguiente clave y una cita perdida puede hacer que el error se prolongue muchas líneas hacia abajo.
La primera ficha imposible suele aparecer después del error original. En un objeto, olvidar una coma después de verdadero hace que la cita que comienza con la siguiente propiedad sea ilegal: el analizador esperaba una coma o una llave de cierre. Una cadena sin terminar puede hacer que el error aparezca en un salto de línea posterior o al final de la entrada. Lea hacia atrás desde el punto informado para encontrar el delimitador que falta; No asuma que el carácter debajo del cursor debe eliminarse.
Ejemplo resuelto: una configuración a la que le falta una coma: la posición informada, los tokens circundantes y cómo retroceder hasta la causa real
Pruebe el documento literal de tres líneas {"name":"demo", seguido de "enabled":true en la línea dos y "port":8080} en la línea tres, sin coma después de true. ToolAcre informa la línea 3, columna 1, desplazamiento 31: esperaba una coma o } después de la propiedad anterior y muestra un signo de intercalación debajo de la primera comilla de "puerto". Inserte una coma al final de la línea dos y luego valide nuevamente. Este es un diagnóstico del primer obstáculo sintáctico, no un juicio de que la palabra "puerto" es incorrecta.
En qué se diferencian los motores de navegador: V8, SpiderMonkey y JavaScriptCore expresan la misma falla de manera diferente, razón por la cual un informe consistente de líneas y columnas ayuda
V8, SpiderMonkey y JavaScriptCore han utilizado redacción diferente y, a veces, fragmentos contextuales diferentes para el mismo error JSON.parse. El escáner de ToolAcre proporciona su propia razón estructural y ubicación cuando el analizador nativo rechaza el valor. Si el escáner alguna vez no está de acuerdo con JSON.parse, la herramienta devuelve el error del motor en lugar de fabricar una posición. Ese recurso es más seguro que señalar con confianza a un personaje adivinado.
Lo que esto no cubre: problemas semánticos como tipos incorrectos, campos faltantes o violaciones de esquema, que un validador de sintaxis nunca detectará.
Un objeto sintácticamente válido aún puede ser incorrecto para su aplicación: un campo obligatorio faltante, una edad escrita como texto, dos claves duplicadas o una referencia a un archivo inexistente no son automáticamente JSON no válidos. RFC 8259 dice que los nombres de los miembros deben ser únicos para la interoperabilidad, pero el simple análisis no aplica el esquema de API. Valide la sintaxis aquí y valide las restricciones semánticas en el programa que consume el documento.
Conclusión: lea la posición como "el primer token que la gramática no pudo aceptar" y cómo el formateador y validador JSON informa esa línea y columna sin cargar el texto.
Trate la posición informada como "la primera señal que esta gramática no pudo aceptar". Trabaja hacia atrás hasta la causa, soluciona un problema y vuelve a ejecutar. El formateador y validador JSON hace esto localmente sin cargar una configuración pegada. No pegue credenciales de producción reales en ningún sitio web público si un editor fuera de línea puede diagnosticar el archivo.