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

restons simples et répondons d'abord à la question.

1. L'interdit caractères ASCII imprimables sont:

   • Linux / Unix:

     / (forward slash)
     

   • de Windows:

     < (less than)
     > (greater than)
     : (colon - sometimes works, but is actually NTFS Alternate Data Streams)
     " (double quote)
     / (forward slash)
     \ (backslash)
     | (vertical bar or pipe)
     ? (question mark)
     * (asterisk)
     

2. caractères Non imprimables

   si vos données proviennent d'une source qui permettrait des caractères non imprimables, alors il y a plus à vérifier.

   • Linux / Unix:

     0 (NULL byte)
     

   • de Windows:

     0-31 (ASCII control characters)
     

   Note: alors qu'il est légal sous les systèmes de fichiers Linux/Unix de créer des fichiers avec des caractères de contrôle dans le nom du fichier, il pourrait être un cauchemar pour les utilisateurs de traiter de tels fichiers .

3. noms de Fichiers réservés

   les noms de fichiers suivants sont réservés:

   • de Windows:

     CON, PRN, AUX, NUL 
     COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
     LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
     

4. autres règles

   • de Windows:

     Les noms de fichiers

     ne peuvent pas se terminer par un espace ou un point.

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 NUL '" 151900920 "' et slash '/' . La barre oblique, bien sûr, peut apparaître dans un nom de chemin, séparant les composants du répertoire.

rumeur ¹ dit que Steven Bourne (de "shell" fame) avait un répertoire contenant 254 fichiers, un pour chaque lettre (code de caractère) pouvant apparaître dans un fichier nom (sauf / , '"151900920"' ; le nom . était le répertoire courant, bien sûr). Il a été utilisé pour tester le Bourne shell et a régulièrement provoqué des ravages sur les programmes imprudents tels que les programmes de sauvegarde.

D'autres personnes ont couvert les règles des fenêtres.

notez que MacOS X a un système de fichiers insensible à la casse.

