URL: https://linuxfr.org/users/mildred/journaux/en-finir-avec-libmagic Title: En finir avec libmagic Authors: Mildred Date: 2007年06月09日T23:25:17+02:00 Tags: Score: 0 Ou la difficulté de connaître le type d'un fichier **Ce qui existe actuellement** Je ne vais pas parler de Mac OS qui est en avance sur ce point là mais juste regarder ce qui est a présent utilisé sur nos bureaux libres et moins libres comme Windows : D'abord il y a l'ignoble extension accolée au nom du fichier. L'avantage indéniable de cette solution c'est qu'elle est facile a mettre ne oeuvre et qu'il est facile de modifier l'extension, .doc le type, du fichier. Mais cela pose aussi plusieurs problèmes : - Ce n'est pas très élégant. Pensez ce que vous voulez mais pour moi un nom de fichier ne doit pas contenir d'autres méta-données. Que pensez vous de stoker en plus la date de modification dans le nom du fichier ? - Ce n'est pas assez pour identifier un type de fichier, surtout si on se limite à l'extension à 3 lettres. - Il est trop facile de modifier l'extension par mégarde sans qu'on le veuille. Pour des utilisateurs novices cela peut poser un problème évident. Une autre solution qui évite pas mal ces problèmes c'est le nombre magique (magic number) au début du fichier. C'est très bien mais : - Certains formats de fichiers (comme le format texte) ne possèdent pas cette information. - Certains formats de fichiers peuvent être détectés comme d'un autre format. Par exemple un fichier Open Document est en fait une archive ZIP. Son nombre magique est celui d'une archive ZIP et sera incorrectement vu comme une archive ZIP. Même si cette solution est meilleure, ce n'est pas encore ça car ses limites nous force a continuer d'utiliser les extensions de fichiers. **Mais de meilleures solutions existent** Ah ? Quelles sont-elles ? Mac OS qui depuis bien longtemps déjà nous fournit une interface utilisateur conviviale avait utilisé le système OSType. Cette information détermine le type de fichier de manière cependant limitée. C'est pour cela qu'elle a été depuis abandonnée. On connaît aussi très bien le type MIME souvent associé aux e-mails et de la forme type/subtype (comme text/plain). Cette méthode est l'une des meilleures et aussi très utilisée sur Internet. Mais cependant a de petits inconvénients comme le manque de standardisation des types mime (pour les types qui ne sont pas enregistrés auprès de l'IANA) Apple comprenant les critiques de ses utilisateurs concernant l'utilisation des extensions a décidé (depuis Mac OS 10.3) d'utiliser un système alternatif : UTI (Uniform Type Identifier). Ce système a l'avantage de limiter les collisions avec l'utilisation de la notation DNS inversée. Ainsi par exemple une image PNG aura le type `public.png` et une image PICT aura le type `com.apple`. Ce Chaque type peut aussi hériter d'un ou plusieurs autres types permettant ainsi une grande flexibilité (ce que ne propose pas le type MIME). Ainsi un fichier JAR de type `com.sun.java-archive` hérite entre autre de `public.archive`. **Mais pourquoi ne les utilise-t-on pas ?** Le principal problème c'est que l'information sur le type du fichier doit aller dans les méta-données et que traditionnellement, sauf pour quelques systèmes, le type du fichier n'y est pas inclus. Ce plus cela implique de fournir le type de fichier lors des transferts de fichiers. Ce problème est en partie résolu par l'utilisation extensive du type MIME dans beaucoup de protocoles. Cependant, la plupart des systèmes de fichiers actuels supportent l'utilisation d'attributs étendus. Alors que reste-t-il pour nous empêcher ? Même si cela est possible, cela reste a standardiser pour que cela soit utilisable. Pour le moment les bureaux libres ne considèrent pas ce problème. GNOME et KDE (pour ne prendre que les deux les plus considérés) utilisent les nombres magiques doublés de l'extension du fichier pour lever les ambiguïtés. Mais cela n'est pas toujours pratique. Ainsi par exemple, si on cherche à ouvrir un fichier avec nautilus, et que ce fichier a un nombre magique qui contredit l'extension, une boîte de dialogue nous informe qu'on ne peux ouvrir le fichier (pour des raisons de sécurité). Ces cas peuvent facilement se produire lorsque par exemple un format de fichier consiste en un des données gzippées. **Qu peut-on faire ?** Je ne sais pas, j'invite tout le monde qui a de bonnes idées a les proposer. L'idéal serait que freedesktop.org nous propose un format standard (de préférence utilisant des standards existants) qu'il soit possible d'inclure dans les attributs étendus, et qu'il soit développé des outils en ligne de commande (et aussi pour nautilus, konqueror, thunar, rox, ...) pour facilement voir et modifier cette information. Mais je n'ai malheureusement rien vu de tel. Et vous, qu'en pensez-vous ? **liens** [http://www.gnome.org/learn/users-guide/latest/nautilus-open-(...)](http://www.gnome.org/learn/users-guide/latest/nautilus-open-file.html) [http://developers.sun.com/solaris/articles/integrating_gnome(...)](http://developers.sun.com/solaris/articles/integrating_gnome.html) [http://developer.kde.org/documentation/library/kdeqt/kde3arc(...)](http://developer.kde.org/documentation/library/kdeqt/kde3arch/mime.html) [http://en.wikipedia.org/wiki/File_format#Identifying_the_typ(...)](http://en.wikipedia.org/wiki/File_format#Identifying_the_type_of_a_file) [http://en.wikipedia.org/wiki/OSType](http://en.wikipedia.org/wiki/OSType) [http://en.wikipedia.org/wiki/Type_code](http://en.wikipedia.org/wiki/Type_code) [http://en.wikipedia.org/wiki/Uniform_Type_Identifier](http://en.wikipedia.org/wiki/Uniform_Type_Identifier)

AltStyle によって変換されたページ (->オリジナル) /