Utilitaire de réparation de fichier XML

[Scrat]

Bonjour.

Mise à jour du 20 novembre 2020 => Version 1.0.9

Je vous propose ici la dernière version d'un petit utilitaire de réparation de fichier XML écrit en langage Java que je vous propose de tester.

Vous devez donc avoir Java d'installé, ce qui est normalement le cas si vous avez suivi les tutoriels d'installation de Apache Open Office ou de Libre Office.

Je mets en ligne l'archive XmlRepar_v_1_0_9.zip qui contient un dossier XmlRepar_v_1_0_9, lequel contient l'exécutable XmlRepar.jar et un sous-dossier lib contenant les bibliothèques nécessaires.

XmlRepar_v_1_0_9.zip

Pour mémoire, je laisse ici l'ancienne version 1.0.8

XmlRepar_v_1_0_8.zip

Un tutoriel complet est disponible sur cette page. Ce tutoriel est un fichier Writer au format odt qui s'ouvre en lecture seule. Vous pouvez le télécharger directement par ce lien. Je le résume ci-dessous.

Dézippez l'archive et stockez le dossier XmlRepar_v_1_0_9 où vous le désirez. Pour lancer l'utilitaire, vous avez deux possibilités:
- par double clic sur l'icône du fichier XmlRepar.jar dans l'explorateur,
- en ligne de commande avec le code suivant

Code : Tout sélectionner

java -jar {chemin du dossier XmlRepar_v_x_x_x}/XmlRepar.jar

Dans cette ligne de commande, x_x_x est le numéro de version.

Une fenêtre s'ouvre avec une barre de menu et une zone de texte. La barre de menu contient les menus Fichier et Aide. L'aide vous donne quelques informations sur ce que peut faire l'utilitaire, sinon tout se gère par le menu Fichier en suivant les indications de la zone de texte:

- 1. Utilisez le menu Fichier->Ouvrir pour sélectionner le fichier à traiter, ce qui ouvre une fenêtre de l'explorateur pour choisir votre fichier XML.

- 2. Utilisez le menu Fichier->Réparer pour démarrer l'analyse du fichier. Vous avez une barre de progression qui s'anime au bas de la fenêtre et un message apparaît dans la zone de texte lorsque le travail est terminé. Utilisez l'ascenseur à droite pour voir le détail des erreurs corrigées.

Le fichier réparé est stocké sous un nom différent dans le même dossier que le fichier sélectionné. Ainsi, si vous avez sélectionné le fichier content.xml, le fichier réparé se nommera content_repare.xml.

- 3. Utilisez le menu Fichier->Ouvrir pour sélectionner un autre fichier, ou le menu Fichier->Quitter pour fermer l'application.

Attention : Réalisez toujours les tentatives de réparation sur une copie de votre document !

Je joins également une archive contenant un exemple de fichier corrompu et le résultat attendu après correction. Bons tests et merci pour vos retours.

exemple_xml.zip

Je ne prétends pas que cet utilitaire va résoudre tous les problèmes, mais il devrait être efficace pour la suppression des multiples définitions d'un attribut. Il peut aussi corriger les définition incorrectes lorsque le signe " est absent après la valeur de l'attribut. Enfin il peut aussi réparer la structure des blocs lorsqu'il trouve des balises orphelines ou lorsque le fichier est tronqué, mais le résultat risque de ne pas être interprétable par AOO/LibO, auquel cas il faudra tout de même mettre les mains dans le cambouis. Dans tous les cas, je conseille d'éditer le fichier pour l'examiner avant de tenter une réparation. En particulier, si la fin du fichier n'est plus que de la bouillie, la supprimer facilitera le travail de l'utilitaire... et lui évitera peut-être de se planter.

A+

[Jeff]

Bonjour,

Merci pour ce nouvel utilitaire, qui plus est multi-plateforme .
(pour mémoire, Scrat a également fourni un Outil de récupération de texte également sous Java)

Pour ceux qui voudrait tester sous Linux, une fois l'archive extraite :

