Formateador de JSON

JSON es un subconjunto estricto de lo que permiten los literales de objeto de JavaScript, y la brecha entre los dos es exactamente de donde vienen la mayoría de los errores de "JSON inválido". Una coma final después del último elemento en un array u objeto es legal en JavaScript moderno pero un error de sintaxis en JSON. Las cadenas con comillas simples funcionan bien en JavaScript y son rechazadas directamente por JSON, que requiere comillas dobles. Las claves de objeto sin comillas — escribir `{name: "value"}` en lugar de `{"name": "value"}` — son una abreviatura válida de JavaScript e inválida en JSON. Ninguno de estos son casos extremos oscuros; son exactamente los hábitos adquiridos al escribir JavaScript que silenciosamente producen un documento que parece JSON pero no lo es.

Los comentarios son la otra fuente frecuente de confusión, porque bastantes formatos de archivo de configuración que parecen JSON — e incluso algunos formatos derivados de JSON usados deliberadamente — permiten comentarios `//` o `/* */`, mientras que la especificación de JSON en sí no tiene sintaxis de comentarios en absoluto. Copiar un archivo de configuración "JSON" que realmente contiene comentarios en un analizador estricto falla de inmediato, y el arreglo es o bien eliminar los comentarios o reconocer que el archivo nunca usó JSON estándar en primer lugar.

Un analizador que solo informa "JSON inválido" sin decir dónde te deja escaneando todo el documento a simple vista buscando una sola coma faltante o una comilla sin escapar, lo cual se vuelve genuinamente tedioso pasadas unas pocas docenas de líneas. Informar la línea y columna exactas del primer problema convierte esa búsqueda en una localización directa — el error describe un carácter específico, no un fallo vago general — que es la diferencia entre arreglar una respuesta de API grande en segundos frente a minutos de escaneo manual.

Vale la pena notar que el error siempre señala el *primer* problema que encuentra el analizador, no necesariamente cada problema del documento: un documento con dos errores de sintaxis informará el primero, y arreglarlo puede revelar el segundo solo en el siguiente intento, ya que un analizador que ya ha fallado en entender la estructura no puede seguir buscando de forma fiable más problemas más allá del primer punto donde se confundió.

El JSON embellecido, con indentación y saltos de línea consistentes, existe para la persona que lo lee — depurando una respuesta de API, revisando un archivo de configuración, entendiendo una estructura de datos de un vistazo. Nada de esa estructura importa a un programa que analiza el mismo JSON, por eso la salida minificada elimina cada carácter que existe puramente por legibilidad humana: indentación, saltos de línea, y cualquier espacio en blanco entre tokens que no sea necesario para separarlos. Los datos representados son idénticos en ambas formas; solo difiere el número de bytes necesarios para transmitirlos o almacenarlos, a menudo sustancialmente para estructuras profundamente anidadas.

La regla práctica es sencilla: formatea el JSON mientras trabajas con él — leyendo, depurando, editando a mano — y minifícalo antes de que vaya a cualquier lugar que pague por su tamaño, como el cuerpo de una solicitud HTTP, un parámetro de consulta de URL, o un valor almacenado en una variable de entorno con límite de longitud.