Valida

Validación como análisis de aceptación o rechazo

Antes de que una aplicación confíe en un documento, debe responder una pregunta más estrecha: ¿este texto está bien formado para el formato que declara ser? La validación en esta familia significa comprobaciones sintácticas y estructurales—¿puede un analizador consciente de los estándares consumir la entrada sin error?—, no certificación completa de reglas de negocio o esquemas (salvo que la definición de «válido» de un formato ya incluya el esquema).

Las herramientas Valid comparten esa misión en HTML, XML, SVG, JSON, YAML y CSV. Empiece con Valid JSON si depura cargas de API; la misma idea se aplica al marcado y al texto tabular en los hermanos siguientes.

Qué significa «válido» según el formato

Los formatos no coinciden en qué tan profundo va «válido»:

• JSON — gramática ECMA-404 / RFC 8259: llaves coincidentes, claves entre comillas, sin comas finales, formas numéricas legales. No hay un paso estándar de «JSON Schema» dentro de la validación de análisis básico.
• YAML — éxito de carga YAML 1.1/1.2: estructura de indentación, etiquetas permitidas y estilos escalares. YAML puede expresar tipos y anclas que JSON no puede; una carga exitosa no equivale a «seguro cargar YAML no confiable» en todo entorno de ejecución.
• XML — bien formado (etiquetas coincidentes, nombres legales, reglas de entidades). La validez de esquema (XSD/DTD) es una capa aparte y más estricta.
• HTML — las reglas de análisis HTML vivas difieren de XHTML. Los validadores pueden señalar elementos sin cerrar, etiquetas mal colocadas o construcciones obsoletas según el perfil de conformidad del motor.
• SVG — vocabulario gráfico basado en XML. El XML bien formado es necesario; SVG válido también implica anidamiento y atributos correctos para el espacio de nombres SVG, aunque herramientas ligeras suelen centrarse primero en comprobaciones de análisis y bien formado.
• CSV — filas de campos separados por un delimitador (a menudo coma) con reglas de comillas (familia RFC 4180). «Válido» suele significar recuentos de columnas consistentes, escape correcto de comillas y codificación legible—no que los valores de celda coincidan con un esquema de negocio.

Saber qué capa necesita evita falsa confianza: XML bien formado puede violar una XSD sectorial; JSON analizable puede carecer aún de campos obligatorios.

Subherramientas de esta familia

• Valid HTML — comprobar marcado HTML en busca de problemas habituales a nivel de analizador en páginas y fragmentos.
• Valid XML — comprobar documentos y fragmentos XML bien formados.
• Valid SVG — comprobar código SVG como marcado gráfico estructurado.
• Valid JSON — aceptar o rechazar texto JSON según reglas gramaticales estándar.
• Valid YAML — analizar YAML y mostrar errores de carga o estructura.
• Valid CSV — comprobar texto tabular delimitado por consistencia estructural.

Elija la herramienta que coincida con el Content-Type o la extensión de archivo que realmente tiene. No valide YAML con un analizador JSON ni HTML con un comprobador solo XML salvo que requiera intencionalmente el dialecto más estricto (por ejemplo XHTML).

Por qué ayuda la validación en el navegador

La validación local acorta el ciclo de retroalimentación al crear fixtures, editar fragmentos de CMS o inspeccionar un cuerpo de respuesta copiado. Ve errores orientados a líneas antes de confirmar archivos o desplegar configuraciones. Mantener el documento en el navegador también evita subir borradores sensibles a un servicio remoto de lint—aunque el portapapeles y la compartición de pantalla siguen exponiendo contenido.

La validación aquí complementa las pruebas unitarias: las pruebas deben seguir afirmando fixtures canónicos en CI con las mismas bibliotecas que usan sus analizadores de producción. Las comprobaciones en línea sirven para exploración y triaje; CI es para regresión.

Formas de error que conviene reconocer

JSON. Token inesperado, cadena sin terminar, coma final, comillas simples, NaN. Editores que aceptan JSONC pasan localmente y fallan en analizadores estrictos de producción.

YAML. Tabulaciones vs espacios, indentación incorrecta bajo una clave, cadenas sin comillas ambiguas (booleanización on/off en YAML 1.1) y claves duplicadas según la configuración del cargador.

XML/SVG. Etiquetas de cierre no coincidentes, < sin escapar en texto, prefijos indefinidos, varios elementos de nivel superior o caracteres de control ilegales. Archivos SVG pensados como fragmentos incrustados en HTML pueden fallar como documentos XML independientes.

HTML. Etiquetas superpuestas, atributos obsoletos y errores en elementos void. Los analizadores HTML a menudo recuperan; un validador que informa problemas puede describir aun así un árbol que un navegador renderizará—trate las advertencias como señales de calidad, no siempre como fallos duros en tiempo de ejecución.

CSV. Comillas sin escapar, saltos de línea incrustados en campos sin comillas, delimitadores mezclados (coma vs punto y coma) y filas irregulares donde el número de columnas varía.

Validación frente a transformación

Los validadores responden sí/no (y dónde falló). Formateadores y convertidores cambian bytes. Un documento puede ser inválido y «verse bien» en el analizador indulgente de HTML de un navegador, o ser JSON válido y aun así incorrecto para el esquema de su API. Pipeline típico:

1. Validar sintaxis para el formato declarado.
2. Opcionalmente validar contra un esquema (JSON Schema, XSD, etc.) en código de aplicación.
3. Solo entonces transformar, fusionar o persistir.

Omitir el paso 1 desperdicia tiempo en errores misteriosos de transformación que eran fallos de análisis desde el principio.

Notas de seguridad por formato

• XML: billion laughs / expansión de entidades y ataques de entidades externas (XXE) importan cuando los analizadores resuelven DTD o entidades. Prefiera analizadores con entidades externas deshabilitadas para entrada no confiable.
• YAML: algunos cargadores pueden construir objetos arbitrarios (etiquetas estilo !!python/object). Prefiera APIs safe-load para YAML no confiable.
• HTML/SVG: atributos script y de manejadores de eventos son una superficie XSS cuando el marcado se incrusta en páginas. Validación ≠ sanitización.
• CSV: inyección de fórmulas en clientes de hoja de cálculo (=CMD(...)) preocupa cuando CSV se abre en Excel; la validez estructural no neutraliza eso.
• JSON: generalmente más seguro de analizar que los anteriores, pero cargas enormes pueden aún provocar DoS de memoria; limite el tamaño en servidores.

Flujos de trabajo prácticos

• Pegue un cuerpo de error de API en Valid JSON antes de culpar a la lógica de aplicación.
• Compruebe un fragmento de configuración de Kubernetes o CI con Valid YAML cuando la indentación parezca sospechosa.
• Confirme una exportación de hoja de cálculo con Valid CSV antes de escribir un importador.
• Verifique iconos editados a mano con Valid SVG antes de empaquetarlos.

Limitaciones

Estas herramientas no sustituyen esquemas de dominio, auditorías de accesibilidad ni suites completas de conformidad HTML (por ejemplo cada comprobación WHATWG). No demuestran que XML cumpla una XSD concreta, que JSON cumpla OpenAPI o que las columnas CSV coincidan con un DDL de base de datos. Tampoco sanitizan contenido activo. Úselas como primera puerta: estructura primero, significado después.

Herramientas relacionadas

Tras validar JSON, use Pretty-print JSON para el diseño o From JSON to XML para proyección en árbol. La validación indica si el documento es comestible; otras familias deciden qué cocinar.