• 1. Via le terminal :
     • Ouvrir un terminal (voir [Aide Linux] Utiliser le Terminal...)
     • Accéder au répertoire contenant le fichier XmlRepar.jar
     • Utiliser la ligne de commande ci-après pour interpréter le fichier :

       Code : Tout sélectionner

       java -jar XmlRepar.jar

       et valider
  2. Via l'interface graphique (réalisée ici sous Xubuntu, donc avec Xfce)
     • Clic-droit sur le bureau > Créer un lanceur
       • Renseigner le nom voulu
       • Renseigner un éventuel commentaire
       • Renseigner la commande suivante :

         Code : Tout sélectionner

         java -jar XmlRepar.jar

       • Renseigner le répertoire de travail
       • Hormis le chemin du répertoire de travail qui varie selon votre configuration, le lanceur devrait ressembler à :
         
         Capture d’écran_2018-03-08_11-52-42.png

         Ajout : Sous certains environnement (par exemple Debian avec le bureau Mate), il n'est pas prévu de possibilités pour renseigner le répertoire de travail. La commande doit donc fournir le chemin : Code : Tout sélectionner java -jar /home/salon/XmlRepar_v_1_0_7/XmlRepar.jar .

         Au premier lancement, cliquer sur le bouton "Marquer exécutable"
• L'utilitaire s'affiche :
  
  Capture d’écran_2018-03-08_09-58-12.png
• Le programme étant lancé, utiliser le menu Fichier > Ouvrir, et sélectionner le fichier.xml concerné
  
  Capture d’écran_2018-03-08_10-01-35.png
• Utiliser le menu Fichier > Réparer pour lancer la réparation :
  
  Capture d’écran_2018-03-08_10-02-09.png
• Le programme vous donne (assez rapidement pour un fichier sain) un résumé, et vous informe que le traitement est terminé
  
  Capture d’écran_2018-03-08_10-03-33.png
• Pour quitter l'utilitaire, menu Fichier > Quitter
  
  • Si vous utilisez le terminal, celui-ci a de nouveau la main, pour ensuite fermer le Terminal, saisir

    Code : Tout sélectionner

    exit

    puis valider

[Jeff]

Je poste à part mes observations

• Ergonomie :
  Serait-il possible que lorsque l’on utilise la commande Fichier > Ouvrir, on accède directement au dossier contenant l’utilitaire ?
• Fonctionnement :
  • Que ce soit sur Linux Xubuntu ou Windows 10, lorsqu’un fichier est réparé, j’ai un doublon nommé input_copy.xml qui est créé dans le dossier contenant l’utilitaire ; a priori, il s’agit du content.xml original.
    (dans tous les cas, le fichier content_repare.xml est bien dans le dossier du content.xml original )
    
    XmlRepar1.png
  • J’ai un fichier a priori sans histoire :
    Sous-total_avec_Decaler.ods
    L’utilitaire me signale une valeur malformée corrigée à la position 15 067 sur 15 190, autant dire vers la fin.
    
    XmlRepar2.png
    Si je recherche le terme incriminé, je vois la différence suivante entre le content.xml et le content_repare.xml
    
    XmlRepar3.png
    Pour le coup, il y a une erreur de syntaxe, et si je relance l’utilitaire, il n’arrive pas à réparer son erreur.
• Cosmétique
  
  Sous Linux uniquement, le dialogue Aide > À propos est tronqué, le bouton Fermer est à peine visible (ok sur W10, je peux te faire une copie-écran au cas où)

Tout cela reste sur le mode de la critique constructive

Pour l’instant, j’ai "piégé" involontairement l’utilitaire sur un fichier a priori sain, cela n’enlève rien a ses capacités sur les fichiers défectueux

[Scrat]

Bonjour Jeff.

Merci pour ces retours constructifs.

Concernant le premier point, je ne comprends pas trop ce que tu veux. Pourquoi accéder au dossier contenant l'utilitaire ? Le menu Fichier->Ouvrir ne sert qu'à aller chercher le fichier que tu veux réparer, et je déconseille de travailler dans le dossier XmlRepar. Mais je peux toujours essayer de rajouter cette possibilité.

Concernant le second point, le fichier input_copy.xml est effectivement une copie du fichier d'entrée faite pour la mise au point du décodage et du codage des caractères spéciaux... et que j'ai oubliée dans le code. Cette copie sera supprimée dans la prochaine mise à jour.

