Détection de type
Un article de Wiki de la communauté Mandriva.
Sommaire |
[modifier] Ébauche de description de standard sur la détection de type de fichier
Ce document décris le stockage du format de fichier. Il a été réalisé par Raphaël Gertz <rapsys@free.fr> suite a deux popositions peu fructueuses de Mildred <mildred593(at)online.fr> : http://linuxfr.org/~mildred/24818.html http://linuxfr.org/~mildred/24648.html Ce document n'est qu'une ébauche et présente une idée.
Ceci est la révision 1 des spécifications mis en ligne le 1er Juillet 2007.
[modifier] Format de donné
A chaque fichier devra être attaché (quel que soit le support) plusieurs méta données selon le format suivant :
Content-Type: aaa/bbb
Charset: ccc
Title[ddd]: eee
Summary[ddd]: fff\rfff\rfff
Keywords[ddd]: ggg\rggg\rggg
Keywords: hhh
Author: iii jjj <kkk@lll.mmm>\riii jjj <kkk@lll.mmm>\riii jjj <kkk@lll.mmm>
[modifier] Content-Type
Cette ligne définit le type de fichier.
- Content-Type a base de mime type
Deux possibilité sont envisageables, soit fixer une liste de content-type standardisés basé sur le modèle actuel.
Il faudrais alors générer ces types de contenus a partir de la liste d'extensions déjà utilisé, par exemple une est disponible ici : http://filext.com/
Il semblerais qu'une liste de format soit déjà disponible ici : http://www.iana.org/assignments/media-types/ http://www.utoronto.ca/webdocs/HTMLdocs/Book/Book-3ed/appb/mimetype.html
Il doit être sérieusement envisagé de revoir cette base pour avoir un schéma de nommage logique et non basé sur les anciennes extensions.
- Content-Type a base d'identifiant de type uniforme apple
Une autre possibilité serait de se baser sur le schéma de nommage d'apple. http://en.wikipedia.org/wiki/Uniform_Type_Identifier
[modifier] Charset
Cette ligne définit le format de codage du fichier.
On peux considérer tous les codes de caractères de fichiers connu : utf-8 iso8859-15 iso8859-1 etc...
[modifier] Title
Cette ligne définit le titre du fichier.
Chaque titre doit obligatoirement être localisé, a savoir que l'on ne dois jamais sauver un titre unique de cette manière : Title: xyz
Chaque titre doit être accompagné d'une ligne Summary ET Keywords, eux même localisés.
Ce titre doit être constitué d'une ligne unique, encodée en utf-8, sans retour chariot ni saut de ligne !
[modifier] Summary
Cette ligne définit le résumé du fichier.
Ce champ doit être localisé et accompagné d'un champ Title et Keywords localisés.
Ce résumé doit être constitué d'une ligne unique, le séparateur de saut de ligne est le retour chariot\r (le saut de ligne pourait poser problème en cas de transmition de fichier descriptif de metadata a côté du fichier) Il doit être encodé en utf-8.
[modifier] Keywords
Cette ligne définis les mots clefs du fichier.
Ce champ doit être localisé et accompagné d'un champ Title et Summary localisé.
Ces mots clefs doivent être mis sur une ligne unique, encodé en utf-8, sans saut de ligne, le retour chariot servant de séparateur.
[modifier] Keywors non localisé
Cette ligne définis les mots clefs du fichier.
Cette ligne est destinée a un usage futur.
A savor le programme qui sauvegarde le fichier récupère automatiquement les mots clefs du document et les met sur cette ligne.
Mais cette ligne pourra également être utilisé pour stocker des mots clefs de champs sémantiques.
A savoir que certains mots clefs connus pourront avoir un champ de mots clef associé. Une recherche sur un de ces mots associé permettra d'avoir une correspondance avec le mot clef père de ce champ.
Exemple pour mer :
bleu vague flot etc
Une recherche sur flot pourra permettre si la recherche par champ sémantique est choisie de trouver les documents avec mer en mot clef.
Ce champ ne doit pas être remplis par l'auteur du document, ces mots clefs doivent être générés automatiquement selon un algorithme connu.
[modifier] Author
Cette ligne non localisée contiens le noms de tous les auteurs ayant apportés des changements au fichier.
Elle est constitué par trois champs : Un prénom Un nom <compte@domaine.tld>
Le prénom et le nom doivent être entièrement en minuscule sauf le première lette du prénom et du nom. Si des caractères accentués sont utilisés, ils doivent être encodé en utf-8 et suivre ce même modèle majuscule, minuscule pour le reste du prénom ou nom.
La liste d'auteur ne doit pas contenir plusieurs triplet prénom+nom+email identiques.
Dans les cas suivants : - Prénom, nom et email absent - Refus de l'utilisateur d'être ajouté comme auteur (Choix par défaut) Le champ auteur ne dois pas être modifié. En cas d'absence d'email, il sera remplacé par la séquence suivante : <>
Il doit y avoir une fonction dans le logiciel d'effacer ce champ et de ne pas le transmettre lors de l'envoi.
[modifier] Transfert de donnée
Cette section décrit la transmission de ces données via les différents protocoles.
- HTTP
L'intégralité de ces données doivent être envoyé selon le protocole http, a savoir ajouter au en-têtes : Content-Type: aaa/bbb; charset=ccc Title[ddd]: eee Summary[ddd]: fff Summary[ddd]: fff Summary[ddd]: fff Keywords[ddd]: ggg Keywords[ddd]: ggg Keywords[ddd]: ggg Keywords: hhh Author: iii jjj <kkk@lll.mmm> Author: iii jjj <kkk@lll.mmm> Author: iii jjj <kkk@lll.mmm>
- FTP
Cette section décrit la transmission de ces données via ftp.
TODO: section a remplir je ne connais pas assez le protocole ftp.
- NFS
Cette section décrit la transmission de ces données via nfs
TODO: Problème réglé ? NFSv4 supporte les méta-données ?
- Système de fichier
Cette section décrit la transmission de ces données via système de fichier.
Les systèmes suivant sont supporté via attribut étendu : ext3 ext4 reiserfs3 reiserfs4 XFS JFS NTFS (via ntfs3g) udf
Système de fichier a problème : smbfs fat32 (proposition de stockage via fichier fantôme ?nom_fichier.ext ou autre) iso9660
- Protocole de messagerie instantané
Cette section décrit la transmission de ces données via transfert par messagerie instantané.
Jabber : besoin de changer le protocole ? ICQ : ???TODO??? MSN : ???TODO???
- Protocole p2p
Cette section décrit la transmission de ces données via peer to peer.
Emule : ???TODO??? Bittorrent : ???TODO??? DirectConnect : ???TODO??? ???TODO???
[modifier] Commentaire de l'auteur
Je pensais déjà depuis pas mal de temps a la sauvegarde de ces types de fichier pour éviter les soucis avec l'ouverture de fichier.
Ceci est une proposition, je vais essayer de la mener en français le temps d'avoir les premiers changements majeurs, elle passera ensuite en anglais pour intégrer XDG et/ou LFS.
Un énorme avantage serait d'arriver a avoir un standard avec Google (section recherche sur les document dans l'ordinateur) et Apple (Section système de fichier et transmission de donné).
N'hésitez pas a m'envoyer des dons par paypal : rapsys@free.fr
[modifier] Objectifs
Obtenir la standardisation en tant que standard "libre" XDG a la fin de l'été. Obtenir la standardisation en tant que standard LSB pour la prochaine version. Implémentation fonctionnelle pour la fin 2008 ou printemps 2009.
[modifier] Liens
http://en.wikipedia.org/wiki/Extended_file_attributes http://www.freedesktop.org/wiki/CommonExtendedAttributes
