Formater du JSON
Mettre en forme, valider et replier du JSON.
Développement
Formater, vérifier et compresser du XML.
Cette distinction est à l'origine de presque toute la confusion autour du XML.
Un document est bien formé s'il respecte les règles syntaxiques du XML : un unique élément racine, des balises correctement imbriquées et fermées, des valeurs d'attribut entre guillemets et des caractères spéciaux encodés.
Il est valide s'il se conforme en outre à un schéma — un XSD ou une DTD — définissant quels éléments peuvent apparaître, dans quel ordre et avec quels types.
Cet outil vérifie qu'il est bien formé. Pour une validation contre un schéma, il vous faut le schéma.
La différence pratique : un document bien formé peut être lu ; un document valide contient en plus ce qu'attend le destinataire.
En France c'est très concret : la facturation électronique repose sur des formats structurés en XML, notamment Factur-X qui associe un PDF lisible et des données XML embarquées, ainsi que les formats UBL et CII. La généralisation de la facturation électronique entre entreprises rend cette exigence beaucoup plus large qu'auparavant.
Un fichier bien formé mais non conforme au schéma est rejeté automatiquement par la plateforme destinataire.
Presque tous les problèmes tiennent en quelques catégories.
Caractères non encodés : une & isolée dans le texte est le classique, tout comme un < dans un contenu textuel. Ils doivent s'écrire & et <.
Encodage : si la déclaration indique UTF-8 alors que le fichier est enregistré autrement, ce sont les caractères accentués qui cassent en premier. En France, c'est de loin le défaut le plus courant.
La marque d'ordre des octets en début de fichier : invisible dans l'éditeur, mais beaucoup d'analyseurs y trébuchent parce que la déclaration XML n'est plus en position zéro.
Espaces de noms : on utilise un préfixe non déclaré, ou la déclaration par défaut se perd en assemblant des fragments de sources différentes.
Et les espaces : dans le contenu d'un élément, ils sont significatifs en XML. Un formateur qui indente modifie donc techniquement le contenu — sans conséquence pour des formats de données purs, mais pas pour du contenu mixte.
Un repère pratique, car la question revient souvent.
XML est fort là où la structure doit être strictement définie et vérifiable automatiquement. C'est pourquoi il persiste dans l'administratif et la facturation, où les formats doivent rester stables et opposables pendant des années.
JSON est plus compact et s'impose dans les interfaces web, mais sa validation par schéma est moins ancrée dans l'usage quotidien, et il ignore les attributs, les espaces de noms et les commentaires.
YAML est plus lisible pour des fichiers de configuration, au prix d'une sensibilité aux erreurs d'indentation.
Si vous convertissez du XML en JSON, gardez en tête ce qui se perd : attributs et éléments sont traités pareillement, les espaces de noms disparaissent, et l'ordre des éléments frères n'est pas garanti dans un objet JSON.
Tout ceci s'exécute localement dans votre navigateur, y compris pour des fichiers qui ne doivent pas quitter votre poste.
Bien formé signifie syntaxiquement correct ; valide signifie en plus conforme à un schéma.
Parce que l'encodage déclaré ne correspond pas à celui du fichier.
Un caractère invisible en début de fichier qui fait échouer de nombreux analyseurs.
Parce que la structure doit être vérifiable automatiquement contre un schéma imposé.
Oui : espaces de noms, distinction attribut/élément et ordre des éléments.
Non.