Valide

La validation comme analyse d'acceptation ou de rejet

Avant qu'une application ne fasse confiance à un document, elle doit répondre à une question plus étroite : ce texte est-il bien formé pour le format qu'il prétend être ? La validation dans cette famille signifie des contrôles syntaxiques et structurels—un analyseur respectueux des standards peut-il consommer l'entrée sans erreur ?—, pas une certification complète des règles métier ou du schéma (sauf si la définition de « valide » d'un format inclut déjà le schéma).

Les outils Valid partagent cette mission pour HTML, XML, SVG, JSON, YAML et CSV. Commencez par Valid JSON si vous déboguez des charges API ; la même idée s'applique au balisage et au texte tabulaire parmi les outils frères ci-dessous.

Ce que « valide » signifie selon le format

Les formats ne s'accordent pas sur la profondeur de « valide » :

• JSON — grammaire ECMA-404 / RFC 8259 : accolades correspondantes, clés entre guillemets, pas de virgules finales, formes numériques légales. Il n'y a pas d'étape standard « JSON Schema » dans une simple validation par analyse.
• YAML — succès de chargement YAML 1.1/1.2 : structure d'indentation, tags autorisés et styles scalaires. YAML peut exprimer des types et des ancres que JSON ne peut pas ; un chargement réussi n'est pas identique à « sûr de charger du YAML non fiable » dans chaque runtime.
• XML — bien formé (balises correspondantes, noms légaux, règles d'entités). La validité de schéma (XSD/DTD) est une couche distincte et plus stricte.
• HTML — les règles d'analyse HTML vivantes diffèrent de XHTML. Les validateurs peuvent signaler des éléments non fermés, des balises mal placées ou des constructions obsolètes selon le profil de conformité du moteur.
• SVG — vocabulaire graphique basé sur XML. Un XML bien formé est nécessaire ; un SVG valide implique aussi un imbrication et des attributs corrects pour l'espace de noms SVG, bien que les outils légers se concentrent souvent d'abord sur l'analyse et le bien formé.
• CSV — lignes de champs séparés par un délimiteur (souvent virgule) avec règles de guillemets (famille RFC 4180). « Valide » signifie généralement des nombres de colonnes cohérents, un échappement correct des guillemets et un encodage lisible—pas que les valeurs de cellule correspondent à un schéma métier.

Savoir quelle couche vous faut évite une fausse confiance : un XML bien formé peut encore violer une XSD sectorielle ; un JSON analysable peut encore manquer de champs obligatoires.

Sous-outils de cette famille

• Valid HTML — vérifier le balisage HTML pour des problèmes courants au niveau analyseur dans pages et fragments.
• Valid XML — vérifier documents et extraits XML bien formés.
• Valid SVG — vérifier le source SVG comme balisage graphique structuré.
• Valid JSON — accepter ou rejeter du texte JSON selon les règles grammaticales standard.
• Valid YAML — analyser YAML et remonter erreurs de chargement ou de structure.
• Valid CSV — vérifier le texte tabulaire délimité pour cohérence structurelle.

Choisissez l'outil qui correspond au Content-Type ou à l'extension de fichier que vous avez réellement. Ne validez pas YAML avec un analyseur JSON ni HTML avec un vérificateur XML seul, sauf si vous exigez intentionnellement le dialecte plus strict (par exemple XHTML).

Pourquoi la validation côté navigateur aide

La validation locale raccourcit la boucle de retour lors de la création de fixtures, de l'édition de fragments CMS ou de l'inspection d'un corps de réponse copié. Vous voyez des erreurs orientées ligne avant de committer des fichiers ou de déployer des configs. Garder le document dans le navigateur évite aussi d'envoyer des brouillons sensibles à un service de lint distant—bien que le presse-papiers et le partage d'écran exposent encore le contenu.

La validation ici complète les tests unitaires : les tests doivent toujours affirmer des fixtures canoniques en CI avec les mêmes bibliothèques que vos analyseurs de production. Les vérifications en ligne servent à l'exploration et au triage ; la CI sert à la régression.

Formes d'erreur à reconnaître

JSON. Jeton inattendu, chaîne non terminée, virgule finale, guillemets simples, NaN. Les éditeurs qui acceptent JSONC passent localement et échouent dans les analyseurs stricts de production.

YAML. Tabulations vs espaces, indentation incorrecte sous une clé, chaînes non quotées ambiguës (booléanisation on/off en YAML 1.1) et clés dupliquées selon les paramètres du chargeur.

XML/SVG. Balises de fin non correspondantes, < brut dans le texte, préfixes non définis, plusieurs éléments racine ou caractères de contrôle illégaux. Des fichiers SVG conçus comme fragments HTML intégrés peuvent échouer en documents XML autonomes.

HTML. Balises chevauchantes, attributs obsolètes et erreurs sur éléments void. Les analyseurs HTML récupèrent souvent ; un validateur qui signale des problèmes peut décrire un arbre qu'un navigateur rendra quand même—traitez les avertissements comme signaux de qualité, pas toujours comme échecs durs à l'exécution.

CSV. Guillemets non échappés, sauts de ligne intégrés dans des champs sans guillemets, délimiteurs mélangés (virgule vs point-virgule) et lignes irrégulières où le nombre de colonnes varie.

Validation versus transformation

Les validateurs répondent oui/non (et où ça a échoué). Formateurs et convertisseurs modifient les octets. Un document peut être invalide et « paraître correct » dans l'analyseur indulgent HTML d'un navigateur, ou être du JSON valide mais incorrect pour le schéma de votre API. Pipeline typique :

1. Valider la syntaxe pour le format déclaré.
2. Valider éventuellement contre un schéma (JSON Schema, XSD, etc.) dans le code applicatif.
3. Seulement ensuite transformer, fusionner ou persister.

Sauter l'étape 1 gaspille du temps sur des erreurs de transformation mystérieuses qui étaient des échecs d'analyse depuis le début.

Notes de sécurité par format

• XML : billion laughs / expansion d'entités et attaques par entités externes (XXE) comptent quand les analyseurs résolvent DTD ou entités. Préférez des analyseurs avec entités externes désactivées pour les entrées non fiables.
• YAML : certains chargeurs peuvent construire des objets arbitraires (tags style !!python/object). Préférez les API safe-load pour YAML non fiable.
• HTML/SVG : attributs script et gestionnaires d'événements sont une surface XSS quand le balisage est intégré dans des pages. Validation ≠ assainissement.
• CSV : injection de formules dans les clients tableur (=CMD(...)) est un souci quand CSV s'ouvre dans Excel ; la validité structurelle ne neutralise pas cela.
• JSON : généralement plus sûr à analyser que les formats ci-dessus, mais d'énormes charges peuvent quand même provoquer un DoS mémoire ; limitez la taille côté serveur.

Workflows pratiques

• Collez un corps d'erreur API dans Valid JSON avant d'incriminer la logique applicative.
• Vérifiez un fragment de config Kubernetes ou CI avec Valid YAML quand l'indentation semble suspecte.
• Confirmez une exportation tableur avec Valid CSV avant d'écrire un importateur.
• Vérifiez des icônes éditées à la main avec Valid SVG avant bundling.

Limitations

Ces outils ne remplacent pas les schémas métier, les audits d'accessibilité ni les suites complètes de conformité HTML (par exemple chaque contrôle WHATWG). Ils ne prouvent pas qu'un XML satisfait une XSD particulière, que du JSON satisfait OpenAPI ou que les colonnes CSV correspondent à un DDL de base de données. Ils n'assainissent pas non plus le contenu actif. Utilisez-les comme première porte : structure d'abord, sens ensuite.

Outils associés

Après validation JSON, utilisez Pretty-print JSON pour la mise en page ou From JSON to XML pour une projection en arbre. La validation indique si le document est comestible ; d'autres familles décident quoi cuisiner.