Journal Nouvelle version de hachoir-metadata tolérante aux erreurs

Posté par  (site web personnel) .
Étiquettes : aucune
0
15
avr.
2007
Hachoir-metadata est un logiciel permettant de lire les métadonnées d'un document : auteur d'une photo, codec d'une vidéo, durée d'une musique, etc. Il supporte énormément de formats, exemples (liste loin d'être complète) : WMA, Real audio/media, AVI, FLV, WMV, MKV, OGM, 7zip, RAR, ACE, EXE, TTF, Torrent, DOC, XLS, PPT, ...
http://hachoir.org/wiki/hachoir-metadata

La nouvelle version (0.10) a été réécrite en partie pour être tolérante aux erreurs, ce qui signifie qu'en cas d'erreur le programme ne s'arrête pas mais affiche simplement une erreur. Ceci permet d'extraire les métadonnées de fichiers tronqués ou erronés mais également de tolérer des erreurs dans Hachoir (coeur/parseur fichier).

Détails des changements

Des greffons pour Konqueror et Nautilus font leur apparition. Ils permettent de lire les métadonnées d'un fichier depuis le menu contextuel (clic droit).

De nouveaux formats sont supportés : documents Microsoft Office (Word, Excel, Powerpoint), New-style Executable (programme NE, Windows 16-bit), X11 Portable Compiled Font (.pcf) et Microsoft Archive (.mar).

Les données sont maintenant fortement typées : un numéro de piste est obligatoirement un entier, la date de création doit être une date, etc. Les chaînes de caractères sont maintenant obligatoirement en Unicode. Le filtre automatique des valeurs erronées (durée négative, chaîne vide, etc.) est un plus restrictif.

Enfin, une nouvelle option « --quality » permet de choisir la qualité des informations extraites ou plus exactement le temps alloué à l'extracteur (quality=0 : extraction rapide, quality=1 : extraction la plus complète mais surtout la plus lente). Cette option détermine par exemple le nombre de fichiers traités dans une archive ou la qualité de l'estimation du débit et de la durée d'un MP3 à débit varible (VBR).

Un programme de fuzzing a été écrit spécialement pour l'occasion. Il a permis de corriger énormément de bugs dans les différents composants d'Hachoir.

Nouvelle version des autres composants d'Hachoir

hachoir-core sort en version 0.9 (c'est essentiellement des corrections de bugs). hachoir-parser sort en version 0.10. Les nouveaux formats supportés : Archive Microsoft (.mar), icône animée pour Microsoft Windows (.ani), aide Microsoft HTML (.chm), raccourci Windows (.lnk), X11 Portable Compiled Font (pcf), Adobe Portable Document Format (PDF).

Détails des changements sur :
http://cheeseshop.python.org/pypi/hachoir-core
http://cheeseshop.python.org/pypi/hachoir-parser

Liste complète des formats supportés par Hachoir :
http://hachoir.org/wiki/hachoir-parser
  • # Strigi

    Posté par  . Évalué à 4.

    Je me demandais, comme ça, est-ce que tu penses que ton projet pourrait collaborer avec strigi d'une façon ou d'une autre ? En ce moment il y a un port des KFilePlugins pour extraire les métadonnées http://wiki.kde.org/tiki-index.php?page=Porting+KFilePlugin+(...) . De ce que j'en ai lu il est très rapide.
    • [^] # Re: Strigi

      Posté par  (site web personnel) . Évalué à 4.

      J'ai pris contact avec les développeurs, mais pour l'instant on n'a rien fait ensemble. Ils m'ont proposé d'écrire un plugin pour Strigi. Je pense par contre qu'Hachoir est très lent et c'est donc pas une bonne idée de l'utiliser avec Strigi.
  • # bonjour

    Posté par  . Évalué à 4.

    dabord merci pour cette outil, j'ai essayé de l'utiliser (pensant que c'etait possible hein ! ) pour extraire/detecter une image bmp perdu dans un fichier binaire.

    je sais qu'ici ce n'est pas un forum mais j'ai un message d'erreur qui me laisse perplexe:

    [err!] [<SpiderManVideoFile>] Hachoir can't extract metadata, but is able to parse: Rom.bin

    si je comprend bien il peut le faire mais ne veut pas, et quelque soit l'options passées il me repond toujours la meme chose. Est ce que l'erreur UnicodeDecodeError: 'ascii' codec can't decode byte 0xff in position 0: ordinal not in range(128) que j'obtiens en mode debug expliquerais le probleme ?

    d'apres http://www.haypocalc.com/wiki/Hachoir il doit etre possible de : Transformation d'un fichier binaire en document XML représentant sa structure c'est ce qui m'interresse ici.

    c'est un fichier de bios, le but etant de changer le logo de demarrage.
    http://awdbedit.sourceforge.net/
    et Phoenix Bios Editor Pro ne veulent pas toucher a mon bios (Rom.bin)
    • [^] # Re: bonjour

      Posté par  (site web personnel) . Évalué à 2.

      Tu peux toujours tenter de repérer la chaine "BM" dans ton fichier binaire. Tu aura déjà l'offset de l'image dans fichier binaire. Ensuite, si tu connais les propriétés de ton image(couleur, hauteur, largeur), il n'y a pas de raison que la taille du BMP soit différente de celle pré-inclu. Bon, ceci-dit, avant d'aller flasher mon bios avec un fichier après ce genre de bidouille, je me méfierais à mort. On peut imaginer que d'un logiciel à l'autre, le BMP ne soit pas tout à fait de taille identique. On peut imaginer que le logiciel qui inclut le BMP dedans ne l'inclut pas tel quel. On peut imaginer qu'il y ait un BM quelque part sans que ça soit l'image... .
    • [^] # Re: bonjour

      Posté par  (site web personnel) . Évalué à 5.

      « d'apres http://www.haypocalc.com/wiki/Hachoir il doit etre possible de : Transformation d'un fichier binaire en document XML représentant sa structure c'est ce qui m'interresse ici. »

      Hum, effectivement, Hachoir pouvait le faire, mais j'ai supprimé le code car ce n'était pas interactif et pas assez souple. Aujourd'hui, j'utilise uniquement hachoir-urwid qui permet d'avoir une visuallisation de ce genre :
      http://hachoir.org/wiki/hachoir-parser/examples

      « j'ai essayé de l'utiliser (pensant que c'etait possible hein ! ) pour extraire/detecter une image bmp perdu dans un fichier binaire »

      ... euh, c'est pas le bon outil, par contre, hachoir-subfile a exactement cet objectif :
      http://hachoir.org/wiki/hachoir-subfile

      Je n'ai pas encore publié de version stable car l'outil est encore pas mal expérimental, néanmois il est possible de le tester avec :
      http://hachoir.org/wiki/Install/snapshot

      Il faudra alors utiliser une commande du genre « hachoir-subfile Rom.fin --category=image ».

      L'erreur « [err!] [<SpiderManVideoFile>] Hachoir can't extract metadata, but is able to parse: Rom.bin » indique que Hachoir pense que ce fichier est une vidéo du jeu SpiderMan et hachoir-metadata ne sait pas lire les métadonnées de ces vidéos. Bon, c'est un bug, ce fichier n'est sûrement pas une vidéo SpiderMan :-p
  • # gestion de trame ?

    Posté par  (site web personnel) . Évalué à 2.

    Est-ce que hachoir gère les trames ?

    En gros, un fichier est le plus souvent une arborescence de champs qui forment des paquets souvent de tailles fixe ou alors avec des tailles précisés.

    Un trame, c'est l'inverse. Taille fixe mais donnés pas forcément de taille fixe. J'ai vu un exemple (CCSDS) ou l'entète de trame donnait l'offset de démarage du prochain paquet.

    J'imagine que les flux genre mpeg2 doivent avoir ce genre de découpe.

    "La première sécurité est la liberté"

    • [^] # Re: gestion de trame ?

      Posté par  (site web personnel) . Évalué à 4.

      Un travail est en cours depuis 6 mois pour supporter les flux fragmentés. Le système de fichier FAT a été le premier à avoir cette fonction, puis Ogg a suivi. Et très récemment, j'ai écrit le support pour les fichiers Microsoft Office qui sont très fragmentés. MPEG TS (Transport Stream) et MPEG PES utilisent aussi le découpage en petit paquet, mais ce n'est pas (encore?) supporté dans Hachoir.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.