Nom de fichier

Un nom de fichier sert à identifier de manière unique un fichier informatique dans un système de fichiers . Différents systèmes de fichiers imposent différentes restrictions quant à la longueur des noms de fichiers.

Un nom de fichier peut (selon le système de fichiers) inclure :

• nom – nom de base du fichier
• extension – peut indiquer le format du fichier (par exemple.txt, pour du texte brut ,.pdfpour le format PDF ,.datpour des données binaires non spécifiées, etc.).

Les composants nécessaires à l'identification d'un fichier par les utilitaires et les applications varient selon les systèmes d'exploitation, tout comme la syntaxe et le format d'un nom de fichier valide.

Les caractères autorisés dans les noms de fichiers dépendent du système de fichiers. La plupart des systèmes de fichiers autorisent les lettres de A à Z et les chiffres de 0 à 9 ; beaucoup prennent en charge des caractères supplémentaires, tels que les lettres de a à z, les caractères spéciaux et d’autres caractères imprimables comme les lettres accentuées, les symboles des alphabets non latins et les symboles des écritures non alphabétiques. Certains systèmes de fichiers autorisent même les caractères non imprimables, notamment la sonnerie , le caractère nul , le retour à la ligne et le saut de ligne , dans un nom de fichier bien que la plupart des utilitaires ne les gèrent pas correctement.

Les noms de fichiers peuvent inclure des éléments tels qu'un numéro de révision ou de génération du fichier, un numéro de séquence numérique (largement utilisé par les appareils photo numériques via la norme DCF ), une date et une heure (largement utilisées par les logiciels d'appareil photo des smartphones et pour les captures d'écran ), ou un commentaire tel que le nom d'un sujet ou d'un lieu ou tout autre texte permettant d'identifier le fichier.

Certains utilisent le terme « nom de fichier » pour désigner une spécification complète incluant le périphérique, les sous-répertoires et le nom du fichier, comme par exemple : C:\Program Files\Microsoft Games\Chess\Chess.exe sous Windows . Dans ce cas, le nom du fichier est Chess.exe . Certains utilitaires, comme l'Explorateur Windows, proposent une option permettant de masquer l'extension.ordinateurs centraux et mini-ordinateurs disposaient de systèmes d'exploitation où les fichiers du système étaient identifiés par un nom d'utilisateur ou un numéro de compte.

Par exemple, sur les systèmes d'exploitation TOPS-10 et RSTS/E de Digital Equipment Corporation , les fichiers étaient identifiés par

• Nom de l'appareil (facultatif, un ou deux caractères) suivi d'un numéro d'unité (facultatif) et de deux points :. En l'absence de ces informations, la valeur « SY » est utilisée.
• Le numéro de compte, composé d'une parenthèse fermante « [ », d'une paire de chiffres séparés par une virgule, et suivi d'une parenthèse fermante « ] ». S'il était omis, il était présumé être le vôtre.
• Nom de fichier obligatoire, composé de 1 à 6 caractères (lettres majuscules ou chiffres)
• Extension optionnelle de 3 caractères.

Sur OS/360 et les systèmes d'exploitation successeurs d' IBM , un nom de fichier peut comporter jusqu'à 44 caractères, composés de lettres majuscules, de chiffres et d'un point. Il doit commencer par une lettre ou un chiffre, contenir au moins un point tous les 8 caractères, et ne peut pas contenir deux points consécutifs. Le nom doit se terminer par une lettre ou un chiffre. Par convention, lors de l'utilisation de TSO , les lettres et les chiffres précédant le premier point correspondent au numéro de compte du propriétaire ou au numéro du projet auquel le fichier appartient. Toutefois, cette convention n'est pas obligatoire.

Sur le système MUSIC/SP de l'Université McGill , les noms de fichiers étaient composés de

• Numéro de compte facultatif, composé d'un à quatre caractères suivis de deux points. Si le numéro de compte était manquant, on supposait qu'il se trouvait dans votre compte ; sinon, on supposait qu'il se trouvait dans le pseudo-compte *COM:, où étaient catalogués tous les fichiers marqués comme publics.
• Nom de fichier de 1 à 17 caractères, pouvant être des lettres majuscules ou des chiffres, et le point, à condition qu'il ne commence ni ne se termine par un point, et qu'il ne contienne pas deux points consécutifs.

Le système d'exploitation Univac VS/9 utilisait des noms de fichiers composés de

• Le nom du compte se composait d'un signe dollar « $ », d'un nom d'utilisateur de 1 à 7 caractères (lettres ou chiffres) et d'un point (« . »). En son absence, le fichier était supposé se trouver dans votre compte. Dans le cas contraire, le système d'exploitation effectuait une recherche dans le compte de l'administrateur système, $TSOS. Si vous saisissiez uniquement un signe dollar comme nom de compte, cela indiquait que le fichier se trouvait dans le compte $TSOS, sauf si les 7 premiers caractères du nom de fichier précédant le point correspondaient à un nom de compte existant. Dans ce cas, c'était ce compte qui était utilisé. Par exemple, si ABLE.BAKER est un fichier de votre compte, le système le rechercherait dans $TSOS.ABLE.BAKER. Si $ABLE.BAKER était spécifié, le fichier $TSOS.ABLE.BAKER serait utilisé, sauf si $ABLE était un compte valide. Dans ce cas, le système rechercherait un fichier nommé BAKER dans ce compte.
• Nom de fichier : 1 à 56 caractères (lettres et chiffres) séparés par des points. Un nom de fichier ne peut pas commencer ni se terminer par un point, et deux points consécutifs ne peuvent pas apparaître.

