Logiciel : Faites parler vos fichiers avec hachoir-metadata
Posté par Victor STINNER (page perso, ). Modéré le 19 décembre 2006.
0
Tous les jours, nous manipulons des dizaines de fichiers binaires sans vraiment se soucier de leur format ou de connaître toutes les informations qu'ils contiennent. Pourtant, ils sont souvent accompagnés de métadonnées qui renseignent sur leur origine et leur contenu : auteur, nom du logiciel, date de création, durée, taille, codec, genre, etc. Ces informations permettent une classification fine et des recherches multicritères très fines.
Hachoir-metadata, programme basé sur la bibliothèque Hachoir, permet de lire ces informations et les présente de manière synthétique. Tous les formats courants sont reconnus : image (JPEG, PNG, GIF, ICO...), vidéo (AVI, WMV, FLV, MKV...), audio (MP3, wav, Ogg, WMA...), archive (zip, gzip, bzip2, tar...).
Les informations sont triées par pertinence (ex les dimensions d'une image sont plus importantes que la méthode de compression). Pour les formats contenant plusieurs « documents », chaque document possède sa propre section (ex : les flux audio, vidéo et les informations générales sont séparés). Contrairement à certains outils où la présentation est calquée sur le format de fichier, hachoir-metadata classe des informations de manière générique (ex : le champ 'duration' est partagée pour une vidéo ou un son).
Hachoir-metadata n'est sûrement pas une révolution, il existe déjà une multitude de bibliothèques pour extraire les métadonnées. Mais, pour les formats supportés, il donne d'aussi bons résultats que ses concurrents voire parfois meilleurs. Au passage, essayez également le programme hachoir-urwid pour explorer vos fichiers en profondeur et découvrir d'autres informations passées sous silence.
![[en]](../images/en.png)
Hachoir-metadata, extracteur de métadonnées (1523 hits)-
Hachoir-parser, bibliothèque sur laquelle repose hachoir-metadata (222 hits)
-
Hachoir-urwid, explorateur de fichier binaire (463 hits)
-
Hachoir-strip, supprime les métadonnées inutiles (207 hits)
> Lire la dépêche (32 commentaires, moyenne: 2,8).
Vous avez demandé le commentaire #786434.
Run by 
Cette page a été générée par Templeet en 0.0632s (dont 0.0064 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Documents bureautique
Est ce qu'on peut imaginer hachoir-metadata récupérer les méta-données d'un document OpenOffice, PDF, MS Word ... ?
Alex.
[^]Re: Documents bureautique
Pour les documents Office, c'est essentiellement le format OLE2, et ce format est le plus complexe de tous les formats qui existent sur Terre. Un parseur a été entamé mais c'est pas encore ça. Aujourd'hui la meilleure bibliothèque pour lire ces informations est libgsf. Plus d'info par ici :
http://hachoir.org/wiki/MicrosoftOffice
Pour OpenOffice, rien n'a été fait pour l'instant, bien qu'un parseur ZIP existe et que Python a tout le nécessaire pour manipuler du XML.
Pour PDF, un parseur existait il y a bien longtemps, mais depuis il n'a pas été récupéré.
[^]Re: Documents bureautique
Je m'étais posé la question de la récupération du texte depuis les documents openoffice (.sxw et .odt), j'avais trouvé des scripts que j'ai mis (en citant les sources) sur mon blog. Le lien : http://genma.free.fr/article.php3?id_article=302 En espérant que ça aide...
"Le jour où tu découvres le Libre, tu sais que tu ne pourras jamais plus revenir en arrière..."
[^]Re: Documents bureautique
Mais en allant plus loin, est-ce que hachoir ne pourrait pas être la base des moteurs d'indexation ? Je ne sais pas comment sont architecturés beagle, strigi, ex-kat, etc... mais il me semble qu'ils pourraient utiliser hachoir, rendant ainsi l'écriture de plugins pour de nouveaux formats plus aisée. Actuellement, si on veut supporter un nouveau format de fichier pour ces moteurs, je suppose qu'il faut se coltiner la création d'une librairie ou alors en reprendre une existante, mais se coltiner l'interface entre la librairie et le moteur.
Avec hachoir, ce serait plus facile, je trouve. Même si les types de fichier les plus importants sont supportés actuellement, il en reste encore des milliers qui pourraient être indexés...
[^]Re: Documents bureautique
Mais en allant plus loin, est-ce que hachoir ne pourrait pas être la base des moteurs d'indexation ?
Ca peut se faire. hachoir-grep est un outil bourrin pour lister toutes les chaînes de caractère d'un fichier binaire. Il sort des chaînes en Unicode propre (si le charset est bien spécifié dans le parseur).
Sinon, hachoir-metadata vise les moteurs d'indexation / de recherche, mais en fait je n'ai jamais zieuté du côté de Beagle & co.
Je ne sais pas si Hachoir est assez rapide pour ces outils. Après il faut choisir vitesse ou qualité des infos :-p
[^]Re: Documents bureautique
Moi je vois en hachoir-metadata une brique très intéressante pour une GED en python :-)
[^]Re: Documents bureautique
Tracker utilise un démon nommé trackerd qui appelle tracker-extract pour sortir des metadata de documents. Les deux programmes sont écrits en C.
Le problème avec hachoir est le python... Le programme tracker-extract est lancé sur chaque fichier à traiter, puis il termine (s'il tourne encore au bout d'un certain laps de temps, il est tué). Sur des vidéos ou des fichiers sonores par exemple, GStreamer met déjà un certain temps à se lancer. Il me semble qu'un programme en Python serait encore plus coûteux à ce moment là parce qu'il apporterait un surcoût. D'autre part, j'ai aussi peur de la conso mémoire et de la rapidité de l'ensemble. Le but de Tracker est aussi d'utiliser le moins de RAM possible et de rester discret (le programme est très poli (nice 19) et demande à passer en dernier sur les opérations d'IO lorsque l'ordonanceur CFQ est utilisé). Tracker a aussi était proposé à l'inclusion dans GNOME 2.18, si cela était accepté, il serait considéré comme une pièce de bas niveau, à la hauteur de gnomevfs.
Autre chose : Hachoir évite l'utilisation de bibliothèques externes, si j'ai bien compris. Dans ce cas, cela déplace le moment où tracker en utilisera une. En effet, il faut de temps à autre extraire les données contenus dans des documents : Poppler pour les PDF, libGSF pour les fichiers OLE2, etc.
Enfin, si je ne me trompe en disant que Hachoir évite l'utilisation de bibliothèques extérieures, cela signifie que les développeurs de ce programme sont amenés à manipuler un très grand nombre de formats hétéroclites. En pratique, non seulement ces fichiers sont très différents, mais peuvent en plus être buggés vis à vis des spécifications (lorsqu'elles sont connues...) normalement attendues. J'ai donc très peu confiance en la capacité d'une petite équipe à arriver à autant d'expertise que plusieurs groupes qui se focalisent sur différents formats de fichiers...
[^]Re: Documents bureautique
Python est à la fois une désavantage et un avantage :
* il est plus lent qu'un programme en C et utilise plus de mémoire (des statistiques sur l'extraction de méta-données m'intéresseraient)
* mais il n'a pas les erreurs du langage C (buffer overflow, pointeur explosif & co) et est plus robuste avec sa gestion des exceptions
Hachoir résiste bien aux fichiers corrompus et tronqués. Je voulais sortir un exemple concret pour le prouver, mais là je me suis souvenu qu'hachoir-metadata est encore très sensible : il n'aime pas les fichiers tronqués :) Il plante lamentablement lorsqu'un champ est absent. Il faudrait que je trouve une solution élégante et générique pour corriger ça.
[^]Re: Documents bureautique
Et Victor créa l'infrastructure pour que l'humanité s'en saisisse et que les gourous insufflent leur connaissance des formats exotiques dans un parseur.
Tout comme le langage Python permet la manipulation directe d'abstractions plus évoluées que le C, la suite hachoir vise à nous permettre de considérer les conteneurs et les contenus de façon plus générique que ce qui a jamais été imaginé auparavant, et j'ai assez confiance qu'elle y parviendra.
[^]Re: Documents bureautique
Oui, mais il est vrai que pour résumer ce qui a été dit avant : généricité ne rime pas avec performance, malheureusement.
(sinon, ça ferait performancité, c'est pas beau...)