648 votes

Quels sont les caractères interdits dans les noms de répertoires Windows et Linux ?

Je sais que / est illégal sous Linux, et les éléments suivants sont illégaux sous Windows (Je pense) * . " / \ [ ] : ; | ,

Qu'est-ce que j'ai manqué d'autre ?

J'ai cependant besoin d'un guide complet qui tienne compte des caractères à double octet. les caractères à double octet. Les liens vers des ressources extérieures me conviennent parfaitement.

Je dois d'abord créer un répertoire sur le système de fichiers en utilisant un nom qui peut contenir des caractères interdits. contenir des caractères interdits, je prévois donc de remplacer ces caractères par des caractères de soulignement. Je dois ensuite écrire ce répertoire et son contenu dans un fichier zip (en utilisant Java). (en utilisant Java), donc tout conseil supplémentaire concernant les noms des répertoires zip serait apprécié.

23 votes

Certains des caractères que vous mentionnez sont en fait autorisés sous Windows. Vérifiez ceci : echo abc > "ab.;,=[1]"

0 votes

Vous pouvez utiliser encodeURIComponent (Javascript) ou un équivalent.

8 votes

N'oubliez pas non plus que < et > sont illégaux sous Windows.

268voto

Dour High Arch Points 11896

Un "guide complet" des caractères interdits pour les noms de fichiers ne fonctionnera pas sous Windows, car celui-ci réserve les noms de fichiers ainsi que les caractères. Oui, des caractères comme * " ? et d'autres sont interdits, mais il existe un nombre infini de noms composés uniquement de caractères valides qui sont interdits. Par exemple, les espaces et les points sont des caractères de nom de fichier valides, mais les noms composés uniquement de ces caractères sont interdits.

Windows ne fait pas de distinction entre les caractères majuscules et minuscules, vous ne pouvez donc pas créer un dossier nommé A si un nommé a existe déjà. Pire encore, des noms apparemment autorisés comme PRN y CON et bien d'autres, sont réservés et non autorisés. Windows a également plusieurs restrictions de longueur ; un nom de fichier valide dans un dossier peut devenir invalide s'il est déplacé dans un autre dossier. Les règles pour nommer les fichiers et les dossiers sont sur les docs de Microsoft.

Vous ne pouvez pas, en général, utiliser du texte généré par l'utilisateur pour créer des noms de répertoire Windows. Si vous voulez permettre aux utilisateurs de nommer ce qu'ils veulent, vous devez créer des noms sûrs tels que A , AB , A2 et al., stockez les noms générés par l'utilisateur et leurs équivalents de chemin d'accès dans un fichier de données d'application, et effectuez le mappage des chemins d'accès dans votre application.

Si vous devez absolument autoriser les noms de dossiers créés par l'utilisateur, la seule façon de savoir s'ils ne sont pas valides est d'attraper les exceptions et de supposer que le nom n'est pas valide. Même cette méthode est périlleuse, car les exceptions lancées en cas d'accès refusé, de lecteurs hors ligne et d'espace disque insuffisant se chevauchent avec celles qui peuvent être lancées pour des noms non valides. Vous ouvrez une énorme boîte de Pandore.

12 votes

La phrase clé du lien MSDN est "[et] tout autre caractère que le système de fichiers cible n'autorise pas". Il peut y avoir différents systèmes de fichiers sous Windows. Certains peuvent autoriser Unicode, d'autres non. En général, la seule façon sûre de valider un nom est de l'essayer sur le périphérique cible.

130 votes

Il y a quelques directives, et "il existe un nombre infini de noms composés uniquement de caractères valides qui sont interdits" n'est pas constructive. De même, "Windows ne fait pas la distinction entre les caractères majuscules et minuscules" est une exception stupide - le PO pose des questions sur la syntaxe et non sur la sémantique, et aucune personne saine d'esprit ne dirait qu'un nom de fichier comme A.txt était invalide parce que a.TXT peut exister.

2 votes

L'idée selon laquelle il ne faut pas autoriser l'accès des utilisateurs aux adresses des structures de fichiers est judicieuse mais très mal formulée. Les utilisateurs doivent pouvoir examiner et manipuler les entités que l'application leur expose. Si ces entités peuvent être des abstraits de plusieurs bases de données portant un nom dynamique, il n'y a rien de mal à demander à l'utilisateur le nom d'un fichier. Les sécurités d'une application doivent empêcher les utilisateurs de commettre des erreurs et d'outrepasser leur autorité ; elles ne doivent pas les empêcher de faire ce qu'ils doivent faire.

91voto

Jonathan Leffler Points 299946

Sous Linux et d'autres systèmes liés à Unix, il n'y a que deux caractères qui ne peuvent pas apparaître dans le nom d'un fichier ou d'un répertoire, et ce sont les suivants : NUL '\0' et la barre oblique '/' . La barre oblique, bien sûr, peut apparaître dans un nom de chemin, pour séparer les composants du répertoire.