En 1985, la RFC 959 a officiellement défini un chemin d'accès comme étant la chaîne de caractères qu'un utilisateur doit saisir dans un système de fichiers afin d'identifier un fichier.

Sur les premiers ordinateurs personnels utilisant le système d'exploitation CP/M , les noms de fichiers comportaient toujours 11 caractères. On parlait alors de nom de fichier 8.3 , avec un maximum de 8 octets pour le nom et de 3 octets pour l'extension. Les utilitaires et applications permettaient aux utilisateurs de spécifier des noms de fichiers sans espaces de fin et d'ajouter un point avant l'extension. Ce point n'était pas stocké dans le répertoire. L'utilisation de caractères de 7 bits seulement permettait d'inclure plusieurs attributs de fichier dans le nom, grâce au bit de poids fort ; ces attributs comprenaient « Lecture seule », « Archive » et « Système ». Cette limitation s'avéra trop restrictive et le nombre de caractères autorisés fut augmenté. Les bits d'attributs furent déplacés dans un bloc spécial du fichier contenant des informations supplémentaires.File Allocation Table ) d'origine, utilisé par Standalone Disk BASIC-80 , imposait une convention de nommage de fichiers 6.3 octets, avec un maximum de 6 octets pour le nom et 3 octets pour l'extension. Les systèmes de fichiers FAT12 et FAT16 d' IBM PC DOS / MS-DOS et de Microsoft Windows (avant Windows 95) utilisaient la même convention 8.3 que le système de fichiers CP/M. Les systèmes de fichiers FAT prenaient en charge les caractères 8 bits, ce qui leur permettait d'inclure des caractères non ASCII dans les noms de fichiers, et stockaient les attributs séparément du nom de fichier.

Aux alentours de 1995, VFAT , une extension du système de fichiers FAT de MS-DOS, a été introduit dans Windows 95 et Windows NT . Il autorisait les noms de fichiers longs (LFN) en casse mixte , utilisant des caractères Unicode , en plus des noms classiques « 8.3 ».

Les programmes et les périphériques peuvent attribuer automatiquement des noms aux fichiers, tels qu'un compteur numérique (par exemple IMG_0001.JPG) ou un horodatage avec la date et l'heure actuelles.

L'avantage d'un nom de fichier horodaté est qu'il facilite la recherche de fichiers par date, les gestionnaires de fichiers proposant généralement une recherche par nom. De plus, les fichiers provenant de différents appareils peuvent être fusionnés dans un même répertoire sans conflit de noms.

En revanche, les noms de fichiers numérotés ne nécessitent pas que l'horloge interne de l'appareil soit correctement réglée. Par exemple, certains utilisateurs d'appareils photo numériques peuvent ne pas se soucier du réglage de l'horloge de leur appareil. Les appareils connectés à Internet, tels que les smartphones, peuvent synchroniser leur horloge à partir d'un serveur NTP.

La convention de nommage de fichiers la plus courante consiste à limiter les noms de répertoires et de fichiers aux 65 caractères autorisés par le jeu de caractères POSIX . Une méthode fréquente consiste à stocker le titre complet d'un document dans le fichier lui-même, sous forme de caractères UTF-8 arbitraires, puis à générer automatiquement un « slug » à partir de ce titre pour servir de nom de fichier.

Les systèmes de fichiers de type Unix permettent à un fichier d'avoir plusieurs noms ; dans les systèmes de fichiers Unix traditionnels, ces noms sont des liens physiques pointant vers l' inode du fichier ou son équivalent. Windows prend en charge les liens physiques sur les systèmes de fichiers NTFS et propose une commande, fsutilsous Windows XP et mklinkversions ultérieures, pour les créer. Les liens physiques diffèrent des raccourcis Windows, des alias classiques de Mac OS/macOS et des liens symboliques . L'introduction des noms de fichiers longs (LFN) avec VFAT a permis l'utilisation d'alias de fichiers. Par exemple, longfi~1.???avec un maximum de huit caractères plus trois, un alias de fichier tel que «long file name.??? » permettait de se conformer aux limitations de la version 8.3 pour les anciens programmes.

Cette propriété était utilisée par l'algorithme de commande de déplacement qui crée d'abord un deuxième nom de fichier, puis supprime uniquement le premier nom de fichier.

D'autres systèmes de fichiers, de par leur conception, ne fournissent qu'un seul nom de fichier par fichier, ce qui garantit que la modification d'un fichier portant un nom de fichier donné n'affecte pas le fichier portant un autre nom de fichier.

