web-dev-qa-db-fra.com

Quels caractères doivent être limités à partir d'un nom de fichier Unix?

Considérez une boîte de dialogue Enregistrer sous avec une entrée de texte libre dans laquelle l'utilisateur entre un nom de fichier sous forme de texte libre, puis clique sur un bouton Enregistrer. Le logiciel valide ensuite le nom du fichier et enregistre le fichier si le nom est valide.

Sur un système de fichiers Unix, quelles règles doivent être appliquées dans la validation de telle sorte que:

  • Le nom ne sera pas difficile à manipuler plus tard pour échapper aux caractères spéciaux, etc.
  • Les règles ne sont pas si restrictives que l'enregistrement d'un fichier devient non convivial.

Donc, fondamentalement, quel est le jeu de caractères minimum qui devrait être restreint à partir d'un nom de fichier Unix?

61
barrymc

Les minimum sont des barres obliques ('/') et NULL ('\ 0')

52
mouviciel

Premièrement, ce que vous décrivez est liste noire . Votre meilleure option est de liste blanche vos personnages, car il est plus facile (du point de vue de l'utilisateur) d'insérer des caractères plutôt que de les retirer.

En termes de ce qui serait bien dans un environnement Unix:

  • a-z
  • A-Z
  • 0-9
  • souligner (_)
  • tiret (-)
  • période (.)

Devrait couvrir vos bases. Les espaces peuvent être corrects, mais compliquent les choses. Les utilisateurs de Windows les adorent, pas UNIX/Linux. Donc, en fonction de votre public cible, choisissez en conséquence.

32
Gavin Miller

Souvent oublié: le signe deux-points (:) n'est pas une bonne idée, car il est couramment utilisé dans des trucs comme $ PATH, c'est-à-dire la liste des répertoires où les exécutables sont trouvés "automatiquement". Cela peut entraîner une confusion avec les noms de répertoire DOS/Windows, où bien sûr les deux points sont utilisés dans les noms de lecteur.

18
unwind

Bien que la réponse acceptée puisse avoir la vérité, je pense qu'il y a un avantage à avoir des restrictions qui pourraient être ennuyeuses pour les scripts ou d'autres choses:

  • barre oblique (/)
  • barre oblique inverse (\)
  • NULL (\ 0)
  • cochez (`)
  • commence par un tiret (-)
  • étoile (*)
  • tuyaux (|)
  • point-virgule (;)
  • citations ("ou ')
  • deux points (:)

(- peut-être de l'espace, même si j'hésite à ajouter cela.)

Comme vous pouvez le voir, vous pourriez être mieux placé sur la liste blanche comme le suggère @Gavin ...

13
ThinkBonobo

N'oubliez pas que vous pouvez ajouter un point (.) au début pour cacher les fichiers et dossiers ... Sinon, je suivrais une convention de nom * NIX (de Wikipedia):

La plupart des systèmes de fichiers UNIX

  • Gestion des cas: préservation de la casse
  • Jeu de caractères autorisé: n'importe lequel.
  • Caractères réservés: /, null.
  • Longueur max: 255.
  • Notes: Un leader. indique que ls et les gestionnaires de fichiers ne montreront pas par défaut le fichier

Lien vers un article wikipedia sur les noms de fichiers

10
Tobias Wärre

Encoder FTW

Comme Bombe le souligne dans sa réponse, restreindre la saisie des utilisateurs est au moins frustrant sinon carrément ennuyeux. Cependant, en tant que développeurs, nous devons supposer que chaque interaction avec notre code est malveillante et les traiter comme tels.

Pour résoudre les deux problèmes dans une application pratique, plutôt que de lister certains caractères en blanc ou en noir, nous ne devons tout simplement pas utiliser l'entrée utilisateur comme nom de fichier.

Utilisez plutôt un nom sûr (caractères hexadécimaux [a-f0-9] uniquement pour la sécurité ultime) de notre propre conception, soit encodé à partir de l'entrée utilisateur (par exemple bin2hex de PHP ), ou un ID généré aléatoirement (par exemple niqid de PHP ) qui est ensuite mappé par une méthode (faites votre choix) à l'entrée utilisateur.

L'encodage/décodage peut être effectué à la volée sans recours à la cartographie, il est donc pratiquement idéal. L'utilisateur n'a jamais besoin de savoir quel est le fichier vraiment appelé; tant qu'ils peuvent obtenir/définir le fichier, et qu'il apparaît pour être appelé ce qu'ils voulaient, tout le monde est gagnant.

Par cette méthodologie, l'utilisateur peut appeler son fichier comme bon lui semble, les hackers seront les seuls personnes frustrés, et votre système de fichiers vous aimera :-)

7
Fred Gandt