Rumeur 1 On raconte que Steven Bourne (le célèbre "shell") avait un répertoire contenant 254 fichiers, un pour chaque lettre (code de caractères) pouvant apparaître dans un nom de fichier (à l'exclusion de / , '\0' ; le nom . était le répertoire courant, bien sûr). Il était utilisé pour tester le Bourne shell et faisait régulièrement des ravages sur des programmes imprudents comme les programmes de sauvegarde.

Autre personnes ont abordé les règles relatives aux noms de fichiers Windows, avec des liens vers les sites suivants Microsoft y Wikipedia sur le sujet.

Notez que MacOS X possède un système de fichiers insensible à la casse. Les versions actuelles de ce système semblent autoriser les deux-points : dans les noms de fichiers, bien qu'historiquement, ce n'était pas toujours le cas :

$ echo a:b > a:b
$ ls -l a:b
-rw-r--r--  1 jonathanleffler  staff  4 Nov 12 07:38 a:b
$

POSIX définit un Jeu de caractères pour les noms de fichiers portables composé de :

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
a b c d e f g h i j k l m n o p q r s t u v w x y z
0 1 2 3 4 5 6 7 8 9 . _ -

Le fait de s'en tenir à des noms formés uniquement à partir de ces caractères évite la plupart des problèmes, bien que Windows ajoute encore quelques complications.


1 C'est Kernighan & Pike dans ['The Practice of Programming'] (http://www.cs.princeton.edu/~bwk/tpop.webpage/) qui l'ont dit dans le chapitre 6, Tests, §6.5 Stress Tests :

Lorsque Steve Bourne a écrit son interpréteur de commandes Unix (connu sous le nom d'interpréteur de commandes Bourne), il a créé un répertoire de 254 fichiers portant des noms à un caractère, un pour chaque valeur d'octet, à l'exception des fichiers suivants '\0' et slash, les deux caractères qui ne peuvent pas apparaître dans les noms de fichiers Unix. Il a utilisé ce répertoire pour toutes sortes de tests de reconnaissance de motifs et de tokenisation. (Le répertoire de test était bien sûr créé par un programme). Pendant des années, ce répertoire a été le fléau des programmes de recherche d'arbres de fichiers ; il les testait jusqu'à la destruction.

Notez que le répertoire doit avoir contenu des entrées . y .. Il s'agissait donc de 253 fichiers (et 2 répertoires), ou de 255 entrées de noms, plutôt que de 254 fichiers. Cela n'affecte pas l'efficacité de l'anecdote, ni les tests minutieux qu'elle décrit.

_TPOP était auparavant à http://plan9.bell-labs.com/cm/cs/tpop et http://cm.bell-labs.com/cm/cs/tpop mais les deux sont maintenant (2021-11-12) cassés. Voir aussi Wikipedia sur TPOP ._

1 votes

254 fichiers ? Et qu'en est-il de l'utf8 ?

28 votes

Les 254 fichiers étaient tous des noms de fichiers à un seul caractère, un par caractère autorisé dans un nom de fichier. UTF-8 n'était même pas une lueur d'espoir à l'époque où Steve Bourne a écrit le Bourne shell. UTF-8 impose des règles concernant les séquences d'octets valides (et interdit les octets 0xC0, 0xC1, 0xF5-0xFF). Sinon, ce n'est pas très différent - au niveau de détail dont je parle.

2 votes

Le séparateur de répertoire sur le disque pour les systèmes de fichiers MacOS HFS+ est en fait un ':' plutôt qu'un '/'. Le système d'exploitation fait généralement (et probablement toujours) ce qu'il faut lorsque vous travaillez avec des API *nix. Mais ne vous attendez pas à ce que cela se produise de manière fiable si vous passez au monde OSX, par exemple avec applescript. Il semble que les API Cocoa utilisent peut-être aussi le / et vous cachent le :, mais je suis pratiquement sûr que les anciennes API Carbon ne le font pas.

29voto

Leonardo Herrera Points 4079

Eh bien, si c'est seulement à des fins de recherche, alors votre meilleure chance est de regarder à cette entrée Wikipedia sur les noms de fichiers .

Si vous voulez écrire une fonction portable pour valider les entrées de l'utilisateur et créer des noms de fichiers sur cette base, la réponse courte est la suivante Ne le fais pas. . Jetez un coup d'œil à un module portable comme celui de Perl Fichier::Spec d'avoir un aperçu de tous les houblons nécessaires pour accomplir une tâche aussi "simple".

2voto

I. J. Kennedy Points 7430

Il y a un bon tableau couvrant les règles de dénomination des fichiers pour les différents systèmes d'exploitation. ici . (partie de l'article du wiki "Nom de fichier").

-3voto

Sous Linux, seul / (barre oblique) n'est pas autorisé dans les noms de fichiers et de répertoires, '\0' peut être utilisé en échappant la barre oblique arrière.

touch "Hello\0World.txt"

Ou :

touch Hello\\0World.txt

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X