Concernant le troisième point, tu as effectivement trouvé comment piéger l'utilitaire. Pour détecter les attributs, je ne pouvais utiliser ni le signe = ni l'espace puisque ces deux caractères peuvent se retrouver dans la valeur d'un attribut. Je ne pouvais pas non plus utiliser le caractère " qui peut manquer au début ou à la fin d'une valeur malformée. J'ai donc choisi de détecter la déclaration d'attribut par la suite des deux caractères =". L'inconvénient, c'est que les attributs pour lesquels le caractère " manque au début ne sont pas détectés. Mais je n'avais pas prévu qu'une valeur d'attribut puisse être réduite au seul signe = ou se terminer par =. J'ai modifié le code pour prévoir la présence de la chaîne ="=" et maintenant ton document est reconnu comme sain (ouf ! ). La correction sera dans la prochaine mise à jour.

Pour le côté "Cosmétique" sous Linux, je crois comprendre d'où ça vient, mais c'est étonnant que l'affichage soit correct sur un OS et pas sur l'autre. Work in progress...

De toute façon, je dois préparer la prise en compte de la présence de commentaires dans un fichier XML. Toutes les corrections seront dans la prochaine version dans mon premier message que je réactualiserai dans quelques jours

Je suis toujours intéressé par des retours avec des exemples qui piègent l'utilitaire. Merci aux volontaires.

A+

[Jeff]

1. Pourquoi accéder au dossier contenant l'utilitaire ?

   En fait, je travaille assez "loin" dans l'arborescence, avec une structure de fichier qui fait que le répertoire dans lequel je mets les utilitaires de récupération est voisin du répertoire dans lequel je mets les fichiers à traiter.
   
   Du coup, je suis obligé de "remonter" toute l'arborescence pour ouvrir un fichier, alors qu'il suffirait de descendre d'un dossier pour remonter immédiatement dans le dossier voulu.
   
   Je pense cependant que c'est plus logique pour l'utilisateur standard, donc la modif est probablement inutile.

2. le fichier input_copy.xml [...] Cette copie sera supprimée dans la prochaine mise à jour.

   

