Suite a mon précédant journal [http://linuxfr.org/~mildred/24648.html], j'ai pensé que je devais faire quelque chose. J'ai donc imaginé un spécification qui décrit un fichier qui contiendrait à la fois des méta-données sur un fichier, et le fichier en lui même. Il est aussi possible de séparer les deux parties.
Pour rappel, les magic numbers sont une chose formidable pour détecter le type d'un fichier, mais c'est insuffisant car :
- plusieurs types de fichiers différents peuvent avoir le même magic number (archives ZIP, JAR, OpenDocument)
- les fichiers texte ne contiennent en général pas de magic number (sauf les scripts avec la fameux #!, mais c'est uneexception)
Et les extensions de fichiers, bien que très pratique dans certains cas et qu'il faut continuer à utiliser dans certains domaines comme la programmation, ne sont pas non plus une solution idéale car elles se mélangent avec le nom du fichier alors que cela n'a rien à voir.
ma solution consiste donc proposer une spécification pour un fichier desc (joli non n'est-ce pas ?). Avant de la poster par exemple sur freedesktop.org (il faudra que je voie comment) j'aimerais vous la soumettre afin que vous puissiez me dire si :
- une spécification existante ne fait pas double usage
- des choses sont a améliorer.
Je l'ai fait en anglais car c'est pour la diffuser. Cependant je n'ai pas encore relu mon anglais, il peut donc y avoir beaucoup d'erreurs, excusez-cela par avence.
La spec:
Desc file format
Created Sunday 01/07/2007
This document describe the desc file format. This file aims at describind another file, especially during transfers like attachements in e-mail or any other kind of transfert. This has been made by Mildred <mildred593(at)online.fr> who was inspired bu the application/applefile files attached by Apple Mail. Maybe another file format is standardized with the same goal, this document is only a draft and presents an idea.
This is the draft number 1 of this specification released the 1st of July 2007.
Description
The desc file includes description for a file that can be included or not. If the file is included the content type is application/descfile. If the file is not included the content type can also be text/descfile.
The frst part of the file is always presend and is textual data. It is called the headers. There must not be any single white line in the body and the first white line begins the second part, that is the included file.
The headers part
The headers host metadata about the file. It is composed of multiples physical lines separated by the character LF (\n). It finnishes when two LF characters are found or at the end of the file. So blank lines are not authorized.
Logical lines are defines. A logical line is generally the same as a physical line except when multiples physical lines are used inside a singlo logical line. A logical line is composed of a finite positive and non null number of physical lines. The first physical line included must not begin by a whitespace character (defined as the ASCII space or the ASCII tabulation \t) and the following physical lines must begin with a whitespace.
The complete header is then split into logical lines except when the first lines of the headers starts with a whitespace character. These first lines are then completely ignored.
Each logical line must be either a header or a comment. The logical line include the line feeds between the physical lines that compose it but do not include the last line feed.
A Comment
A comment is a logical line that starts wth the character '#'. It is completely ignored. Note that comments are logical lines so they can span across multiple physical lines.
A Header
A header is a line that starts with a header name and continue with a content. The header name must contains only characters from A to Z, from a to z, from 0 to 9, the character '-' and the character '.'. The header name and the content are separated by a colon ':' followed by optional whitespaces characters (space or tabulation) that are not part of the content.
The content can span across multiple physical lines. The content is defined as the binary data from the first non whitespace character after the colon following the header name until the end of te logical line.
We can also define the stripped content that is the same as the content except that the first whitespace character after any line feed is removed.
The included file part
The included file part is optional and is defines as the binary data that follow the first occurence of two LF characters.
Valid files
A desc file is valid only if it matches the description given above and if all the headers are valid and if all required headers are present.
A header is valid only if either :
• The name is described as a valid name and the content matches the description given
• The name begins with "X-" or "x-"
• The name contains dots (.)
if a header specifies that is must be present only once that means that if the headers is present more than once, the file is invalid.
Valid headers
The valid headers are described below :
Version
This header is not required. It defines the version of the file specification that must be followed. if not present, the version of the specification that should be taken is the version 1.0 or the latest draft if the version 1.0 of this specification does not exists. This header must be present only once.
Filename
This header is required only if the desc file does not hold the included file part. it contains a relative path to the filename that the desc file describes. The path is relative to the desc file location. This header must be present only once.
Content-Type
The Content-Type header is case-insensitive and holds the content-type of the file described. This header must be present only once and is not required.
Examples of desc files
Content-Type: text/plain; encoding=utf-8
This is a text file
encoded in UTF-8
Here the desc file is useful because it can specify the encoding of the text file
Example of uses
The desc file may be used to transfert metadata along with a file in a protocol when this is not usually permitted. For example we can imagine a mail client that will create a desc file for each attached file in an electronic mail. The desc file will host metadata and will reference the file with its name using the Filename header.
it can also be useful to store files and keep informations such as their content-type on filesystems that do not store this information.
We can imagine that on such systems, applications can open desc files and read the included content. So it would be possible to store files and not loose any metadata such as the content type. Thus not being forced to rely on magic numbers (note that magic numbers are not always relyable, for example with test files or ZIP files that can be also Jar archives or openDocuments).
# ...
Posté par M . Évalué à 4.
Comment sont liée les metadata et le fichier ?
Si j'utilise une opération qui ne supporte pas tes desc qu'est ce qui se passe ?
[^] # Re: ...
Posté par Mildred (site web personnel) . Évalué à 1.
Le fichier est inclus dans le fichier desc qui contient les méta-données. Il faut bien sûr qu'un maximum de logiciels comprennent ce format de fichier. Une autre alternative est de placer tout ça dans des attributs étandus du fichier (si c'est possible).
Par opération, tu veux dire quoi ?
Si un logiciel ne supporte pas ce format de fichier, alors il faudra utiliser un petit utilitaire à part qu'il reste à écrire qui permet d'extraire le contenu du fichier. Un peut comme une archive, sauf qu'il n'y a ni compression, ni possibilité de mettre plusieurs fichiers à l'intérieur.
Ou alors on patche le logiciel.
[^] # Re: ...
Posté par M . Évalué à 2.
$ mv fichier /autre_rep/fichier
$ vi fichier
[...]
bref tout ce qui est suceptible de modifier le fichier ou de le deplacer
[^] # Re: ...
Posté par Mildred (site web personnel) . Évalué à 2.
Par contre si tu fais un vi, un grep ou autre sed, ça peut poser problème. Dans ce cas c'est sûr qu'il vaut mieux utiliser les attibuts étendus. Et je pense c'est ce qu'il faut faire sur un système qui le permet.
En fait il faut voire le fichier desc comme un conteneur au même titre que tar ou gzip (mais contrairement à eux, il n'y a ni possibilité d'agrégation de plusieurs fichiers, ni compression).
L'avantage c'est que c'est du texte et que si tu l'ouvres avec Vi tu devrais quand même t'y retrouver.
# ..
Posté par M . Évalué à 3.
Filename
This header is required only if the desc file does not hold the included file part. it contains a relative path to the filename that the desc file describes. The path is relative to the desc file location. This header must be present only once.
Et tu geres comment les fichiers avec des "\n" dans le nom ?
[^] # Re: ..
Posté par Mildred (site web personnel) . Évalué à 1.
Car l'espace (tabulation en l'occurence) après chaque caractère de fin de ligne est enlevée du contenu. Je ne décrit lorsque je décris le stripped content
On peut même mettre n'importe quel contenu binaire. Mais c'est vrai que ce n'est pas très clair.
# Moué
Posté par Ph Husson (site web personnel) . Évalué à 5.
Comme dit au dessus, faudrait que les softs sachent un minimum ce que sont les .desc, sinon ca va être ingérable tout simplement, ensuite quel interêt face à l'utilisation des attributs étendus ?
Si ce n'est que c'est indépendant du FS, mais qu'en contre partie ca double le nombre de fichiers.
Par contre pour transporter ces informations faut bien quelque chose, mais plutot qu'un format original de plus, pourquoi ne pas tout simplement sérialiser ces attributs étendus ?
Alors on pourrait bien évidement imaginer une librairie qui permette de faire aussi bien ton systeme que les attributs étendus juste en ayant à mettre une option, mais bon.
[^] # Re: Moué
Posté par Mildred (site web personnel) . Évalué à 2.
D'autant plus que les attributs étandus sont je crois stokés dans l'inode, donc l'accès y est beaucoup plus rapide.
L'idée de ce format de fichier c'est justement de pouvoir sérialiser les atrtibuts étandus lors de transfert de fichiers et sur les systèmes/logiciels qui ne supportent pas les attributs étandus.
L'idée c'est aussi de mettre une emphase sur le type de fichier qui est a mon avis une information qu'il faudrait garder avec le fichier car les nombres magiques ne sont pas la solution a tout, et les extensions non plus.
Même si je n'ai spécifié que quelques headers, on peut en mettre autant qu'on veut, et donc sérialiser ainsi les attributs étandus dans le fichier desc.
[^] # Re: Moué
Posté par Ph Husson (site web personnel) . Évalué à 2.
Comment tu veux mettre ca en attributs étendus ?
Il faudrait plutot
Plutot que ce que tu fais
Bon sinon j'etais pas sur d'avoir compris ton systeme donc ce que tu dis c'est de mettre ces informations au début du fichier et non dans un fichier à part, donc à ce moment là (même si je suis pas du tout d'accord avec le systeme mais c'est une autre histoire), il vaut mieux le mettre à la fin du fichier, ca permet une pseudo compatibilité avec un certain nombre d'outils, par exemple tar ou gunzip (cad qu'ils décompressent mais avec un message d'avertissement, mais ils y arrivent), je penses que d'autres outils se comportent ainsi.
[^] # Re: Moué
Posté par Mildred (site web personnel) . Évalué à 3.
Pour ce qui est de séparer le Content-Type de l'encodage pourquoi pas ... Sauf que pratiquement partout (HTTP, MIME, ...) lorsqu'on veut spécifier l'encodage d'un fichier on le met après le Content-Type. Il me semble avoir même lu quelque part que cela en faisait partie.
Si tu veux tu peux remplacer mon exemple (pas très parlant il est vrai par :
Ca peut être une idée de mettre les headers à la fin du fichier ... Sauf que tu détectes comment la fin du fichier ? Après les derniers \n\n ? Ca veut dire parcourir tous le fichier à la recherche de toutes les séquences \n\n et prendre la dernière. Ca me semble un peu lourd. Surtotu si ton fichier est très gros.
[^] # Re: Moué
Posté par Ph Husson (site web personnel) . Évalué à 2.
Sinon mettre le charset sur la meme ligne que le type de contenu bon déjà c'est plus lourd à parser proprement (enfin amha), et le "this is a text file encoded in UTF-8" (bon déjà ca me parait débile de mettre ca), et ensuite c'etait sensé être le X-Summary
[^] # Re: Moué
Posté par Lebas Sébastien . Évalué à 2.
[^] # Re: Moué
Posté par Ph Husson (site web personnel) . Évalué à 2.
[^] # Re: Moué
Posté par Mildred (site web personnel) . Évalué à 2.
sisi, c'est exactement ça.
# je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 3.
normal
un fichier .zip est un fichier compressé au format zip
un fichier .jar est aussi un fichier compressé au format zip (il me semble)
un fichier .od? est un "meta-fichier" compressé au format zip, tu peux toutafais decompresser le fichier .od? est voir qu'il contient plusieurs fichiers.
je ne vois donc pas l'interet de tes "metadonnées"
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 3.
Un fichier zip, jar ou odt peut s'ouvrir avec n'importe quel utilitaire zip
Un fichier jar ou odt sont conformes à la spécification jar. Mais un utilitaier jar ne pourra pas forcément ouvrir un fichier zip quelconque (Jar est plus restrictif im me semble, sans doute un fichier manifest obligatoire).
Un fichier odt s'ouvre trs bien avec un utilitaire zip ou jar. par contre OpenOffice qui ouvre les odt ne peux pas ouvrir n'importe quel fichier zip ou jar, ça ne marchera pas.
Donc il faut un moyen de différencier des 3 fichiers, sinon lorsque tu va ouvrir un fichier zip tu risque de l'ouvrir avec OpenOffice qui va raler qu'il ne comprend rien, a moins que lorsque tu n'ouvres un fichier odt, tue ne l'ouvres avec un archiveur et tu ne comprendras pas pourle coup pourquoi tu ne vois pas ton document.
L'interêt des meta-données c'est de pouvoir faire cette différence facilement.
On a le même genre de problme avec les fichiers texte. les fichiers XML par exemple. Un fichier XML peut avoir un type très complexe (grâce aux namespaces XML) pas forcément facile a identifier.
J'ai eu un problème similaire avec un logiciel que je ne retrouve plus, oregano, qui permet de faire de la simulation électronique avec spice. le firchier était il me semble un fichier XML gzippé. Pas moyen d'associer dans mon navigateur de ficheir (nautilus) une action précise pour ce fichier sans toucher à tous les fichier gzippés. pas moyen d'ouvrir les fichiers oregano avec oregano mais garder mes archives tar.gz avec file-roller.
[^] # Re: je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 5.
c'est là que l'extension vient completer le magic-number
et que le mime-type permet d'associer le .od? à openoffice, là ou le .zip sera associer au gestionnaire d'archive.
sinon ton histoire de meta-données ca me fait penser au systeme de fichier NTFS
ou tu peux mettre 2Go de meta-données pour un fichier texte de 1ko
au final il te faut reecrire :
- soit un nouveau systeme de fichier
- soit tout un ensemble d'outils pour lire ces meta-données
et esperer que tes interlocuteurs utiliserons le meme systeme de fichier/les memes outils, sinon tu perd les meta-données.
c'est deja le cas en passant un fichier de NTFS -> VFAT par exemple.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 3.
Car pourquelqu'un qui ne s'y connaît pas trop en informatique, les extensions sont un moen facile de changer le type d'un fichier et de ne plus pouvoir l'ouvrir. Bref de perdre un fichier ...
La solution ? Cacher l'extension ? Une protection ?
J'utilise Apache avec une extension dont j'ai oublié le nom et qui permet selon la configuration du navigateur de proposer un fichier dans la langue que préfère l'utilisateur. Dans ce cas là, la manière la plus simple de faire c'est d'utiliser une double extension. Et j'avais donc régulièrement des fichiers avec les extensions :
.html.fr
.html.en
.xhtml.fr
.xhtml.en
Dans ce cas la, l'extension indique non seulement le type du fichiermais aussi la langue. Et dans ce cas là tu est bien embêté lorsque ton navigateur de fichier ne prend que la dernière extension en compte (.fr ou .en) alors que c'est celle d'avant qui représente le type.
Sans compter qu'on peut vouloir mettre ce qu'on veut dans le nom de fichier et que lorsqu'on ouvre son dossier ~/Documents on peut préférer voir des fichiers sans extensions (car ça prend de la place pour rien, l'icone donne déjà cette information).
C'est comme de demander de ne pas mettre d'espaces dans les noms de fichiers. Certes en ligne de commande c'est plus pratique, mais avec une interface graphique c'est bien mieux d'avoir des espaces.
[^] # Re: je n'ai pas tout lu mais...
Posté par Nicolas Schoonbroodt . Évalué à 6.
Et c'est quoi la solution contre l'effacement de tes méta-données ? Les cacher (ah ben c'est ce que tu fais...) ? Une protection ? Parce que s'il n'a plus les méta-données, tu "perds" ton fichier, tout comme pour les extensions.
Ben tu demandes à ton afficheur d'arborescence de ne pas montrer les extensions.
[^] # Re: je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 4.
[^] # Re: je n'ai pas tout lu mais...
Posté par iznogoud . Évalué à 5.
Quelqu'un qui ne s'y connait pas trop en informatique, ou quelqu'un qui s'y connait aussi d'ailleurs, peut se servir de l'extension pour savoir quel type de document c'est, sans avoir à aller choper les propriétés du document (clic, clic droit, propriétés, lecture : quatre actions au lieu d'une).
Différencier :
~/mesvacances
de :
~/mesvacances
le premier étant un film de mes vacances, le second un document qui me tient lieu de mémo.
L'extension est utile ici. Comment comptes-tu t'en débarrasser ? En mode graphique, on pourrait s'en tirer avec une lecture du desc pour afficher des icones différentes, mais en mode texte ?
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
Mais il faut aussi permettre aux gens qui n'aiment pas les extensions de pouvoir s'en passer.
De plus je te fais remarquer qu'avec les fichiers multimédia, les extensions peuvent représenter tout et n'importe quoi. par exemple un fichier.ogg peut aussi bien représenter :
- une musique OGG/Vorbis
- un son OGG/Speex
- une vidéos OGG/Theroa/Vorbis
- et d'autre combinaisons je suppose .....
Et ça m'a joué des tours lorsque j'ai mis du ogg/speex sur mon baladeur sans comprendre pourquoi ça ne marchait pas (il ne comprend que l'ogg/vorbis)
A mon avis les extensions sont très pratique dans certains domaines (programmation, makefiles, ...) mais dans d'autres contextes on devrait pouvoir s'en passer. je veux dire que cela ne devrait pas être obligatoire.
Et si tu aimes les extensions, rien ne t'empêche de les mettre.
[^] # Re: je n'ai pas tout lu mais...
Posté par Gilles G. . Évalué à 3.
En quoi le fait de virer les extensions va t'aider à résoudre ce problème?
[^] # Re: je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 2.
je dirais meme plus,
je n'ai pas ces variantes de fichiers,
mais le magic number de ces differents fichiers est-il vraiment identique ?
car s'il est different alors ton probleme n'existe plus/pas.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 1.
Avec une méta-donnée tu peux bien plus précisément identifier le type d'un fichier. Car tu n'est pas limité par l'extension qui fait généralement 3 charactères et dépasse rarement les 5 caractères.
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 1.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: je n'ai pas tout lu mais...
Posté par B16F4RV4RD1N . Évalué à 3.
bien entendu tu fais absolument ce que tu veux de tes documents.
Mais le problème c'est qu'avec ce genre de principe, si on encourage les gens à ne plus avoir d'extensions de fichiers (ce que windows fait un peu en cachant systématiquement les extensions), le jour où windows implémentera un système similaire de descriptif de fichiers, bien entendu incompatible avec le reste des systèmes non-windows, et bien cela sera encore les utilisateurs de systèmes alternatifs qui morfleront.
Déjà que l'on reçoit suffisamment dans le cadre du travail des fichiers bâtards (genre .doc, .xls ou .extension_image_exotique_et_propriétaire_du_scanner_untel ), alors si en plus on ne doit plus avoir possibilité de voir à quoi on a affaire, cela sera pire.
Apple a essayé de faire cela, se passer des extensions de fichiers, cela n'a pas réussi. Ils n'ont réussi qu'à ennuyer ceux qui n'utilisent pas Apple.
De plus, pour éviter d'effacer par erreur les extensions de fichier (en plus de l'alerte habituelle), il peut y avoir comme dans konqueror le surlignage uniquement du nom sans l'extension au moment du renommage.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: je n'ai pas tout lu mais...
Posté par Guillaume Knispel . Évalué à 2.
Le gros problème c'est qu'en passant d'un truc purement proprio à un truc basé sur Posix, il ne pouvait plus s'amuser à dire que les type de fichiers seraient gérés comme ça et JAMAIS autrement.
Ca illustre bien le poids de l'existant et à mon avis pour qu'un système standard spécifiant des méta donnés arrive à prendre, faut que ça s'intègre facilement et efficace sur un système ou ça n'a pas du tout été prévu à l'origine, et à mon avis rajouter un header au payload des fichiers ne satisfera jamais cette condition.
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 2.
(moinssez-moi :) )
[^] # Re: je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 0.
microsoft avait un projet en ce sens
tu stocke tout dans une base de donnée
comme ca tu as un champ type, extension, données
quand tu cherches un fichier tu n'as pas besoin de savoir ou il est
tu pourrais avoir plusieurs fichiers avec le meme nom mais pas le meme type (video, texte, son)
cela s'appellait WINFS et devait etre mis en place avec vista,
finalement ils ont laissé tomber un probleme de performances il me semble.
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 1.
[^] # Re: je n'ai pas tout lu mais...
Posté par Gniarf . Évalué à 2.
et zut, des extensions !
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: je n'ai pas tout lu mais...
Posté par NeoX . Évalué à 2.
ok tu peux aussi l'envoyer en fichier .odt
mais en PDF cela evite que le fichier ne soit modifier par le prof
(ok c'est etre parano)
enfin ton systeme qui veut supprimer les extensions,
pour ton rapport, tu as
- un fichier (texte, pdf decrivant ton sujet)
- une video ou un extrait sonore à diffuser pendant la presentation.
ben tu fais comment avec tes meta-données ?
tu nommes tes fichiers differemment ?
texte_mon_rapport
video_mon_rapport
ou bien
mon_rapport_extrait_video
mon_rapport_texte
?
finalement on retrouve les extensions (ou les prefixes) que tu voulais supprimer...
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
Et je m'arrête la. je crois que j'ai assez expliqué ce point.
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 2.
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 1.
/o\ tu viens de démontrer que ton idée, ton draft, ton "argumentation" sont débiles
[^] # Re: je n'ai pas tout lu mais...
Posté par z a . Évalué à 2.
[^] # Re: je n'ai pas tout lu mais...
Posté par B16F4RV4RD1N . Évalué à 2.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: je n'ai pas tout lu mais...
Posté par Gniarf . Évalué à 4.
attention attention, qui décide de ça ? c'est une base de référence qui est ensuite personnalisée par chaque utilisateur à travers la planète ? si X utilise Inkscape pour éditer un SVG et Y utilise plutôt Sodipodi, tu vas mettre autre chose que image/svg+xml dans ton fichier Desc ?
si oui, comment ils vont bosser ensemble ? si non, en quoi ça aide à savoir "avec quel logiciel on peut ouvrir un fichier donné"
après, pdf c'est application/pdf : tu voulais un application/svg ?
J'ai eu un problème similaire avec un logiciel que je ne retrouve plus, oregano, qui permet de faire de la simulation électronique avec spice. le firchier était il me semble un fichier XML gzippé. Pas moyen d'associer dans mon navigateur de ficheir (nautilus) une action précise pour ce fichier sans toucher à tous les fichier gzippés. pas moyen d'ouvrir les fichiers oregano avec oregano mais garder mes archives tar.gz avec file-roller.
ah. enfin un semblant de début d'esquisse de vrai problème interessant.
bon maintenant demande toi :
1) comment tu fais pour éditer un SVG avec plusieurs applications à part à peu près égale (et pas juste 99 % pour inkscape et 1 % de temps en temps avec sodipodi ou autre). ah, et ça, indépendemment du document lui-même : les minutes paires c'est l'un, les minutes impaires c'est l'autre.
2) pourquoi diable des gens se sont amusés à inventer et utiliser une extension de fichier "svgz" pour du contenu SVG compressé avec gzip ? au lieu de laisser .gz ou .svg.gz ?
je cite Wikipedia ici :
Compression
If storage space is an issue, SVG images (which are just text files) can be saved with gzip compression, in which case they may be called "SVGZ files". SVG files can also be compressed with any other compression algorithm, but those are not called SVGZ files.
"called". c'est une convention. par des humains. ça marche. c'est un peu comme choisir image/svg+xml au lieu de image/svg (comme pour gif, bmp...), y'a peut-être une raison, hein
pour le reste, chacun ses goûts comme tu dis. il y a des gens qui hurlent après les .DS_Store des macs, d'autres après les .cvsignore ou CVS/Entries CVS/Repository CVS/Root qui trainent encore dans trop de versions stables de softs a priori releasés proprement. ne t'étonne pas (au contraire) si on te crie après à cause de tes Desc par milliers
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 1.
Après en ce qui concerne la coopération des logiciels, c'est un autre problème. Les métadonnées ici se contentent juste de donner le tye du fichier et ne s'occupent pas du tout des applications qui vont les utiliser.
[^] # Re: je n'ai pas tout lu mais...
Posté par Victor STINNER (site web personnel) . Évalué à 2.
$ hachoir-metadata --mime Ubuntu-Examples/oo-welcome.odt
application/vnd.oasis.opendocument.text
Hachoir fait parti du projet Debian maintenant :-) http://hachoir.org/wiki/Install
[^] # Re: je n'ai pas tout lu mais...
Posté par Mildred (site web personnel) . Évalué à 2.
Ce n'est pas tout à fait le même but.
mais peut être que le résultat de hachoir-metadata peut être stoké (en cache) dans les attributs étandus...
# Nouvelles versions
Posté par Mildred (site web personnel) . Évalué à 1.
http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
la version draft 2:
http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
[^] # Re: Nouvelles versions
Posté par Gilles G. . Évalué à 1.
Il se trouve que j'arrive personnellement à identifier très facilement les types des fichiers qui se trouvent sur mon système, et cela grâce à l'extension du fichier, tout simplement.
D'ailleurs, je trouve la gestion des mime-type de KDE plutôt lourdingue, au final, c'est parfois assez difficile d'associer une extension de fichier à un logiciel. Je préfererais une gestion simple que tout utilisateur peut comprendre. Or, pour déterminer le type d'un fichier, l'extension est une information très fiable. Libmagic devrait être utilisé uniquement pour être sur que l'extension est plausible.
Exemple:
fichier en *.odt : a priori c'est un document OpenDocument. En vérifiant avec libmagic, c'est une archive zip, ce qui est cohérent puisque les fichier odt sont des archives zip.
Ce qu'il manque éventuellement, c'est une protection simple de l'extension des fichiers (comme par exemple sous Windows qui affiche un avertissement lorsqu'on change l'extension d'un fichier). Et peut-être qu'il faudrait trouver une façon de spécifier l'encodage d'un fichier texte, mais sinon, tout va bien dans la gestion des types de fichiers!
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . Évalué à 2.
Je pense que le nom de fichier doit appartenir a l'utilisateur qui dispose du fichier. Et si on met une extension (comme cela m'arrive, notament pour les fichiers sources) il faut que ce soit du choix de l'utilisateur.
je dois dire que j'ai du mal a imaginer qu'on puisse imaginer les extensions aux noms de fichier comme autre chose qu'un palliatif pour une méta-donnée inexistante.
Si ça se trouve je suis en train de rêver aux cotés des gens qui pensent sur Étoilé. mais je préfère faire quelque chose pour que ce rêve prenne forme.
Dans mon imaginaire les fichiers devraient être à la base de tout. Chaque e-mail reçu irait se loger dans un fichier qu'on pourrait directement visualiser au sein du navigateur de fichiers, chaque bookmark qu'on a vers une page web serait dans un fichier qui contiendrait aussi un cache sur la page pointée (permettant de voir ses bookmarks offline), et ainsi de suite. Et les extensions sone une gêne car elles introduisent quelque chose de technique (le type du fichier) au sein du navigateur de fichier où a mon sens on ne devrait voir que ce qui est créé par l'utilisateur. les fichiers de l'utilisateur, les noms de fichiers de l'utilisateur ...
[^] # Re: Nouvelles versions
Posté par z a . Évalué à 3.
ben si, ça différencie bien le ODT du ZIP non ?
De plus je trouve que c'est moche et je préfère dans bien des cas ne pas la mettre.
ça c'est ton avis, et comme tu le fais remarquer, c'est déjà configurable
Dans mon imaginaire les fichiers devraient être à la base de tout.
ouais genre "j'ai compris unix", mais pas la peine de compliquer inutilement avec ton truc.
Chaque e-mail reçu irait se loger dans un fichier qu'on pourrait directement visualiser au sein du navigateur de fichiers
maildir/mh ?
chaque bookmark qu'on a vers une page web serait dans un fichier qui contiendrait aussi un cache sur la page pointée (permettant de voir ses bookmarks offline)
"enregistrer la page sous" ?
tu cherches à généraliser quelque chose qui n'a pas besoin de l'être. Tu peux même le régler à ta convenance pour cacher l'extension, et ça marche toujours aussi bien.
Parce que le problème reste entier pour les fichiers qui ont perdu leur extension, sans ta donnée inscrite en dur dedans, seule libmagic pourra t'aider...
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . Évalué à 2.
Et entre .xml et .xml, tu différencie quoi ? Entre .ogg et .ogg .... et entre un .txt (iso-8859-1) et .txt (utf-8) ?
A propos des encodages des fichiers textes, j'ai souvent ce problème et en général l'autodétection est foireuse. Sauf qi j'ai un magic cookie utf-8 mais peu d'éditeurs le supportent. De plus c'est plutôt avec iso-8859-1 que j'ai des problèmes.
Pas vrament, surout qu'il y a Plan9 qui s'approche de ce concept. peut être j'aurais du mettre que je préférais travailler par documents.
En disant ça je ne pensait pas a unix mais plutôt aux conceps d'Étoilé. Car le concept tout est fichier d'unix ne se place pas a ce niveau. Que peux tu faire d'un fichier device, pipe ... dans une interface graphique ? Rien.
Oui, je l'utilise mais nautilus ne sais pas afficher mes e-mails :(
Et le lien vers la page il est où ?
Si c'est un commentaire dans la source ce n'est pas suffisant, je n'ai pas envie de voir la source de chacun de mes bookmarks a chaque fois que je les utilise
Cacher les extensions de fichiers serait la solution effectivement, solution si on s'accorde a rajouter un peu de longeur a ces extensions, et peut être uassi une normalisation des extensions. Mais il me semble que pas mal de personnes ici n'aiment pas ça (je peux me tromper) et quitte a développer un nouveau truc, je préfère personellement mes métadonnées.
Cacher les extensions cela revient en fait à rajouter une metadonnée ... sauf qu'on l'incluue dans le nom ... et on ne lui donne pas assez de place pour mettre assez d'infos dedans (comme l'encodage d'un fichier texte qui fait partie du type de fichier a mon avis)
[^] # Re: Autre proposition
Posté par pshunter . Évalué à 2.
Par contre, comme les indexeurs sont à la mode, je pense qu'on pourrait les utiliser pour analyser de façon paresseuse et de manière approfondie les différents fichiers dont dispose une personne. Par exemple, lors de l'apparition d'un fichier openoffice, le système voit que c'est une archive zip, puis essaie de l'ouvrir, et finit par voir que c'est un document de type tableur ods. Quand cette info est obtenue, on l'inscrit dans les métadonnées du fichier gérées par l'indexeur (ou les attibuts étendus) pour ne pas avoir à ré-analyser plusieurs fois.
Sur les systèmes lents, on pourrait commencer par afficher une icône représentant un type de fichier inconnu, et par-dessus un symbole qui indique que l'analyse est en cours. Au fur et à mesure que l'info sur le fichier s'affine, l'icône change et une fois que l'analyse est terminée l'indicateur d'attente disparaît. Si la personne est pressée et qu'elle veut ouvrir le fichier, mais que l'analyse n'est pas terminée, on peut présenter un boîte qui indique où on en est de l'analyse (par exemple, jusqu'à présent c'est une archive zip et vous pouvez l'ouvrir, mais si ça se trouve c'est autre chose, si vous n'êtes pas sûr veuillez patienter)
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . Évalué à 4.
Pour moi ces spécifications (comme tu veux le faire avec un conteneur) ne sont pas utilisable.
(ça va demander trop de changements majeurs)
Pour moi, au lieu de créer des fichier encapsulant tout je pense qu'il faut différencier 3-4 cas.
1 - Sur le système de fichier :
On dois spécifier le Content-Type, le Charset, le Title et le Summary.
A savoir chaque fichier créé a partir d'un programme compatible (ou sauvegardé avec a partir d'un existant) doit embarquer ces spécification.
Cela prendrais la forme :
Content-Type: text/plain
Charset: utf-8
Title[fr]: Résumé de ma todo list
Summary[fr]: Ce que je dois finir sur mon projet.\rRaphaël réveille toi si tu lis ça !\rTu as du boulot.
Ensuite on peux utilise le Content-Type pour savoir avec quoi l'ouvrir.
On peu imaginer une liste de Content-Type officielle, genre :
text/plain
text/html
application/xhtml+xml
application/xml
source/php
source/ruby
source/python
binary/elf32-little-endian
binary/elf64-little-endian
binary/win32
image/png
image/gif
image/jpg
video/mkv
video/avi
video/ogm <= pas de ogg !!!
audio/mkv
audio/mp3
audio/mp4
audio/vorbis
audio/flac
etc...
Le charset pour plus avoir de faire des opérations "magique"
Quand au titre avec la langue entre crochet permettra, faut voir si on met pas les codes du type fr_FR, puis autoriser pour une personne en fr_BE le fallback en fr_FR (et vide versa).
Ensuite cette langue dans la titre et le résumé permet de détecter si un document est mono langue ou multi-langue.
2 - le mail
Je ne sais pas exactement comment ça marche exactement dans ce cas là, mais on dois pouvoir passer comme en-tête de fichier attaché ces quelques champs.
3 - le http, ben là c'est facile, on a le Content-Type servi direct par le serveur http, on peux imaginer d'envoyer le reste automatiquement.
(en plus ça pourra peut-être être plus rapide de taper dans les matadata du fichier que de faire de la détection sur extension)
4 - en ftp, bon là je pense qu'il faudra peut-être une commande de plus.
5 - protocoles de messageries instantané
Bon il faudra mettre a jour le protocole jabber sur le transfert de fichier a ce sujet.
Pour les autres, il faudra calculer les metadata a la réception du fichier (en tout cas pour les Content-Type et Charset et mettre les champ Title: et Summary: vide)
6 - autre moyen de transfert de fichier.
Bon là j'ai pas d'idée d'autre moyen de transfert de fichier.
Après je pense qu'il es pas utile de conserver une date de création de fichier dans les metadata car le système de fichier le fait déjà non ?
Si ma conception te plais hésite pas a faire un draft ;)
Plus sérieusement je pense que ma manière de faire permettra une transition en douceur, a savoir les vieux clients y verront rien du tout, par contre les clients compatible ça marchera direct.
Ensuite il restera plus qu'a convaincre M$ et Apple de suivre ces spécifications inter-opérables de s'échanger des fichiers sans perdre les informations supplémentaires.
Quand a ce qui est des extensions de fichier, ça on s'en foutra du coup un peu, ce sera conservé quelque temps pour éviter les ambiguités.
Ensuite on peux imaginer ça devenir un point de validation de LSB, ça permetrais d'avoir ça fonctionnel a l'horizon 2009.
Pour rappel toutes les applications sauvegardant des fichiers devront être patchés ça représente un travail énorme !
(sans parler de toutes les applications web et réception de contenu web en provenance de couillon qui le respecteront pas et enverront toujours les vieux content type pourrit genre application/octet-stream)
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . Évalué à 2.
[^] # Re: Nouvelles versions
Posté par Mildred (site web personnel) . Évalué à 2.
Pour ce qui est du Summary, je ne sais pas si c'est intéressant, car c'est quelque chose qui doit être rempli par l'utilisateur et qu'il ne remplira jamais si il n'a pas la discipline de le faire. En tout cas ce ne dois pas être obligatoire. mais c'est vrai que ca peut être pratique.
les crochets ca peut être pratique pour la langue mais en général quelqu'un ne va pas s'amuser a renseigner un document qu'il crée dans toutes les langues du monde. mais il faut que ce soit permis, c'est vrai.
Pour ce qui est du transfert des méta-données, c'est je pense intéressant de faire soit un conteneur comme je le décris ou d'associer un fichier avec les méta-données. Du moins tant que les protocoles ne permettent pas de spécifier tous les attriuts qu'on veut. Apple le fait déjà avec les données spotlight (je crois, pas testé) qu'il envoie avec chaque fichier attaché dans un email. Un fichier de type application/applefile. Bien sûr je ne sais pas si c'est standardisé. Mon idée c'est de faire quelque chose de similaire standard.
Mais c'est vrai que si tous les protocoles permettent de faire passer les meta-données, ce n'est plus utile du tout.
Pour ce qui est du type de contenu, je ne crois pas qu'il faille garder le content-type actuel qui est assez peu standardisé. Apple propose une alternative basée sur une notation reverse DNS qui permet a n'importe qui de créer des nouveaux types. [http://en.wikipedia.org/wiki/Uniform_Type_Identifier]
Pour ce qui est de la date, je pense que c'est intéressant de la garder. Car il y a trop de cas où elle est perdue. par exemple lorsqu'on compresse/décompresse un fichier, lorsqu'on le copie, ... la date est réinitialisée. Et du coup pas moyen de savoir quand on a bien pu écrire un fichier texte qui traine depuis toujours dans notre homedir.
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Moi je veux quelque chose qui marche, en fait je pensais proposer ça dans la cooker ml de mandriva pour voir arriver ce genre de chose dans LSB plus tard.
C'est justement pour ça que ça doit être obligatoire !
A savoir que l'utilisateur peut le laisser vide, mais en théorie ça doit être obligatoire.
Pensons au futur, quand nous aurons des ordinateurs capable de comprendre notre langage humain (ou du moins un super algorithme), on peux imaginer laisser a notre algorithme le sois de remplir ce champ pour nous.
On peux même imaginer un champ Keywords: obligatoire aussi pour accélérer la recherche de fichier.
A savoir on ajoute dans ce champ les noms de champs sémantiques détectés dans les documents en question.
L'user peux bien sur en ajouter en plus pour sa langue.
Ainsi on a :
Keywords: <keyword auto>\r<keyword auto>\r<keyword auto>
Keywords[fr]:
Selon cette forme, une recherche sur les fichier, va taper dans l'ordre suivant :
1 - Title en priorité
2 - Description
3 - Keywords user
4 - Keywords auto
5 - Champ sémantique des keyword user
6 - Champ sémantique des keyword auto
Ce qui permettra d'avoir une table de champ sémantique par langue et de tomber via une recherche sur "mer" sur des résultats contenant "bleu", "vague", etc...
Bon bien sur les portions 5 et 6 seront des améliorations futures.
C'est justement de la connerie !
Les dates doivent être toujours transférées, si ça ne marche pas c'est que ton apache/IIS/webappliquette fait pas sont boulot en te les envoyant pas !
Ou que ton compresseur (tar) ne fait pas correctement son boulot (comme star par exemple).
Pour ce qui est du support du standard, ce sera vite fait, il suffit de mettre google dans le lot, de s'assurer que son moteur de recherche de donnée sur disque dur utilise ce standard et paf m$ et apple auront qu'a suivre la marche !
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . Évalué à 2.
http://wiki.mandriva.com/fr/Détection_de_type
N'hésitez pas a discuter chaque point.
[^] # Re: Nouvelles versions
Posté par Raphaël G. (site web personnel) . Évalué à 4.
http://wiki.mandriva.com/fr/D%C3%A9tection_de_type
# humour
Posté par z a . Évalué à 2.
# Soutien
Posté par moramarth . Évalué à 4.
Sans connaissance techniques particulières, j'ai fait une tentative pour proposer l'idée, mais d'un point de vue utilisateur que je suis malheureusement. En fait, je ne voulais pas trop retoquer à une porte de ces obscures arcanes du logiciels libres, mais suite à une promesse stupide et des plussages qui le sont autant, j'ai du m'exécuter. Inutile de préciser le désastre. J'ai galéré pendant deux semaines pour un flottement dans la fréquence de postage dans la mailing-list.
https://linuxfr.org/~mildred/24648.html#840225
http://lists.freedesktop.org/archives/xdg/2007-June/008504.h(...)
Je te souhaite néanmoins sincèrement d'avoir ou de trouver les clefs pour bouger le bouzin. Même les geeks les plus renfrognés qui regrettent presque l'existence de l'interface graphique (si j'ai vu ça une fois, promis) seront très contents que les systèmes libres prennent des parts de marché, de l'importance et rende leurs matos, leurs formats (je pense particulièrement aux oggs) etc. compatibles en standard.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Soutien
Posté par Mildred (site web personnel) . Évalué à 2.
Je pense comem toi que les attributs étendus doivent être utilisés. Ma spécification était plus dans le sens de faire bouger les choses mais il faut peut être la travailler plus effectivement.
D'ailleurs dans le draft n°2 j'en parle.
Le problème c'est que faire un spec pour dire qu'on doit utiliser tel attribut avec tel nom avec comme contenu un type MIME ou UTI, ca fait un peu brut je trouve. Et avec mon fichier spec je propose un moyen de concerver la compatibilité.
Mais c'est vrai que j'imagine mal ma spec devenir définitive, pourmoi c'est plus une base de discussion. D'ailleurs à l'intérieur je parle du Content-Type mais je préfèrerais mettre un UTI car les types MIME sont utilisés un peu à tort et à travers sans concertation. UTI permet lui à tout le monde de créer un nouvel identifiant de type sans se soucier d'éventuelles collisions.
UTI: http://en.wikipedia.org/wiki/Uniform_Type_Identifier
draft n°2: http://mildred817.free.fr/Misc/Computer/Ideas/Spec/Desc_file(...)
[^] # Re: Soutien
Posté par B16F4RV4RD1N . Évalué à 3.
tu parles d'un exemple : chez microsfot vive les virus qui se propagent en partie à causes des extensions cachées (britney.jpg.exe), et chez apple vive les fichiers sans extensions qui viennent intriguer les destinataires de courriel non apple qui reçoivent de tels fichiers. Les fichiers sans extensions sur les vieux système apple, dans leur circuit fermé de fanboy ou de graphistes de pub, pourquoi pas en 1985 alors qu'internet n'avait pas le même poids que maintenant, mais de nos jours ce n'est plus trop tenable.
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Soutien
Posté par Mildred (site web personnel) . Évalué à 2.
Après si tu n'as pas libmagic ou que tu as un mauvais mailer, c'est ton problème.
[^] # Re: Soutien
Posté par NeoX . Évalué à 1.
parce que mon fichier (en suivant ta norme) qui se nommera
toto
avec les entetes qui vont bien.
sur mon systeme linux, ca va le faire grave...
mais si je l'envoie à un pote sous macOS ou windows ?
ensuite avant de pondre une nouvelle norme,
il faut peut-etre se pencher sur la faisabilité de la chose,
faire une maquette,
et si la maquette fonctionne alors tu poses ta norme.
le format ODF par exmeple existe depuis un bon moment et n'a était considéré comme norme qu'à partir du moment ou cela a bien fonctionné.
---
je te soutiens dans le principe de vouloir ameliorer les choses, mais typiquement tu vas surement devoir te demander pourquoi il existe autant de systeme de fichiers extX, Xfs, Hfs, ReiserFs, Ntfs, Fat = > pour les disques durs
Iso9660, Joliet, RockRidge, Udf => pour les CD/DVD
BlueRay, HD-Dvd => pour les DVD HD
chacun veut apporter quelque chose de nouveau, il definit son cahier des charges
de là à ce que ce soit adopté par une majorité, il faut du temps.
---
j'arrete de chercher la petite bete sur le fait de savoir si c'est bien ou pas, le futur nous le dira.
# Une meilleure idée (à mon avis) : sérialiser
Posté par alexissoft . Évalué à 3.
L'avantage : Pas de modifs d'applies, et que c'est très simple à implémenter (deux outils en ligne de commande de plus, juste à avoir des wrappers KDE/Gnome).
[^] # Re: Une meilleure idée (à mon avis) : sérialiser
Posté par z a . Évalué à 1.
[^] # Re: Une meilleure idée (à mon avis) : sérialiser
Posté par dinomasque . Évalué à 3.
BeOS le faisait il y a 20 ans !
# NIH
Posté par Guillaume Knispel . Évalué à 2.
Malheureusement c'est vrai que les solutions existantes pour les méta données sont pas vraiment 100% compatible les unes avec les autres, mais pour faire un truc efficace et susceptible de prendre il faut commencer par étudier ce qui existe déjà et être sur que ça peut s'intégrer efficacement et simplement avec tous les systèmes, surtout quand ils sont pas prévu pour à l'origine.
En outre ton format limite l'évolutivité sans raison apparente (il faudrait au minimum prévoir la possibilité d'ajouter des headers valide d'interprétation non obligatoire dans le format que les anciennes implémentations seraient susceptible d'ignorer) et de plus le seul header spécifié vraiment important est Content-Type ce qui un peu léger à l'époque où les environnement dominant ont tous des solutions d'indexation de méta données... d'ailleurs au dela de la description du format de fichier il faudra une spécification plus importante de l'intégration à l'existant et des recommendations pour la mise en application sur de nouveaux systèmes.
Enfin, les fichiers de descriptions "inclus" me semblent peu intéressants tels que décrits ici dans la mesure ou leur content type masque celui du payload et qu'ils sont donc incompatible avec l'existant. L'idéal serait de les stocker dans un fork sur les systèmes qui supportent, sauf que de tels système mémorisent généralement déjà le content-type ou équivalent comme des grands, donc ca limite l'interet.
Enfin ton format ressemble à celui de la RFC 2822 tout en étant incompatible ce qui est plutôt génant. Il serait préférable de tout simplement référencer la RFC 2822 histoire de ne pas réinventer la roue ni obliger de réimplementer avec du nouveau code des parser et générateurs justes un poil pas pareil.
[^] # Re: NIH
Posté par Mildred (site web personnel) . Évalué à 2.
Pour ce qui est de l'évolutivité, je n'avais pas l'impression de la limiter, mais c'est vrai que c'est peut être le cas. Il faut bien comprendre que ce n'est qu'un draft que j'ai écrit hier dans la nuit car je voulais noter l'idée avant de dormir :). L'idée c'est que les headers du style X-Quelquechose ou com.example.quelquechose sont disponnible à tout le monde, les autres doivent être présents dans la norme. mais il n'est absolument pas interdit de rajouter des headers dans la norme.
En fait il faudrait peut être faire ça avec la version. Si la version du fichier est supérieure à la version du parseur, alors les headers inconnus sont ignorés et le fichier est valide.
Pour ce qui est de la RFC 2822, je me doutais bien que ce que je faisais devait déjà être plus ou moins normalisé. Cependant (je n'ai pas encore regardé la RFC) mon système permet de mettre n'importe quelle donnée *binaire* comme valeur des headers. C'est pour cela que je n'ai pas cherché la RFC... Mais c'est vrai qu'on peut toujours utiliser base64 ou autre codage si on veut.
[^] # Re: NIH
Posté par Bertrand Mathieu . Évalué à 2.
Après je vois souvent sur les partages de fichiers que ceux déposés par les utilisateurs de mac sont souvent accompagnés d'un '.DStore' (ou quelque chose comme ça, et qui contient le nom du fichier). J'imagine que cela permet à un autre utilisateur de mac de récupérer aussi les métadonnées du fichier, sans jamais toucher le contenu du fichier lui-même (donc "compatible" pour les autres OS).
[^] # Re: NIH
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: NIH
Posté par Guillaume Knispel . Évalué à 2.
Header1: blabla
Header2: foobar
sur internet et ailleurs.
La RFC 2822 en elle même décrit le format des e-mails, mais elle (ou la 822) est référencé par l'HTTP, le SIP, etc... justement en ce qui concerne le format des headers. Et pour les trucs binaires on fait effectivement du base64. cf RFC 2047 et 2045
Étant donné que tu fais un truc en rapport à mon avis tu gagnerais à te taper toute la lecture des RFC 2045 à 2049 de toute manière, qui décrit MIME.
# Ca marchera jamais
Posté par Uriel Corfa . Évalué à 3.
T'as pas prevu d'en-tete pour mettre des DRM. :)
# Adobe XMP
Posté par lint . Évalué à 2.
http://www.adobe.com/products/xmp/
"Adobe's Extensible Metadata Platform (XMP) is a labeling technology that allows you to embed data about a file, known as metadata, into the file itself. With XMP, desktop applications and back-end publishing systems gain a common method for capturing, sharing, and leveraging this valuable metadata — opening the door for more efficient job processing, workflow automation, and rights management, among many other possibilities. With XMP, Adobe has taken the “heavy lifting” out of metadata integration, offering content creators an easy way to embed meaningful information about their projects and providing industry partners with standards-based building blocks to develop optimized workflow solutions."
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.