Intégrité fichier XML (balises)

Version imprimable

07/12/2018, 18h22
steph78630

Intégrité fichier XML (balises)
Bonjour,

j'ai plusieurs fichiers XML d'environ 20000 lignes dont je dois régulièrement importer le contenu.

De temps à autre, en raison de la présence de balises orphelines dans ces fichiers (balise ouverte mais non fermée ou le contraire), le traitement plante…

Je souhaiterais pouvoir vérifier l'intégrité des fichiers XML avant d'en exécuter l'import, afin de les corriger le cas échéant.

Exemple de fichier XML :
Code:

1 2 3 4 5 6 7 8 9 <BALISE1> <BALISE2>valeur</BALISE2> <BALISE3>valeur</BALISE3> </BALISE1> <BALISE4>valeur</BALISE4> <BALISE1> <BALISE5>valeur</BALISE5> <BALISE6>valeur</BALISE6> </BALISE7>
Dans cet exemple :

- La balise1 s'ouvre et se ferme correctement une fois (lignes 1 et 4), se rouvre (ligne 6) mais ne se ferme pas.
- La balise7 se ferme (ligne 9) mais ne s'est précédemment pas ouverte… D'où les 2 problèmes.

SVP, connaîtriez-vous un outil ou un script (idéalement vbscript) qui pourrait effectuer ce contrôle et en afficher les erreurs éventuelles ?

Merci d'avance pour vos précieux avis et conseils,
Cdt, Stéphane

C'est simple pour tester le bien-formatage d'un fichier xml. On peut rapidement écrire un vbscript pour ce but et uniquement pour ce but.
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 dim xfile, oparser, bret xfile="batch001234.xml" 'à préciser set oparser=createobject("msxml2.freethreadeddomdocument.6.0") with oparser .async=false .validateonparse=false .resolveexternals=true bret=.load(xfile) if not bret then wscript.echo xfile & " : mal-formé." wscript.echo "error code: " & hex(.parseerror.errorcode) & vbcrlf & "reason: " & .parseerror.reason else wscript.echo xfile & " : bien-formé." end if end with set oparser=nothing
On peut s'adapter pour qu'on recherche dans quelque répertoire et puis qu'on traite tous les candidats xml à traiter là-dedans. Aussi si par malheur vous n'avez pas v6.0 de msxml2.freethreadeddomdocument, trouvez la bonne version installée dans le système ou bien passez le moniker sans version par enlever la partie ".6.0" pour laisser le système à trouver une d'après le registre.

07/12/2018, 20h30
steph78630

Bonjour Tsuji,

merci pour votre réponse rapide et solution !

Je viens de l'essayer avec le fichier exemple de mon message et ça me retourne :

- Fichier mal formé
- Code d'erreur : C00CE555
- Raison : Un seul élément de niveau supérieur est autorisé dans un document XML

Je n'ai peut-être pas la bonne version de msxml2... ? (j'ai aussi essayé en enlevant ".6.0" à Set oparser =…)

En essayant sur l'un de mes fichiers de 20000 lignes, aurais-je davantage de précisions sur la ou les erreur(s) rencontrées ?

J'ai aussi remplacé dans mon fichier exemple balise7 par balise1 (ligne 9) afin qu'il n'y ait plus d'erreur dans le fichier mais j'ai toujours le même retour d'erreur (voir plus haut)
07/12/2018, 23h00
CosmoKnacki