lorsque Steve Bourne a écrit son shell Unix (qui est devenu connu sous le nom de shell Bourne), il a créé un répertoire de 254 fichiers avec des noms à un caractère, un pour chaque valeur de byte sauf '" 151900920 "' 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 filtrage et de segmentation. (Le le répertoire de test a bien sûr été créé par un programme. Pendant des années, ce répertoire a été le fléau des programmes d'arborescence des fichiers; il les a testés jusqu'à leur destruction.

au lieu de créer une liste noire de caractères, vous pouvez utiliser un liste blanche . Tout bien considéré, la gamme de caractères qui ont du sens dans un contexte de nom de fichier ou de répertoire est assez courte, et à moins que vous n'ayez des exigences de nommage très spécifiques, vos utilisateurs ne la retiendront pas contre votre application s'ils ne peuvent pas utiliser l'ensemble de la table ASCII.

Il ne résout pas le problème des noms réservés dans le système de fichiers cible, mais avec un whitelist il est plus facile d'atténuer les risques à la source.

dans cet esprit, il s'agit d'une gamme de caractères qui peuvent être considérés comme sûrs:

• lettres (A-z A-Z) - caractères Unicode ainsi, si nécessaire
• chiffres (0-9)
• trait de Soulignement (_)
• trait D'Union ( - )
• Espace
• Dot (.)

et tout autre caractère de sécurité que vous souhaitez autoriser. En outre, vous avez juste à appliquer quelques règles supplémentaires concernant les espaces et les points . Ceci est généralement suffisant:

• nom doit contenir au moins une lettre ou un numéro (pour éviter seulement les points/espaces)
• nom doit commencer par une lettre ou un numéro (pour éviter les points/espaces)

cela déjà permet des noms assez complexes et absurdes. Par exemple, ces noms seraient possibles avec ces règles, et seraient des noms de fichier valides dans Windows / Linux:

• A...........ext
• B -.- .ext

en essence, même avec si peu de caractères de liste blanche, vous devriez encore décider ce qui a du sens, et valider/ajuster le nom en conséquence. Dans une de mes applications, j'ai utilisé les mêmes règles que ci-dessus mais dépouillé tous les points et espaces dupliqués.

bien, si ce n'est qu'à des fins de recherche, alors votre meilleur pari est de regarder cette entrée Wikipédia sur les noms de fichier .

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 ne pas . Jetez un coup d'oeil à un module portable comme le fichier de Perl::Spec pour avoir un aperçu de tous les sauts nécessaires pour accomplir une telle tâche "simple".

la manière la plus simple d'obtenir que Windows vous indique la réponse est d'essayer de renommer un fichier via Explorer et de taper / pour le nouveau nom. Windows affichera un message vous indiquant la liste des caractères illégaux.

A filename cannot contain any of the following characters:
    \ / : * ? " < > | 

https://support.microsoft.com/en-us/kb/177506

Pour Windows, vous pouvez le vérifier en utilisant PowerShell

$PathInvalidChars = [System.IO.Path]::GetInvalidPathChars() #36 chars

pour afficher les codes UTF-8, Vous pouvez convertir

$enc = [system.Text.Encoding]::UTF8
$PathInvalidChars | foreach { $enc.GetBytes($_) }

$FileNameInvalidChars = [System.IO.Path]::GetInvalidFileNameChars() #41 chars

$FileOnlyInvalidChars = @(':', '*', '?', '\', '/') #5 chars - as a difference

en date du 18/04/2017, aucune simple liste noire ou blanche de personnages et de noms de fichiers n'est évidente parmi les réponses à ce sujet - et il ya beaucoup de réponses.

la meilleure suggestion que j'ai pu trouver était de laisser l'utilisateur nommer le fichier comme il l'aime. Utilisation d'un gestionnaire d'erreurs lorsque l'application essaie de sauvegarder le fichier, de saisir les exceptions, de supposer que le nom du fichier est à blâmer (évidemment après s'être assuré que le chemin de sauvegarde était ok aussi bien), et d'inviter l'utilisateur pour un nouveau nom de fichier. Pour de meilleurs résultats, placez cette procédure de vérification dans une boucle qui continue jusqu'à ce que l'utilisateur obtienne ce droit ou abandonne. Ça a marché le mieux pour moi (au moins en VBA).

exemple de code VBA: (sera ajouté plus tard aujourd'hui)

bien que les seuls chars Unix illégaux puissent être / et NULL , bien qu'une certaine considération pour l'interprétation en ligne de commande devrait être incluse.

par exemple, bien qu'il puisse être légal de nommer un fichier 1>&2 ou 2>&1 dans Unix, les noms de fichiers tels que ceux-ci peuvent être mal interprétés lorsqu'ils sont utilisés sur une ligne de commande.

de même , il peut être possible de nommer un fichier $PATH , mais en essayant d'y accéder à partir de la en ligne de commande, le shell traduira $PATH à sa valeur variable.

lors de la création de raccourcis internet dans Windows, pour créer le nom de fichier, il saute les caractères illégaux, sauf pour slash forward, qui est converti en moins.

dans les shells Unix, vous pouvez citer presque tous les caractères entre guillemets ' . Sauf la simple citation elle-même, et vous ne pouvez pas exprimer les caractères de contrôle, parce que \ n'est pas élargi. L'accès à la citation elle-même à partir d'une chaîne de caractères est possible, car vous pouvez concaténer des chaînes avec des guillemets simples et doubles, comme 'I'"'"'m' qui peut être utilisé pour accéder à un fichier appelé "I'm" (double citation également possible ici).

So vous devez éviter tous les caractères de contrôle, parce qu'ils sont trop difficiles pour entrer dans le shell. Le reste est quand même drôle, surtout les fichiers commençant par un tiret, car la plupart des commandes les lisent comme des options à moins que vous n'ayez deux tirets -- avant, ou que vous les spécifiez avec ./ , ce qui cache aussi le démarrage - .

si vous voulez être gentil, n'utilisez aucun des caractères que le shell et les commandes typiques utilisent comme éléments syntaxiques, parfois dépendant de la position, ainsi par exemple vous pouvez toujours utiliser - , mais pas comme premier caractère; même avec . , vous pouvez l'utiliser comme premier caractère seulement quand vous le pensez ("fichier caché"). Quand vous êtes Moyen, vos noms de fichier sont des séquences d'échappement VT100; -), de sorte qu'un ls déchiffre la sortie.

j'avais le même besoin et je cherchais des recommandations ou des références standard et je suis tombé sur ce fil. Ma liste noire actuelle de caractères qui devrait être évitée dans les noms de fichiers et de répertoires est:

$CharactersInvalidForFileName = {
    "pound" -> "#",
    "left angle bracket" -> "<",
    "dollar sign" -> "$",
    "plus sign" -> "+",
    "percent" -> "%",
    "right angle bracket" -> ">",
    "exclamation point" -> "!",
    "backtick" -> "`",
    "ampersand" -> "&",
    "asterisk" -> "*",
    "single quotes" -> "“",
    "pipe" -> "|",
    "left bracket" -> "{",
    "question mark" -> "?",
    "double quotes" -> "”",
    "equal sign" -> "=",
    "right bracket" -> "}",
    "forward slash" -> "/",
    "colon" -> ":",
    "back slash" -> "\",
    "lank spaces" -> "b",
    "at sign" -> "@"
};