3. c'est étonnant que l'affichage soit correct sur un OS et pas sur l'autre

   Avec Xubuntu 16.04 32 bits installé "nativement" (j'entends par la qu'il ne s'agit pas d'un dual-boot ou autre, c'est le seul OS du poste) :
   
   Xfce.png
   J'ai voulu testé avec Ubuntu 16.04 x64, version qui, pour le coup, est installée dans une machine virtuelle, et tourne avec openJDK (du Java OpenSource), là par contre, ça crashe avec le log suivant :

   Code : Tout sélectionner

   jeff@jeff-VirtualBox:~/Téléchargements/XmlRepar/XmlRepar$ java -jar XmlRepar.jar 
   #
   # A fatal error has been detected by the Java Runtime Environment:
   #
   #  SIGSEGV (0xb) at pc=0x00007fe9fd9ef009, pid=2911, tid=2935
   #
   # JRE version: OpenJDK Runtime Environment (9.0) (build 9-internal+0-2016-04-14-195246.buildd.src)
   # Java VM: OpenJDK 64-Bit Server VM (9-internal+0-2016-04-14-195246.buildd.src, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
   # Problematic frame:
   # C  [libjava.so+0x1d009]  JNU_GetEnv+0x19
   #
   # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/jeff/Téléchargements/XmlRepar/XmlRepar/core.2911)
   #
   # An error report file with more information is saved as:
   # /home/jeff/Téléchargements/XmlRepar/XmlRepar/hs_err_pid2911.log
   #
   # If you would like to submit a bug report, please visit:
   #   http://bugreport.java.com/bugreport/crash.jsp
   # The crash happened outside the Java Virtual Machine in native code.
   # See problematic frame for where to report the bug.
   #
   Abandon (core dumped)

   Le fichier log zippé, je n'y comprends absolument rien, mais si ça peut aider :
   hs_err_pid2911.log.zip
   J'essaierai en installant la version Java d'Oracle, mais plutôt courant semaine prochaine.

[Scrat]

Bonjour.

Mise à jour en version 1.01 dans mon premier message: désormais, le nom du dossier contenant l'application porte le numéro de version pour éviter toute confusion.

Modifications apportées:
- première ouverture de l'explorateur dans le dossier de l'application, puis ouvertures suivantes dans le dernier dossier ouvert.
- copie du fichier d'entrée supprimée.
- modification de la détection des attributs pour tenir compte de la présence éventuelle de la chaîne ="=" qui provoquait une fausse détection dans la première version, plus ajout de quelques tests pour éviter d'avoir des caractères bizarres dans le nom d'une balise malformée.
- prise en compte de la présence de commentaires avec réparation des commentaires malformés.
- retouche de la fenêtre A propos, en espérant que ça passe sous Linux.

Quant au crash avec OpenJDK, je n'ai pas suffisamment de connaissances en java pour comprendre ce qui se passe. Apparemment, Java ne trouve pas certains fichiers relatifs à la partie graphique (voir messages File not found, Class not found).

L'utilitaire est développé dans Netbeans 8.2 tournant avec le JDK 1.8 d'Oracle sous Vista 32 bits, et le projet est construit avec le Swing Application Framework qui crée automatiquement la partie graphique avec les menus. Dans ses mises à jours de NetBeans , Oracle avait supprimé cette possibilité en préconisant de passer plutôt par la plateforme NetBeans, mais c'est une usine à gaz beaucoup trop lourde pour des applications simples comme la mienne et beaucoup d'utilisateurs ont râlé. Oracle a donc rétabli les bibliothèques Swing Application Framework dans Netbeans, mais ces bibliothèques ne sont plus maintenues. Éventuellement, pour une utilisation avec OpenJDK, je peux fournir les trois fichiers des classes java qui traitent les fichiers XML (classes FileParser, Block et Balise), à charge pour l'utilisateur de construire son interface, graphique ou pas.

Ajout : Concernant le crash avec OpenJDK 9, j'ai trouvé un rapport de bogue sur le net qui renvoie les mêmes messages d'erreur: https://bugs.openjdk.java.net/browse/JDK-8173626 Ce bogue est en rapport avec celui-ci pour l'application Swing "Hello world" qui ne fonctionne pas: https://bugs.openjdk.java.net/browse/JDK-8159050 Et la réponse faite dans le premier rapport: Email sent to the Submitter: As per the submitted report, The issue is coming from OpenJDK 9ea. We would highly recommend you to try running with Oracle's JDK 9ea latest build.

A+

[Jeff]

retouche de la fenêtre A propos, en espérant que ça passe sous Linux

Nickel

Capture d’écran_2018-03-10_18-21-56.png

Si je veux chipoter, je dirai qu'il manque la version de l'utilitaire dans l'intitulé de la fenêtre , du coup, comme le numéro de version apparaît clairement dans le contenu de la fenêtre, je virerai le numéro de version dans l'intitulé de la fenêtre.

try running with Oracle's JDK

Yes oui canne

[Scrat]

Bonjour.

Mise à jour du 15 mars 2018 en version 1.0.2 dans le premier message:

- amélioration de la robustesse (ajout de protections contre les plantages),
- amélioration de la détection des champs (balises et attributs),
- suppression des caractères non autorisés dans les noms des champs,
- résultats d'analyse plus détaillés et mieux formatés,

A+

[HRk2o]

Bjr,

testé sur Mac OsX El Capitan, pas de problèmes apparus sur les fichiers en exemple.
Ce sera un +++ car ni WinRar ni CZip n'existaient pour OsX

[Scrat]

Bonjour.

Mise à jour du 20 mars 2018 en version 1.0.3 dans le premier message.

Correction d'un problème de détection qui faisait que certaines erreurs pourtant corrigées n'apparaissaient pas dans dans le résultat de l'analyse.

A+

[Scrat]

Bonjour.

Mise à jour du 10 juin 2018 en version 1.0.4 dans le premier message.

Cette version améliore la robustesse en éliminant le problème rencontré avec un fichier très corrompu qui provoquait un dépassement de tableau.

Pour les puristes, la modification consiste à ignorer un caractère < s'il est isolé au sein d'une balise et à ignorer un caractère > s'il est isolé en dehors d'une balise, ceci afin de préserver l'alternance des caractères < et >.

Naturellement, tous les cas de corruption ne peuvent pas être prévus, et un plantage de l'outil de réparation est toujours possible. C'est pourquoi il est toujours recommandé de faciliter le travail de l'outil de réparation en éditant le fichier XML pour éliminer tout ce qui parait trop corrompu à la fin, en particulier si le fichier a été tronqué. Plutôt que de laisser des scories, il est préférable d'élaguer le fichier proprement, et l'outil de réparation sera toujours capable de reconstituer les balises manquantes pour fermer les blocs et avoir une fin de fichier correcte.

A+

[zeguedon]

Salut,

Voilà une belle initiative qui va nous épargner bien des maux de tête et nous faire gagner de précieuses minutes
Sans compter qu'à terme l'utilisateur lambda pourra se dépanner seul.
Testé sous Linux.

A+

[Scrat]

Bonjour.

Mise à jour du 16 juillet 2018 en version 1.0.5 dans le premier message.

Cette mise à jour corrige une petite régression de la version 1.0.4 où certaines balises récupérables par la version 1.0.3 étaient ignorées, et elle améliore encore la robustesse du code vis à vis des fichiers très corrompus.

Jusqu'à la version 1.0.4, seules les balises étaient analysées et corrigées, et le contenu texte des blocs était reproduit tel quel. Avec cette nouvelle version, le contenu texte des blocs est également analysé pour éliminer tous les caractères & isolés qui affichent des erreurs dans les éditeurs XML.

En effet, dans un fichier ODF, certains caractères que vous écrivez sont remplacés dans le content.xml par une séquence du type &xxx;, par exemple l'apostrophe, ou le caractère & lui-même. Exemples:

- la chaîne de caractères "l'apostrophe" est transcrite "l&apos;apostrophe".

- la chaîne de caractères "truc & bidule" est transcrite "truc &amp; bidule".

L'absence du caractère ; après un caractère & provoque une erreur dans les éditeurs XML. La nouvelle version de l'outil de réparation élimine donc tous les caractères & qui ne sont pas associés à un caractère ;.

A+

[Scrat]

Bonjour.

Mise à jour du 30 Septembre 2018 en version 1.0.6 dans le premier message.

Cette mise à jour améliore l'analyse du contenu texte des blocs introduite dans la version 1.0.5.

A la suppression des caractères & isolés qui provoquent des erreurs, cette nouvelle version ajoute la suppression de tous les caractères de contrôle que la corruption du document aurait pu ajouter au contenu texte des blocs et qui provoquent également des erreurs.

En pratique, cela signifie que la valeur décimale d'un caractère dans le codage ASCII doit être supérieure à 31. Seuls trois caractères de contrôle de valeur inférieure à 32 sont admis:
1) caractère CTRL+I pour la valeur décimale 9 (caractère HT pour Tabulateur horizontal)
2) caractère CTRL+J pour la valeur décimale 10 (caractère LF pour Line Feed ou NL pour New Line)
3) caractère CTRL+M pour la valeur décimale 13 (caractère CR pour Carriage Return)