Que les choses soient claires, l'outil que t'a donné tsuji ne sert qu'à afficher les problèmes de ton XML (ce qui correspond à ta demande). En aucun cas et d'aucune manière tu ne peux transformer un fichier corrompu (autrement dit: qui n'est pas du XML) en XML. À la limite tu peux effectuer des corrections dans la mesure ou tu disposes d'informations précises sur la structure attendue ou sur le type d'erreurs (mais ça restera du bricolage, mieux vaut solutionner le problème en amont si possible), mais en aucun cas tu ne peux espérer comme par miracle que ton XML soit comme il devrait être. Corrompu c'est foutu, mal formé c'est baisé.

Tout ce que tu peux attendre d'un parser, c'est qu'il applique des corrections automatiques à ton document, mais rien ne garanti que ce seront celles que tu souhaites.
07/12/2018, 23h18
steph78630

Bonjour @CosmoKnacki,

tout à fait, je n'attend pas d'un outil (ou d'un script) qu'il fasse les corrections du fichier XML à ma place (sur 20000 lignes j'aurais trop peur qu'il fasse n'importe quoi…)

Par contre, ce que j'espère d'un tel outil, c'est qu'il identifie les erreurs (balises en trop ou manquantes) et qu'il me précise la ligne (voire nom de la balise) ou l'erreur s'est produit.

Ainsi, ça me permettrait de corriger le fichier si peu d'erreurs (ton fameux "bricolage") et surtout d'intervenir en amont pour éviter l'erreur lors de l'écriture du fichier…

Aujourd'hui, j'ai régulièrement des fichiers XML qui plantent mais je ne sais pas ou et pourquoi.

Donc, si j'ai bien compris tes explications, ce n'est pas d'un parser dont j'ai besoin...
08/12/2018, 05h11
CosmoKnacki

Non tu as mal compris, tu as bien besoin d'un parser pour qu'il détecte les erreurs et c'est exactement ce que fait le code de tsuji. Seulement c'est ensuite à toi de lire et de comprendre les messages qu'il te renvoie (ce qui nécessite un minimum de connaissances du XML). Donc la première chose à faire est de lire un tutoriel de base sur le XML que tu trouveras probablement sur le site.

Ici tu obtiens comme raison: Un seul élément de niveau supérieur est autorisé dans un document XML. Cette erreur est produite dés que le parser rencontre <BALISE4> car à ce moment le parser se rend compte qu'il n'y a pas d'élément racine dans ton document (ou plutôt que celui-ci n'est pas unique puisque BALISE1 et BALISE4 sont au même niveau).

Si tu veux que le script t'indique la localisation de l'erreur, tu peux en plus afficher les propriétés .parseerror.line et .parseerror.linepos.
08/12/2018, 11h34
steph78630

Ok CosmoKnacki, merci pour ces précisions.

Pour davantage de précision sur l'erreur rencontrée, j'ai aussi ajouté .parseerror.srctext à l'affichage.

Sinon, malheureusement le formatage "non conventionnel" de ces fichiers XML m'est imposé, ce n'est apparemment pas du "pur" XML mais je dois faire avec ça.

Du coup, le code erreur C00CE555 qui s'affiche (Un seul élément de niveau supérieur est autorisé dans un document XML) est dans mon cas un "faux positif" qui arrête le script et bloque la détection des vrais problèmes.

Y aurait-il un moyen pour désactiver certaines fonctionnalités de détection ? (c'est uniquement la gestion des balises "orphelines" qui m'intéresse, et aussi de celle d'éventuels caractères spéciaux)

Stéphane
08/12/2018, 13h14
CosmoKnacki

Citation:

Sinon, malheureusement le formatage "non conventionnel" de ces fichiers XML m'est imposé, ce n'est apparemment pas du "pur" XML mais je dois faire avec ça.

Du point de vue terminologique, en toute rigueur, soit un document est du XML (donc bien formé à tout points de vue), soit il n'est pas du XML. Dans cette perspective, on parle alors de XML mal formé (parce que c'est pratique), mais c'est clairement un abus de langage.

Citation:

Du coup, le code erreur C00CE555 qui s'affiche (Un seul élément de niveau supérieur est autorisé dans un document XML) est dans mon cas un "faux positif" qui arrête le script et bloque la détection des vrais problèmes.

Y aurait-il un moyen pour désactiver certaines fonctionnalités de détection ? (c'est uniquement la gestion des balises "orphelines" qui m'intéresse, et aussi de celle d'éventuels caractères spéciaux)

Non, tu ne peux pas désactiver certaines détections, par contre tu peux ruser en ajoutant un élément racine avant de parser ton fichier: tu charges ton fichier dans une chaîne de caractères, tu ajoutes par exemple <root> au début et </root> à la fin^*, et tu charges le tout avec la méthode .loadXml() (à la place de .load()).

_{(* tu peux appeler cet élément comme tu veux, mais il faut éviter les noms de balises déjà présents dans le document.)}
08/12/2018, 15h28
steph78630

Eh eh !

C'est beaucoup mieux avec cette balise unique (<root> dans ton exemple) placée en début et fin de fichier !

Avec mon fichier exemple [après avoir corrigé les erreurs] et en gardant .load, j'ai désormais un résultat "Fichier bien formé"
Avec .LoadXml sur le même fichier, j'ai un code erreur C00CE556 - raison : "Non valide au niveau supérieur du document." - ligne 1, position 1

Sinon, avec l'un de mes fichiers balisés de 20000 lignes, c'est l'hécatombe (multiples problèmes d'accents, de simple cote et d'espaces dans les valeurs, etc.) et comme le script s'arrête à chaque erreur c'est la misère.

> Je rappelle que les soucis que je rencontre sont principalement des balises orphelines (ce qui n'est pas le cas ici) et que les valeurs accentuées sont bien gérées lors de l'import.

La solution proposée par @tsuji et @CosmoKnacki me semble très séduisante [parfaite ?] pour un fichier XML et je vous en remercie, mais l'utilisation avec mes fichiers "non normalisés" est beaucoup trop sensible…

Qu'en pensez-vous ?