Extension de nom de fichier - Filename extension

Une extension de nom de fichier , une extension de fichier ou un type de fichier est un identifiant spécifié comme suffixe du nom d'un fichier informatique . L'extension indique une caractéristique du contenu du fichier ou son utilisation prévue. Une extension de nom de fichier est généralement délimitée du nom de fichier par un point (point), mais dans certains systèmes, elle est séparée par des espaces.

Certains systèmes de fichiers implémentent les extensions de nom de fichier en tant que caractéristique du système de fichiers lui-même et peuvent limiter la longueur et le format de l'extension, tandis que d'autres traitent les extensions de nom de fichier comme faisant partie du nom de fichier sans distinction particulière.

Usage

Les extensions de nom de fichier peuvent être considérées comme un type de métadonnées . Ils sont couramment utilisés pour impliquer des informations sur la manière dont les données peuvent être stockées dans le fichier. La définition exacte, donnant les critères pour décider quelle partie du nom de fichier est son extension, appartient aux règles du système de fichiers spécifique utilisé ; généralement, l'extension est la sous-chaîne qui suit la dernière occurrence, le cas échéant, du caractère point ( exemple : txt est l'extension du nom de fichier readme.txtet htmll'extension de mysite.index.html). Sur les systèmes de fichiers de certains systèmes mainframe tels que CMS dans VM , VMS , et de systèmes PC tels que CP/M et systèmes dérivés tels que MS-DOS , l'extension est un espace de noms distinct du nom de fichier. Sous Microsoft DOS et Windows , des extensions telles que EXE, COMou BATindiquent qu'un fichier est un programme exécutable . Dans OS/360 et ses successeurs , la partie du nom de l'ensemble de données suivant la dernière période est traitée comme une extension par certains logiciels, par exemple TSO EDIT, mais elle n'a pas de signification particulière pour le système d'exploitation lui-même ; la même chose s'applique aux fichiers Unix dans MVS.