Par exemple, sur un document récent que j'avais dû réparer manuellement, la nouvelle version 1.0.6 permet de supprimer un caractère ESC (Escape) de valeur décimale 27 dans un bloc de texte qui provoquait un message d'erreur.

La liste des caractères autorisés ou non au sein des blocs pourra être modifiée dans les versions ultérieures en fonction des retours d'expérience, car j'ai un peu la flemme de lire toute la documentation de la syntaxe XML et de tester tous les caractères de contrôle.

A+

[tintin]

Utilisation de XMLRepar sur MacOSX
+ outil de compression-décompression The Unarchiver (plus performant que l'outil de base)
+ AOO 4.1.5 et/ou LibO 6.0.6.

Comme signalé ici
Pour les utilisateurs de Mac, après opération complète de la réparation, la demande d'ouverture provoque l'ouverture d'une fenêtre proposant la réparation du fichier.

XmlRepar_reparation_fichier.png

La document s'ouvre mais à chaque ouverture demandée on observe le même comportement sur Mac comme sur les autres configurations.

@tintin: même message d'erreur que toi avec ton fichier.

Le document une fois ainsi ouvert doit être enregistré sous et refermé.
Il s'ouvre alors normalement sans cette demande de réparation.

Et bravo Scrat

[Diulf]

Merci beaucoup pour ce petit utilitaire des plus utile !

[Scrat]

Bonjour et bananier... euh... pardon, bonne année.

Mise à jour du 17 Janvier 2019 en version 1.0.7 dans le premier message.

Cette version 1.0.7 améliore la robustesse du code en corrigeant une erreur de logique entraînant un dépassement de tableau en cas de forte corruption du fichier lorsque les noms de balises ou d'attributs sont indécodables. De plus, une petite partie du code particulièrement bordélique a été réorganisée pour plus de clarté.

Par ailleurs, la reconnaissance d'un nouveau type d'erreur est prise en compte: le caractère ":" ne pouvant apparaître qu'une seule fois dans un nom, les éventuelles occurrences supplémentaires sont remplacées par le caractère "_". Mais dans ce cas, il est probable que le nom reconstitué ne sera pas reconnu et il faudra terminer la réparation en éditant le fichier.

Cerise sur le gâteau, cette nouvelle version vous inflige la lecture d'un message de mise en garde lorsque vous lancez la réparation du premier fichier ouvert. Oui, je sais, je suis ch... mais cette mise en garde vous explique pourquoi la réparation peut produire un fichier apparemment correct mais qui provoquera une erreur, et quoi faire dans ce cas. Ce message n'apparaîtra que pour le premier fichier si vous enchaînez les réparations sans fermer le logiciel.

J'ai validé cette version sur mes cas tests et sur un gros fichier qui faisait planter la précédente version, mais merci pour vos retours éventuels.

A+

[Jeff]

Merci pour cette nouvelle mouture

[Scrat]

Bonjour.

Mise à jour du 27 Juillet 2019 en version 1.0.8 dans le premier message.

Cette mise à jour corrige quelques erreurs:

- correction d'une erreur de logique qui faisait que, selon le niveau de corruption, certains attributs malformés n'étaient pas corrigés.

- prise en compte de la possibilité d'un en-tête de fichier composé de plusieurs blocs.

Normalement, l'en-tête est composé d'une balise de nom "xml" sur la première ligne, les deux premiers caractères étant < et ? et les derniers caractères étant ? et >.

Mais sur certains documents Microsoft, il existe une seconde balise d'en-tête de nom "mso-application". Cette situation non prévue entraînait des messages d'erreur même si le fichier était correct. Dorénavant, la possibilité d'un en-tête composé de plusieurs balises est prévue, la première devant être la balise "xml".

Enfin, cette nouvelle version apporte quelques petits changements cosmétiques:

- réapparition du "splashscreen" pendant le chargement du logiciel. C'est une image png qui avait disparu lorsque j'ai abandonné mon vieux PC Windows pour un PC Linux, le chemin de l'image étant resté celui du PC Windows.

- le message d'avertissement que je vous avais infligé à la version précédente et qui apparaissait systématiquement avant la première réparation a migré.
Il faut reconnaître que c'était particulièrement gonflant !
Ce message est maintenant accessible par l'item "Avertissement" dans le menu "Aide". Un très court message en fin du résumé de réparation dans la fenêtre principale vous invite à le consulter.

Note: dans le premier message, j'ai définitivement supprimé la version 1.0.5 que je considérais jusqu'ici comme une référence. Dorénavant, vous ne trouverez dans ce message que la dernière version disponible.

Bonne mise à jour.

A+

[Scrat]

Bonjour.

Mise à jour du 20 novembre 2020 en version 1.0.9 dans le premier message.

La précédente version ne détectait pas tous les caractères non autorisés dans les zones de texte, et certains fichiers corrompus étaient considérés comme corrects.

Cette mise à jour prend en compte l'ensemble des caractères autorisés selon la spécification XML 1.0.

A+