Validador JSON

Los errores de sintaxis JSON más comunes incluyen: comas finales (la última coma antes de ] o } que no está permitida en JSON estricto), comas faltantes entre elementos de arreglo o propiedades de objeto (olvidar el separador de coma), nombres de propiedad sin comillas o con comillas simples (JSON requiere comillas dobles para todas las claves), literales de cadena sin cerrar (falta la comilla de terminación, a menudo debido a caracteres especiales), secuencias de escape inválidas (\\q, \\x sin dígitos hexadecimales, etc.), corchetes y llaves faltantes o no coincidentes (desajuste estructural entre [/{ y ]/}), y tokens inesperados (como undefined de JavaScript, NaN, o llamadas a funciones que no son JSON válido). El validador señala cada error con la línea y columna exacta, explica qué salió mal, y para muchos errores comunes ofrece una corrección automática que puedes aplicar con un solo clic.

El modo estricto impone el cumplimiento exacto de RFC 8259: solo cadenas con comillas dobles, los nombres de propiedades deben estar entre comillas dobles, no se permiten comentarios, no hay comas finales, no hay contenido final después del valor raíz, y solo se permite null (no undefined ni NaN). Este es el modo a usar al validar JSON para APIs, bases de datos y sistemas de producción que requieren un cumplimiento absoluto del estándar. El modo permisivo (compatible con JSON5) permite: comentarios (tanto de una línea // como de múltiples líneas /* */), comas finales en arreglos y objetos, claves sin comillas (si son identificadores válidos de JavaScript), cadenas con comillas simples, cadenas de múltiples líneas, puntos decimales al inicio o final de números, y formatos numéricos adicionales (hexadecimal, infinito positivo). Use el modo permisivo para archivos de configuración (tsconfig.json de TypeScript, ESLint, configuraciones de VS Code) y situaciones donde los humanos escriben JSON manualmente y se benefician de una sintaxis más flexible.

El validador maneja todos los caracteres UTF-8/Unicode y los codifica adecuadamente en el informe de errores. Los escenarios comunes incluyen: caracteres escapados dentro de cadenas (\n, \ t,\\,\", \ / y \ uXXXX Los escapes Unicode deben ser válidos), caracteres Unicode literales (chino, Japonés, árabe, emoji son válidos en cadenas JSON sin escapes), BOM (Marca de Orden de Bytes) los caracteres al comienzo de los archivos a menudo interrumpen el análisis (el validador detecta e informa la presencia de la lista de materiales) y secuencias de bytes UTF-8 inválidas (el validador los detecta antes de que comience el análisis JSON). Para los informes de errores, la herramienta normaliza la posición del error para tener en cuenta los caracteres de varios bytes, de modo que los números de columna sean precisos incluso con contenido en varios idiomas. Al corregir errores, el validador escapa correctamente de cualquier carácter que necesite escapar en cadenas JSON.

Sí, la validación JSON debería ser parte de cada flujo de trabajo de desarrollo. Para pipelines de CI/CD, use validadores de línea de comandos como ajv-cli para Python jsonschema o eslint-plugin-json para hooks de pre-commit que validen archivos JSON antes del commit. Para nuestro validador en línea, puede usarlo como una verificación manual rápida. Para uso programático, integre la validación JSON en su aplicación con bibliotecas de análisis JSON rápidas (JSON.parse en JavaScript, json.Unmarshal en Go, json.loads en Python) que generan errores claros en entradas no válidas. En editores de código, use soporte de lenguaje JSON (VS Code tiene validación JSON incorporada con soporte de JSON Schema) que proporciona resaltado de errores en tiempo real e IntelliSense. Para desarrollo de API, aplique validación JSON a nivel de puerta de enlace: frameworks de API como Express.js, FastAPI y Spring Boot pueden validar el JSON entrante contra esquemas antes de llegar a su lógica de negocio.

Si la validación pasa pero tu aplicación aún falla al usar el JSON correctamente, el problema probablemente va más allá de la sintaxis: discrepancias de tipo (el JSON es válido pero tu código espera un número donde se proporciona una cadena), violaciones de esquema (el JSON es sintácticamente válido pero no coincide con la estructura esperada, como campos obligatorios faltantes o anidación incorrecta), problemas de codificación (el archivo puede analizarse correctamente pero la aplicación lo recibe con una especificación de codificación incorrecta), limitaciones de tamaño (un JSON muy grande puede exceder los límites de tamaño del cuerpo HTTP o los tamaños de campos de la base de datos), errores semánticos (JSON válido pero datos inválidos, como un campo de correo electrónico que contiene algo que no es un correo electrónico) y desajustes de versión (la estructura del JSON cambió pero tu código espera el esquema antiguo). Para depurar estos problemas: valida contra un esquema JSON (no solo la sintaxis), verifica que el encabezado Content-Type sea application/json al enviar por HTTP, asegúrate de que los tipos de campo coincidan con lo que tu código espera, y prueba con el JSON exacto que recibe tu aplicación (no una versión reformateada).