Validar una cadena de texto como JSON

Una cadena es JSON válido cuando su contenido, leído de principio a fin, describe exactamente un valor conforme a la especificación del formato. Ese valor puede ser un objeto delimitado por llaves, un arreglo delimitado por corchetes, una cadena entre comillas dobles, un número, o uno de los literales true, false o null. No se admite texto suelto antes ni después del valor: si tras el cierre de un objeto aparecen más caracteres, la cadena deja de ser válida. Tampoco vale una cadena vacía, porque no representa ningún valor. Comprender esto ayuda a interpretar los resultados, ya que muchos fallos no están en el interior de la estructura, sino en algo que sobra al final o en un envoltorio inesperado que rodea al JSON real.

El punto que más confusión genera es el uso de las comillas. En JSON, tanto las claves de los objetos como los valores de tipo texto deben ir siempre entre comillas dobles. Las comillas simples, perfectamente válidas en muchos lenguajes de programación, no lo son en JSON y provocan un error inmediato. Dentro de una cadena, ciertos caracteres deben escaparse con la barra invertida: las propias comillas dobles, la barra invertida en sí, y caracteres de control como el salto de línea o la tabulación. Si una cadena contiene una comilla doble sin escapar, el analizador cree que la cadena termina ahí y se desconcierta con lo que viene después. La herramienta detecta estos casos y señala la posición donde el texto se rompe, que suele coincidir con la comilla problemática.

Más allá de las comillas, la validez de una cadena JSON depende de que su estructura esté bien equilibrada. Cada llave de apertura necesita su llave de cierre, y lo mismo ocurre con los corchetes de los arreglos. Los pares clave-valor dentro de un objeto, y los elementos dentro de un arreglo, se separan con comas, pero nunca debe haber una coma tras el último de ellos. Esta coma final es, con diferencia, el error más frecuente al editar JSON a mano, porque aparece de forma natural al borrar la última línea de una lista. Otro fallo habitual es olvidar los dos puntos que separan una clave de su valor dentro de un objeto. Cuando la estructura no cierra bien, el analizador se detiene en el punto donde esperaba un delimitador y no lo encontró, y ahí es donde la herramienta lo marca.

La herramienta no se limita a decir que la cadena es válida o no: cuando falla, localiza el primer error con precisión. El análisis avanza carácter a carácter y, en el instante en que encuentra algo que no encaja con lo que la especificación permite en ese punto, se detiene y anota la posición. Por eso el error siempre corresponde al primer problema del texto; puede haber más adelante, pero se revelarán una vez corregido este. Todo ese trabajo ocurre en local, dentro de su navegador, gracias al intérprete de JavaScript de la propia página. La cadena que pega, por larga o delicada que sea, no se transmite a ningún servidor ni se guarda en ningún lugar. Puede validar cuantas cadenas quiera, de forma gratuita, con la certeza de que su contenido permanece en su equipo.

Comprobar una cadena antes de tratarla como JSON evita fallos más adelante en su flujo de trabajo. Cualquier lenguaje que deserialice JSON aplica el mismo criterio estricto que el método JSON.parse de JavaScript: si la cadena no es válida, la conversión lanza un error y el programa se detiene o entra en el manejo de excepciones. Al validar aquí primero, sabe de antemano si esa conversión tendrá éxito, sin necesidad de ejecutar código. Esto resulta útil cuando la cadena procede de fuentes diversas: un campo de base de datos, una variable de entorno, un mensaje de una cola o un fragmento copiado de un documento. En todos esos casos, confirmar la sintaxis de forma aislada le permite separar un problema de formato de un problema de lógica y actuar sobre la causa correcta desde el principio.