Fermer le menu

Apple repense la signature des fichiers

Nonoche | | 17:20 |  38

Lorsque le Macintosh est arrivé en 1984, si son interface graphique était l'élément le plus évident du caractère révolutionnaire de la machine d'Apple, c'était loin d'être le seul. La façon dont le Mac gérait ses fichiers était également un modèle du genre. Sur MS-DOS, les fichiers ne pouvaient avoir un nom que de 8 caractères (contre 31 pour le Mac), suivis d'une "extension" de 3 caractères qui déterminait le type de fichier (par exemple "fichier.doc"), ce qui est plutôt abscons.

Sur Mac en revanche, les fichiers n'avaient pas d'extension : en lieu et place, ils intégraient une signature, qui précisait à la fois le format de fichier, et l'application qui l'avait créé (sur 4 caractères chacun). Non seulement chaque format de fichier a droit à sa propre icône permettant de l'identifier, mais celle-ci varie également en fonction du logiciel qui l'a créé (Apple fournissant des guides pour que le tout soit clair et cohérent).

Ainsi, Photoshop avait pour type APPL (précisant qu'il s'agit d'une application), et pour créateur 8BIM. Un fichier au format Photoshop avait pour type 8BPS et pour créateur 8BIM. De cette manière, le Finder détermine automatiquement quelle icône attribuer au fichier, mais également avec quel logiciel l'ouvrir lorsque l'utilisateur double-clique dessus. À l'inverse de ce qui se fait chez Microsoft, chaque fichier peut s'ouvrir directement avec le logiciel qui l'a créé, quel que soit leur format. Sur Windows, en revanche, un seul logiciel s'ouvre par défaut pour tout type donné de fichier.


L'édition de la signature dans ResEdit

Sur les autres systèmes, les fichiers sont un simple empilement de données, au format binaire ou ASCII. Sur Mac en revanche, les fichiers possèdent une data fork pour les données en elles-mêmes, et une resource fork qui contient diverses informations sur le fichier ou des données formatées spécifiquement (palettes de couleurs, éléments d'interface, etc). De même, les logiciels disposaient d'une ressource BNDL qui listait tous les types de fichiers gérés par l'application (et donc tous les formats). Ainsi, le Finder pouvait déterminer s'il pouvait autoriser le glisser-déposer d'un fichier sur une application qui ne l'avait pas créé. La resource fork était une des spécificités du filesystem du Mac, HFS. De même, c'est dans les attributs HFS que la signature type/créateur des fichiers était stockée.

Tout allait pour le mieux dans le meilleur des mondes possibles, et nombre d'utilisateurs du Mac ne tarissaient pas d'éloges sur le confort qu'un tel système permettait, jusqu'au jour où les ordinateurs ont cessé de vivre en autarcie : les PC ont fini par abandonner les disquettes 5,25" pour préférer le format 3,5" utilisé par le Mac, et les réseaux hétérogènes ont commencé à apparaître. Et là, horreur, les fichiers créés sur Mac devenaient illisibles une fois qu'ils voyageaient sur des partitions de formats autres que HFS. Les fichiers Mac, sans extension dans leur nom, devenaient impossibles à lire sur PC à moins d'ajouter l'extension idoine à la main. Une fois revenus sur un Mac, ils avaient perdu leur signature type/createur, et le Finder n'arrivait plus à savoir avec quel logiciel les ouvrir. Apple a bien proposé un tableau de bord, nommé Echange PC/Mac, qui se chargeait, outre du support des disquettes MS-DOS, de convertir le typage des données entre Mac & PC (à l'aide d'une base de données d'extensions et leurs correspondances en type/créateur). Hélas, ça ne réglait pas le problème des applications, qui devenaient définitivement inutilisables dès lors qu'elles étaient stockées sur un disque non-HFS, à moins de les compresser et de les encoder. Et l'arrivée progressive d'Internet n'a rien fait pour simplifier les choses (ceux qui se rappellent des .sit.hqx en savent quelque chose). Ce qui était d'une simplicité exemplaire tant qu'on restait entre Macs devenait un vrai casse-tête dès qu'on utilise d'autres formats de stockage. Il n'est d'ailleurs pas impossible que ce problème ait été une des raisons qui ont fait reporter le support de ZFS dans Mac OS X, pourtant promis de longue date.

Bref, la particularité du Mac, si elle était une force en autarcie, est devenue une faiblesse dans un monde connecté. L'arrivée de Mac OS X a offert une porte de sortie : à la trappe la resource fork, toutes les ressources sont converties au format data : les applications deviennent des dossiers (dont on peut toujours afficher le contenu en sélectionnant "afficher le contenu du paquet" dans le Finder) qui contiennent différents types de fichiers pour remplacer feue la resource fork, et les extension à la manière de MS-DOS, Windows, Linux et Unix font leur apparition sur Mac (bien qu'il soit possible de les masquer pudiquement). Les fichiers, quant à eux, voient leurs ressources stockées dans des dossiers invisibles. Mais la signature type/créateur survit vaille que vaille… jusqu'à l'arrivée de Snow Leopard (voir notre article Quand Apple complique l'ouverture des fichiers).

Catastrophe! Apple aurait passé à la trappe cette merveilleuse trouvaille ? A y regarder de plus près, pas tout à fait, comme le souligne AppleInsider. On l'a vu, la signature type/créateur pose quelques problèmes en environnement hétérogène, mais il y en a d'autres. Ainsi, la limite de quatre caractères arrive très vite à saturation, et il devient difficile de trouver des combinaisons disponibles pour de nouveaux types de fichiers. D'autre part, le typage des données est utilisé à bien d'autres endroits : le presse-papiers (qui contient différentes versions des mêmes données pour en permettre l'utilisation partout, ainsi, une page HTML devra rester lisible selon qu'elle sera collée dans un document de texte, enrichi ou non), coup d'œil, les services (qui sont en quelque sorte un copier-coller paramétrique), ou encore le glisser-déposer entre applications. Pour tous ces éléments du système qui font appel au typage des données, et pour répondre aux problématiques induites par la signature type/createur, Apple a apporté avec Snow Leopard une réponse fiable, durable, homogène, tout en conservant la compatibilité avec le passé.

Ce nouveau système, nommé UTI (pour Uniform Type Identifiers), a été introduit dans Tiger : Snow Leopard ne fait qu'entériner la bascule en abandonnant la signature type/créateur. Il emprunte au MIME type du web et du mail, en poussant le principe bien au-delà. Ainsi, lorsqu'on avait autrefois une signature 8BIM/8BPS pour un fichier créé par Photoshop, on aura dorénavant une signature sous la forme de com.adobe.photoshop-image. Celle-ci fait également partie d'un arbre de famille, puisqu'elle se raccorde à d'autres signatures, de type public. Ainsi, des données ayant pour signature "public.html" se conforment également à l'UTI "public.text". De cette manière, toute application capable de gérer du texte devient de facto capable de gérer le format HTML. En outre, les UTI permettent d'attribuer automatiquement l'ancienne signature Mac "HTML", mais également toutes les extensions de nom connues du html (.html, .htm, .shtml, .shtm), et même le type MIME "text/html".

De cette manière, les UTI deviennent le standard universel du typage de données, et répondent à toutes les problématiques induites par les différents systèmes. En outre, le procédé est dorénavant homogène dans tout le système, avec un seul gabarit de typage qui répond à toutes les utilisations. En outre, plus de limites sur le nom, et il n'y a plus besoin non plus d'enregistrer un nouveau type dans un registre public comme c'était autrefois le cas : le simple raccordement aux UTI publics permet à toute application d'exploiter simplement les données sans avoir même jamais croisé le format de fichier précédemment.

Voilà une nouveauté de taille, bien que comme nombre d'améliorations incluses dans Snow Leopard, elle ne saute pas aux yeux au premier abord. Mais il s'agit clairement d'un gestionnaire tourné vers l'avenir et les autres plateformes.

Catégorie : 
Tags : 

38 Commentaires

avatar geneosis 24/09/2009 - 22:54

des articles comme ça on en redemande.

Sérieux, j'en redemande.

avatar CocoaPower 24/09/2009 - 23:17

Je trouve aussi que l'article est trompeur. L'UTI existe depuis longtemps. Au final, Apple a plutôt retiré une fonctionnalité en retirant les créateurs.

avatar jpp22 24/09/2009 - 23:49

Erreur, L-J, les UTI utilisés correctement remplacent les types *et* les créateurs, et de manière plus flexible. A ce sujet, lisez l'excellent article très complet de Dan Dilger, auteur de «Snow Leopard Server (Developer Reference)»: http://www.roughlydrafted.com/2009/09/22/inside-snow-leopards-uti-apple-fixes-the-creator-code/

avatar Thierry61 25/09/2009 - 00:21

ha Resedit... on s'amusait bien

avatar DrFatalis 25/09/2009 - 02:14

Enfin des vieux C... dans mon genre qui ont connu resedit.
"les extension à la manière de MS-DOS, Windows, Linux et Unix font leur apparition sur Mac "
Encore une allégeance à l'archaïsme windozien. Se connecter oui, s'identifier jusqu'à y perdre son âme, non.
Heureusement que l'on peut masquer ces lamentables "extensions" que seul un système mal formé (win...) a pu rendre indispensable et implanter dans l'esprit des utilisateurs comme étant indispensable...

(et, enfin, comment dire... Ce article est vraiment super mais... "les extension ", il ne manque pas une extension, justement, vers le fin ?)

avatar DG33 25/09/2009 - 03:47

ResEdit : un générateur de bombes pour les plus fous d'entre nous.
Mais quel plaisir d'aller y rechercher un string !
Dites, MacGé, ça ne vous tenterait pas de nous sortir une série d'articles pour nous, les quadras (hé hé) et quintas (ah, raté) avec des bons vieux Souvenirs (Pomme Pomme oh je tiens la forme, moi) à l'Apple (la pelle) ?

avatar Didier Guillion 25/09/2009 - 08:52

Le concept d'UTI existe depuis des années, la doc apple a été mise en jour en 2008 et existait bien avant.

Cordialement

avatar gl3am 25/09/2009 - 09:06

Super article.... J'avais déjà oublieé le super look des fenêtres MAC, presque pas pris une ride !

avatar Anonyme (non vérifié) 25/09/2009 - 10:09

les graphistes, qui jonglent en permanence avec les deux types d'eps (illustrator et Photoshop) l'ont bien dans le c…

avatar Ziflame 25/09/2009 - 11:40

C'est vraiment gonflant de lire des commentaire comme "lamentables extentsions"...

Encore bien qu'elles existent quand vous telechargers des fichiers hein... faut arreter d'etre trop con des fois...

avatar Ziflame 25/09/2009 - 11:45

Ou quand en compresse... ou quand on passe d'un FS a l'autre... Enfin en gros, quand on ne vit pas dans son petit nuage, seul au monde.

avatar Anonyme (non vérifié) 25/09/2009 - 12:55

@Ziflame : c'est peut-être indispensable aujourd'hui, mais est-ce que ça veut dire qu'une solution plus moderne ne puisse pas exister ? Parce que dans l'absolu, oui, les extensions, c'est moche !
L'idéal pour un nom de fichier, c'est un texte en langue naturelle (avec les accents bien sûr !).

avatar VieillePomme 25/09/2009 - 13:52

Purée, les gars, les resources fork à l'ancienne n'ont pas du tout disparu... elles fonctionnent même encore très bien sous 10.6 !... de nombreux fichiers systèmes , quicktime, les .psd, en sont bourrés, retro-compatibilité oblige...

avatar marc_os 25/09/2009 - 14:42

Au sujet des resources fork, il me semble même que le prnicipe avait été généralisé par Apple et que HFS+ n'était plus limité à "seulement" deux types de "forks" pour les données (data) et les ressources, mais permettait d'en gérer bien plus.
Mais vu que seul le format HFS gère ça, et quand on voit toutes ces clefs USB vendues en FAT ou FAT32, Apple devait trouver une solution de rechange.

Quant au nombre de valeurs possibles pour ces quatre petits caractères pour le type et le créateur, le maximum théorique n'est pas 20 millions mais de 2 puissance 32, soit 4 294 967 296. Car ces quatre caractères (ascii) sont une représentation d'un entier long sur 32 bits (un caractère ascii est stocké sur un octet, et 4 x 8 = 32). ResEdit aurait pu aussi afficher la valeur hexadécimale plutôt que la représentation ascii.

avatar Psylo 25/09/2009 - 16:35

@DG33 [i]Dites, MacGé, ça ne vous tenterait pas de nous sortir une série d'articles pour nous...... avec des bons vieux Souvenirs ?[/i]
Excellente idée ! (excellent article)
revoir l'interface de ReSedit ça fait quelquechose :') nostalgiiiiie !

avatar MagicLudovic 30/09/2009 - 21:15

Superbe article ! Ah resedit ... Que de souvenirs !

avatar peyret 05/10/2009 - 22:51

D'abord, vient d'où cette copie d'écran ! de Resedit... Y a un mac+ qui tourne chez mac-gé ?

avatar vintz72 28/10/2009 - 09:25

> Lemmings

+1000000 pour les datatypes de l'Amiga. Je ne connaissais pas, c'est super simple comme idée, mais c'est génial ! (comme toutes les meilleurs idées, ce sont les plus simples, mais "il fallait y penser"). Etonnant que personne n'ait repris l'idée en effet... Allo ? M. Jobs ?

avatar Yip 24/09/2009 - 22:43

ahhhhh, Resedit............ soupir !

avatar NekoSan64 24/09/2009 - 22:12

@Lemmings

Je plussoie des deux mains et des deux pieds en ce qui concerne l'Amiga. Le système code/créateur des fichiers était un modèle du genre ! Le Mac sous Système 6 était techniquement un poil plus compliqué mais tout aussi efficace.

Quand on pense à Windows... ça fait vraiment rire (ou pleurer quand on a pas le choix)...
Mais on dirait qu'avec SL on y fonce tout droit... Déjà qu'avec Tiger ou Leopard ce n'était déjà pas forcément évident tous les jours (j'ai le problème des ".as" sur Léo, les SWF refusent d'être assignés globalement à une version du player Flash, c'est le dernier player ou autoexecutable lancé qui l'emporte ensuite)...

avatar Nonoche 24/09/2009 - 21:29

@Jerome74 : bien vu, c'est corrigé

avatar kubernan 24/09/2009 - 21:07

Faut préciser que l'usage de l'UTI est apparu dans OS X bien avant Snow Leopard. On pourrait comprendre à tord que l'UTI a été inventé avec Snow Leopard.

avatar françois bayrou 24/09/2009 - 19:56

... et les fichiers .AS ( flash actionscript ) sont bien reconnus comme des fichiers actionscripts ( un double click dessus ouvre Flash ) mais quicklook refuse d'en afficher le contenu, même avec des plugins additionnels.
La faute à l'extension as, qui est aussi reconnue comme "apple single archive".
bref sous SL Il m'a donc fallu gruger en rajoutant les fichiers apple single archive comme lisible ( plaintext ) et les associer à l'excellent plugin QLColorCode alors que sous Leopard ca fonctionnait très bien : je ne comprends plus rien.
Vu dans le package d'un plugin quicklook, ils associent bel et bien un UTI à ... une extension :((((
D'ou le souci avec des extensions similaires pour des fichiers différents

avatar UnAm 24/09/2009 - 19:45

Purée... ResEdit... :/
*nostalgique*

avatar dodobis 24/09/2009 - 19:43

j'ai un coup de nostalgie, là ....

Pages

Connexion utilisateur