Certains systèmes de fichiers limitent la longueur des noms de fichiers. Dans certains cas, cette limite s'applique à l'intégralité du nom, comme 44 caractères sous IBM z/OS . Dans d'autres cas, elle peut concerner des parties spécifiques du nom, telles que le nom d'un fichier dans un répertoire ou le nom d'un répertoire. Par exemple : 9 caractères ( FAT 8 bits sous Standalone Disk BASIC ), 11 caractères ( FAT12 , FAT16 et FAT32 sous DOS), 14 caractères (anciennes versions d'Unix), 21 caractères ( Human68K ), 31 caractères , 30 caractères ( Apple DOS 3.2 et 3.3), 15 caractères ( Apple ProDOS ), 44 caractères (IBM S/370) ou 255 caractères (anciennes versions d'Unix Berkeley). Les limites de longueur résultent souvent de l'attribution d'un espace fixe dans un système de fichiers au stockage des composants des noms ; par conséquent, l'augmentation des limites nécessite souvent une modification incompatible, ainsi que la réservation de davantage d'espace.

Un problème particulier des systèmes de fichiers stockant les informations dans des répertoires imbriqués est la possibilité de créer un fichier dont le chemin d'accès complet dépasse les limites d'implémentation, car la vérification de la longueur peut ne s'appliquer qu'à certaines parties du nom et non au nom entier. De nombreuses applications Windows sont limitées à une MAX_PATHvaleur de 260 caractères, mais les noms de fichiers Windows peuvent facilement dépasser cette limite. À partir de Windows 10, version 1607 , les limitations de MAX_PATH ont été supprimées.

Il n'existe pas de norme d'encodage générale pour les noms de fichiers.

Les noms de fichiers doivent être échangés entre les environnements logiciels pour le transfert de fichiers en réseau, le stockage sur système de fichiers, les logiciels de sauvegarde et de synchronisation, la gestion de la configuration, la compression et l'archivage des données, etc. Il est donc essentiel de ne pas perdre ces informations entre les applications. C'est pourquoi Unicode s'est largement imposé comme norme d'encodage des noms de fichiers, même si certains logiciels anciens ne sont pas compatibles avec Unicode.

Dans un même répertoire, les noms de fichiers doivent être uniques. La syntaxe des noms de fichiers s'appliquant également aux répertoires, il est impossible de créer des entrées de fichier et de répertoire portant le même nom dans un même répertoire. Plusieurs fichiers situés dans des répertoires différents peuvent porter le même nom.format de normalisation Unicode, comme NFC ou NFD. Cela signifie que deux fichiers distincts peuvent être créés avec le même nom de fichier texte et une implémentation binaire différente, comme L"\x00C0.txt" (UTF-16, NFC) (A majuscule latin avec accent grave) et L"\x0041\x0300.txt" (UTF-16, NFD) (A majuscule latin avec accent grave).

Certains systèmes de fichiers, comme FAT avant l'introduction de VFAT , stockent les noms de fichiers en majuscules, quelle que soit la casse utilisée lors de leur création. Par exemple, un fichier nommé « MyName.Txt » ou « myname.txt » sera enregistré sous le nom « MYNAME.TXT » (VFAT conserve la casse). Toute combinaison de majuscules et de minuscules peut être utilisée pour désigner le même fichier. Ces systèmes de fichiers sont dits insensibles à la casse et ne conservent pas la casse . Certains systèmes de fichiers interdisent totalement l'utilisation de minuscules dans les noms de fichiers.

Certains systèmes de fichiers conservent les noms de fichiers tels qu'ils ont été créés ; on les appelle systèmes respectant la casse. Ces systèmes peuvent être sensibles ou insensibles à la casse. S'ils sont sensibles à la casse, « MyName.Txt » et « myname.txt » peuvent désigner deux fichiers différents dans le même répertoire, et chaque fichier doit être référencé en respectant la casse exacte. En revanche , sur un système de fichiers insensible à la casse mais respectant la casse, un fichier ne peut porter que l'un des noms suivants dans un répertoire donné à un instant donné : « MyName.Txt », « myname.txt » ou « Myname.TXT ». Ce fichier peut alors être référencé quelle que soit la casse.

Dès leur origine, les systèmes de fichiers d'Unix et de ses dérivés étaient sensibles à la casse et la préservaient. Cependant, tous les systèmes de fichiers de ces systèmes ne sont pas sensibles à la casse ; par défaut, HFS+ et APFS sous macOS sont insensibles à la casse mais la préservent, et les serveurs SMB offrent généralement un comportement insensible à la casse (même lorsque le système de fichiers sous-jacent est sensible à la casse, comme Samba sur la plupart des systèmes de type Unix), et les systèmes de fichiers clients SMB offrent également un comportement insensible à la casse. La sensibilité à la casse des systèmes de fichiers représente un défi considérable pour des logiciels tels que Samba et Wine , qui doivent interagir efficacement avec les systèmes qui traitent les fichiers en majuscules et en minuscules comme étant différents, ainsi qu'avec les systèmes qui les traitent de la même manière.