Les systèmes de fichiers pour les systèmes d'exploitation de type UNIX ne séparent pas les métadonnées d'extension du reste du nom de fichier. Le caractère point est juste un autre caractère dans le nom de fichier principal. Un nom de fichier ne peut avoir aucune extension, une seule extension ou plusieurs extensions. Plusieurs extensions représentent généralement des transformations imbriquées, telles que files.tar.gz(le .tarindique que le fichier est une archive tar d'un ou plusieurs fichiers, et le .gzindique que le fichier d'archive tar est compressé avec gzip ). Les programmes transformant ou créant des fichiers peuvent ajouter l'extension appropriée aux noms déduits des noms de fichiers d'entrée (à moins qu'un nom de fichier de sortie ne soit explicitement donné), mais les programmes lisant les fichiers ignorent généralement les informations ; il est principalement destiné à l'utilisateur humain. Il est plus courant, en particulier dans les fichiers binaires, que le fichier lui-même contienne des métadonnées internes décrivant son contenu. Ce modèle nécessite généralement que le nom de fichier complet soit fourni dans les commandes, alors que l'approche des métadonnées permet souvent d'omettre l'extension.

Les systèmes de fichiers VFAT , NTFS et ReFS pour Windows ne séparent pas non plus les métadonnées d'extension du reste du nom de fichier et autorisent plusieurs extensions.

Avec l'avènement des interfaces utilisateur graphiques , le problème de la gestion des fichiers et du comportement de l'interface s'est posé. Microsoft Windows permettait d'associer plusieurs applications à une extension donnée et différentes actions étaient disponibles pour sélectionner l'application requise, comme un menu contextuel offrant le choix entre l'affichage, l'édition ou l'impression du fichier. L'hypothèse était toujours que toute extension représentait un seul type de fichier ; il y avait une correspondance sans ambiguïté entre l'extension et l'icône.

Le Mac OS classique éliminait entièrement les métadonnées d'extension basées sur les noms de fichiers ; il a utilisé, à la place, un code de type de fichier distinct pour identifier le format de fichier. De plus, un code créateur a été spécifié pour déterminer quelle application serait lancée lorsque l' icône du fichier était double-cliquée . macOS , cependant, utilise des suffixes de noms de fichiers, ainsi que des codes de type et de créateur, du fait qu'il est dérivé du système d' exploitation NeXTSTEP de type UNIX .

Améliorations

L'extension de nom de fichier était à l'origine utilisée pour déterminer le type générique du fichier. La nécessité de condenser le type d'un fichier en trois caractères a souvent conduit à des extensions abrégées. Les exemples incluent l'utilisation .GFXde fichiers graphiques, .TXTde texte brut et .MUSde musique. Cependant, étant donné que de nombreux logiciels différents ont été créés pour gérer ces types de données (et d'autres) de diverses manières, les extensions de nom de fichier ont commencé à être étroitement associées à certains produits, même à des versions de produits spécifiques. Par exemple, les premiers fichiers WordStar utilisaient .WSou , où n était le numéro de version du programme. En outre, des utilisations conflictuelles de certaines extensions de nom de fichier se sont développées. Un exemple est , utilisé à la fois pour les packages RPM Package Manager et les fichiers RealPlayer Media ;. D'autres sont partagés par les polices DESQview , les registres financiers Quicken et les images QuickTime ; , partagé par les scripts GrabIt et les images ROM Game Boy Advance ; , utilisé pour SmallBasic et Scratch ; et , étant utilisé pour Dynamix Three Space et DTS . .WSn.rpm.qif.gba.sb.dts

Certains autres systèmes d'exploitation qui utilisaient des extensions de noms de fichiers avaient généralement moins de restrictions sur les noms de fichiers. Beaucoup autorisaient des longueurs de nom de fichier complètes de 14 caractères ou plus, et des longueurs de nom maximales jusqu'à 255 n'étaient pas rares. Les systèmes de fichiers dans les systèmes d'exploitation tels que Multics et UNIX stockaient le nom de fichier sous la forme d'une chaîne unique, non divisé en composants de nom de base et d'extension, permettant le "." être juste un autre caractère autorisé dans les noms de fichiers. De tels systèmes autorisent généralement des noms de fichiers de longueur variable, autorisant plus d'un point, et donc plusieurs suffixes. Certains composants de Multics et UNIX, et les applications qui s'y exécutaient, utilisaient des suffixes, dans certains cas, pour indiquer les types de fichiers, mais ils ne les utilisaient pas autant - par exemple, les exécutables et les fichiers texte ordinaires n'avaient pas de suffixes dans leurs noms.

Le système de fichiers haute performance (HPFS), utilisé dans Microsoft et IBM « s OS / 2 pris en charge également les noms de fichiers longs et ne divise pas le nom du fichier en un nom et une extension. La convention d'utiliser des suffixes a continué, même si HPFS prenait en charge les attributs étendus pour les fichiers, permettant de stocker le type d'un fichier dans le fichier en tant qu'attribut étendu.

Le système de fichiers natif de Windows NT de Microsoft , NTFS , prenait en charge les noms de fichiers longs et n'a pas divisé le nom de fichier en un nom et une extension, mais encore une fois, la convention d'utiliser des suffixes pour simuler les extensions a continué, pour la compatibilité avec les versions existantes de Windows.

Lorsque l' ère Internet est arrivée pour la première fois, ceux qui utilisaient des systèmes Windows qui étaient encore limités aux formats de nom de fichier 8.3 devaient créer des pages Web avec des noms se terminant par .HTM, tandis que ceux qui utilisaient des ordinateurs Macintosh ou UNIX pouvaient utiliser l' .htmlextension de nom de fichier recommandée . Cela est également devenu un problème pour les programmeurs expérimentant le langage de programmation Java , car il nécessite le suffixe de quatre lettres .javapour les fichiers de code source et le suffixe de cinq lettres .classpour les fichiers de sortie de code objet du compilateur Java .

Finalement, Windows 95 a introduit la prise en charge des noms de fichiers longs et a supprimé la division 8.3 nom/extension dans les noms de fichiers de Windows non NT, dans une version étendue du système de fichiers FAT couramment utilisé appelé VFAT . VFAT est apparu pour la première fois dans Windows NT 3.5 et Windows 95 . La mise en œuvre interne des noms de fichiers longs dans VFAT est largement considéré comme une bidouille , mais il supprimé l'importante restriction de longueur et les fichiers autorisés à avoir un mélange de majuscules et minuscules lettres, sur des machines qui ne fonctionneraient pas Windows NT bien.

Problèmes de nom de commande

L'utilisation d'une extension de nom de fichier dans un nom de commande apparaît occasionnellement, généralement comme un effet secondaire de la commande ayant été implémentée en tant que script, par exemple, pour le shell Bourne ou pour Python , et le nom de l'interpréteur étant suffixé au nom de la commande, un pratique courante sur les systèmes qui reposent sur des associations entre l'extension de nom de fichier et l'interpréteur, mais fortement déconseillée dans les systèmes de type Unix, tels que Linux , Oracle Solaris , les systèmes basés sur BSD et macOS d'Apple , où l'interpréteur est normalement spécifié comme un en-tête dans le script (" shebang ").

Sur les systèmes basés sur une association, l'extension de nom de fichier est généralement mappée sur une seule sélection d'interpréteur à l'échelle du système pour cette extension (comme ".py" signifiant utiliser Python), et la commande elle-même est exécutable à partir de la ligne de commande même si l'extension est omise (en supposant que la configuration appropriée soit effectuée). Si le langage d'implémentation est modifié, l'extension du nom de la commande est également modifiée et le système d'exploitation fournit une API cohérente en permettant l'utilisation de la même version sans extension de la commande dans les deux cas. Cette méthode souffre quelque peu de la nature essentiellement globale du mappage d'association, ainsi que de l'évitement incomplet des extensions par les développeurs lors de l'appel de programmes, et que les développeurs ne peuvent pas forcer cet évitement. Windows est le seul employeur encore répandu de ce mécanisme.

Sur les systèmes avec des directives d'interpréteur , y compris pratiquement toutes les versions d'Unix, les extensions de nom de commande n'ont pas de signification particulière et ne sont pas utilisées par la pratique standard, puisque la méthode principale pour définir des interpréteurs pour les scripts est de les démarrer avec une seule ligne spécifiant l'interpréteur à use (qui pourrait être considéré comme une fourchette de ressources dégénérée ). Dans ces environnements, inclure l'extension dans un nom de commande expose inutilement un détail d'implémentation qui met en danger toutes les références aux commandes d'autres programmes si l'implémentation change. Par exemple, il serait parfaitement normal qu'un script shell soit réimplémenté en Python ou Ruby, et plus tard en C ou C++, ce qui changerait tous le nom de la commande si des extensions étaient utilisées. Sans extensions, un programme a toujours le même nom sans extension, seule la directive de l' interpréteur et/ou le nombre magique changent, et les références au programme à partir d'autres programmes restent valides.

Les problèmes de sécurité

Le comportement par défaut de l' Explorateur de fichiers , le navigateur de fichiers fourni avec Microsoft Windows , est que les extensions de nom de fichier ne s'affichent pas. Des utilisateurs malveillants ont tenté de propager des virus informatiques et des vers informatiques en utilisant des noms de fichiers formés comme LOVE-LETTER-FOR-YOU.TXT.vbs. L'espoir est que cela apparaisse comme LOVE-LETTER-FOR-YOU.TXTun fichier texte inoffensif, sans alerter l'utilisateur sur le fait qu'il s'agit d'un programme informatique nuisible, dans ce cas, écrit en VBScript . Le comportement par défaut de ReactOS est d'afficher les extensions de nom de fichier dans ReactOS Explorer .

Les versions ultérieures de Windows (à commencer par Windows XP Service Pack 2 et Windows Server 2003 ) incluaient des listes personnalisables d'extensions de noms de fichiers qui devraient être considérées comme « dangereuses » dans certaines « zones » de fonctionnement, par exemple lorsqu'elles sont téléchargées à partir du Web ou reçues sous forme de courrier électronique. pièce jointe au courrier. Les systèmes logiciels antivirus modernes aident également à défendre les utilisateurs contre de telles tentatives d'attaques dans la mesure du possible.

Certains virus tirent parti de la similitude entre le domaine de premier niveau « .com » et l' extension de nom de fichier « .COM » en envoyant par courrier électronique des pièces jointes de fichier de commande exécutables malveillantes sous des noms superficiellement similaires aux URL ( par exemple , « myparty.yahoo.com » ), avec pour effet que les utilisateurs non avertis cliquent sur des liens intégrés dans les e-mails qui, selon eux, mènent à des sites Web, mais téléchargent et exécutent en réalité les pièces jointes malveillantes.

Il y a eu des cas de logiciels malveillants conçus pour exploiter les vulnérabilités de certaines applications Windows, ce qui pourrait provoquer un débordement de la mémoire tampon basée sur la pile lors de l'ouverture d'un fichier avec une extension de nom de fichier trop longue et non gérée.

L'extension de nom de fichier n'est qu'un marqueur et le contenu du fichier n'a pas à y correspondre. Cela peut être utilisé pour déguiser un contenu malveillant. Lorsqu'on essaie d'identifier un fichier pour des raisons de sécurité, il est donc considéré comme dangereux de se fier uniquement à l'extension et une bonne analyse du contenu du fichier est préférable. Par exemple, sur les systèmes dérivés d' UNIX , il n'est pas rare de trouver des fichiers sans aucune extension, car des commandes telles que file (commande) sont censées être utilisées à la place et liront l'en-tête du fichier pour déterminer son contenu.

Alternatives

Dans de nombreux protocoles Internet , tels que les e - mails HTTP et MIME , le type d'un flux binaire est indiqué comme type de média , ou type MIME, du flux, plutôt que comme extension de nom de fichier. Ceci est donné dans une ligne de texte précédant le flux, comme Content-type: text/plain .

Il n'y a pas de mappage standard entre les extensions de nom de fichier et les types de média, ce qui peut entraîner des incompatibilités d'interprétation entre les auteurs, les serveurs Web et le logiciel client lors du transfert de fichiers sur Internet. Par exemple, un auteur de contenu peut spécifier l'extension svgz pour un fichier Scalable Vector Graphics compressé , mais un serveur Web qui ne reconnaît pas cette extension peut ne pas envoyer le type de contenu approprié application/svg+xml et son en-tête de compression requis, laissant les navigateurs Web incapable d'interpréter et d'afficher correctement l'image.

BeOS , dont le système de fichiers BFS prend en charge les attributs étendus, baliserait un fichier avec son type de média en tant qu'attribut étendu. Les environnements de bureau KDE et GNOME associent un type de média à un fichier en examinant à la fois le suffixe du nom de fichier et le contenu du fichier, à la manière de la commande file , en tant qu'heuristique . Ils choisissent l'application à lancer lorsqu'un fichier est ouvert en fonction de ce type de média, réduisant ainsi la dépendance vis-à-vis des extensions de nom de fichier. macOS utilise à la fois des extensions de nom de fichier et des types de média, ainsi que des codes de type de fichier , pour sélectionner un identificateur de type uniforme permettant d'identifier le type de fichier en interne.

Voir également

Les références

Liens externes