Apple repense la signature des fichiers
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.
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.
sekhmet |
Anonyme (non vérifié) |
eTeks |
Nicolas_D |
Lemmings |
Arnaud de la Grandière |
jerome74 |
Macleone |
Almux |
L-J |
dodobis |
UnAm |
françois bayrou |
kubernan |
NekoSan64 |
Yip |
geneosis |
CocoaPower |
jpp22 |
thierry61 |
DrFatalis |
DG33 |
Didier Guillion |
gl3am |
Ziflame |
VieillePomme |
marc_os |
Psylo |
magic.ludovic |
peyret |
vintz72 |
