Quels caractères sont interdits dans les noms de répertoire Windows et Linux?
Je sais que/est illégal sous Linux, et les suivants sont interdits sous Windows (je pense) *."/\[]:;|,
Que manque-t-il d'autre?
J'ai besoin d'un guide complet, cependant, qui prenne en compte les caractères double octet. La connexion à des ressources extérieures me convient parfaitement.
Je dois d'abord créer un répertoire sur le système de fichiers en utilisant un nom pouvant contenir des caractères interdits. Je prévois donc de remplacer ces caractères par des traits de soulignement. J'ai ensuite besoin d'écrire ce répertoire et son contenu dans un fichier Zip (avec Java), donc tout conseil supplémentaire concernant les noms des répertoires Zip serait apprécié.
Un "guide complet" des caractères de nom de fichier interdits ne fonctionnera pas sous Windows car il réserve les noms de fichiers ainsi que les caractères. Oui, les caractères tels que *"? et les autres sont interdits, mais il existe un nombre infini de noms composés uniquement de caractères valides interdits. Par exemple, les espaces et les points sont des caractères de nom de fichier corrects, mais les noms composés uniquement de ces caractères sont interdits.
Windows ne fait pas la distinction entre les majuscules et les minuscules, vous ne pouvez donc pas créer un dossier nommé A s'il existe déjà un nom nommé a. Pire, les noms apparemment autorisés tels que PRN et CON, ainsi que de nombreux 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 MSDN.
En règle générale, vous ne pouvez pas utiliser de texte généré par l'utilisateur pour créer des noms de répertoire Windows. Si vous souhaitez autoriser les utilisateurs à nommer ce qu'ils veulent, vous devez créer des noms sécurisés tels que A, AB, A2 et al., Stockez les noms générés par l'utilisateur et leurs équivalents de chemin dans un fichier de données d'application et effectuez un mappage de chemin dans votre application.
Si vous devez absolument autoriser les noms de dossiers générés par l'utilisateur, le seul moyen de savoir s'ils sont non valides consiste à intercepter les exceptions et à supposer que le nom est invalide. Même cela est périlleux, car les exceptions levées pour les interdictions d’accès, les lecteurs hors connexion et les espaces insuffisants chevauchent celles qui peuvent être émises pour des noms non valides. Vous ouvrez une énorme boîte de conserve.
Restons simples et répondons d'abord à la question.
Les caractères interdits imprimables ASCII sont les suivants:
Linux/Unix:
/ (forward slash)Les fenêtres:
< (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)
Caractères non imprimables
Si vos données proviennent d'une source permettant des caractères non imprimables, vous devez en vérifier davantage.
Linux/Unix:
0 (NULL byte)Les fenêtres:
0-31 (ASCII control characters)
Remarque: Bien qu'il soit 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, cela pourrait être un cauchemar pour les utilisateurs de le faire fichiers .
Noms de fichiers réservés
Les noms de fichiers suivants sont réservés:
Les fenêtres:
CON, PRN, AUX, NUL COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9(seuls ou avec des extensions de fichier arbitraires, par exemple
LPT1.txt).
Autres règles
Les fenêtres:
Les noms de fichiers ne peuvent pas se terminer par un espace ou un point.
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 d'exigences de nommage très précises, vos utilisateurs ne l'utiliseront pas si ils ne peuvent pas utiliser l'intégralité de ASCII table.
Cela ne résout pas le problème des noms réservés dans le système de fichiers cible, mais avec une liste blanche, il est plus facile d'atténuer les risques à la source.
Dans cet esprit, il s'agit d'une gamme de caractères pouvant être considérés comme sûrs:
- Lettres (a-z A-Z) - Caractères Unicode également, si nécessaire
- Chiffres (0-9)
- Souligner (_)
- Trait d'union (-)
- Space
- Point (.)
Et tous les caractères supplémentaires que vous souhaitez autoriser. Au-delà de cela, il vous suffit d'appliquer quelques règles supplémentaires concernant les espaces et les points. C'est généralement suffisant:
- Le nom doit contenir au moins une lettre ou un chiffre (pour éviter uniquement les points/espaces)
- Le nom doit commencer par une lettre ou un chiffre (pour éviter les points ou les espaces)
- Le nom ne peut pas se terminer par un point ou un espace (il suffit de les couper, le cas échéant, comme le fait Explorer)
Cela permet déjà des noms assez complexes et absurdes. Par exemple, ces noms seraient possibles avec ces règles et constitueraient des noms de fichiers valides sous Windows/Linux:
A...........extB -.- .ext
En substance, même avec si peu de caractères de la liste blanche, vous devez quand même décider de ce qui fait sens, et valider/ajuster le nom en conséquence. Dans l'une de mes applications, j'ai utilisé les mêmes règles que ci-dessus, mais j'ai supprimé tous les points et espaces en double.
Eh bien, ne fût-ce qu’à des fins de recherche, votre meilleur choix est de regarder cette entrée Wikipedia sur les noms de fichiers .
Si vous souhaitez écrire une fonction portable pour valider la saisie de l'utilisateur et créer des noms de fichiers basés sur celle-ci, la réponse courte est et non . Jetez un coup d'œil à un module portable comme Perl File :: Spec pour avoir un aperçu de tous les sauts nécessaires à la réalisation d'une tâche aussi "simple".
Le moyen le plus simple pour que Windows vous dise la réponse consiste à tenter de renommer un fichier via Explorer et de taper/pour le nouveau nom. Windows affichera une boîte de message vous indiquant la liste des caractères illégaux.
A filename cannot contain any of the following characters:
\ / : * ? " < > |
Pour Windows, vous pouvez le vérifier à l'aide de 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
À partir du 18/04/2017, aucune liste simple de caractères et de noms de fichiers, noir ou blanc, n'est évidente parmi les réponses à ce sujet - et les réponses sont nombreuses.
La meilleure suggestion que je pouvais trouver était de laisser l'utilisateur nommer le fichier comme il l'entend. À l'aide d'un gestionnaire d'erreurs lorsque l'application tente de sauvegarder le fichier, interceptez les exceptions, supposez que le nom du fichier est à blâmer (évidemment après vous être assuré que le chemin de sauvegarde était également correct) et demandez à l'utilisateur un nouveau nom de fichier. Pour de meilleurs résultats, placez cette procédure de vérification dans une boucle qui se poursuit jusqu'à ce que l'utilisateur comprenne bien ou abandonne. A fonctionné mieux pour moi (au moins en VBA).
Sous Windows 10 (2019), les caractères suivants sont interdits par une erreur lorsque vous essayez de les saisir:
Un nom de fichier ne peut contenir aucun des caractères suivants:
\ / : * ? " < > |
Bien que les seuls caractères Unix illégaux puissent être / et NULL, vous devez toutefois prendre en compte l'interprétation de la ligne de commande.
Par exemple, s'il peut être légal de nommer un fichier 1>&2 ou 2>&1 sous Unix, les noms de fichier tels que celui-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 lorsqu’il tente d’y accéder à partir de la ligne de commande, le shell traduira $PATH en sa valeur de variable.
Lors de la création de raccourcis Internet dans Windows, pour créer le nom de fichier, il ignore les caractères non autorisés, à l’exception de la barre oblique qui est convertie en signe moins.