Quelles raisons techniques existent pour ne pas utiliser de caractères d'espace dans les noms de fichiers ?

Les caractères d'espacement dans les noms de fichiers peuvent être un vrai casse-tête dans de nombreux contextes en ligne de commande et dans les scripts, où il faut faire attention à s'assurer qu'ils sont correctement échappés afin de ne pas être pris pour des séparateurs par les commandes que vous exécutez.

Il est juste plus sûr de ne pas les avoir là, même si vous êtes sûr que le fichier/répertoire/quoi que ce soit ne sera jamais utilisé dans un tel contexte.

Ça, et les vieilles habitudes ont la vie dure.

En plus des autres réponses sur la ligne de commande et les vieilles habitudes, il existe également de nombreux protocoles réseau qui nécessitent une attention particulière lors de la manipulation de noms de fichiers contenant des espaces.

(Si vous avez déjà essayé de télécharger "Product List.pdf" à partir d'un site web et que vous vous retrouvez avec un fichier appelé simplement "Product", vous avez été mordu par cela, car le programmeur à l'autre bout ne connaissait pas ou ne pouvait pas comprendre les règles de cotation pour l'en-tête Content-Disposition http.)

Beaucoup des raisons sont historiques. Cela ne signifie pas qu'elles n'ont pas de sens aujourd'hui.

Problèmes de portabilité

Lorsque vous donnez un nom à un fichier, vous devez également considérer comment d'autres systèmes (de fichiers) traiteront ce nom de fichier. Un caractère dans un nom de fichier peut convenir à votre système, mais peut poser problème à un autre système.

Ainsi, tant qu'il y avait la moindre possibilité que vous souhaitiez pouvoir accéder facilement au fichier à partir d'un ancien système, vous choisiriez uniquement un caractère sûr. Cela peut inclure le démarrage dans un ancien système de récupération que vous avez conservé ou la crainte que les versions récentes de Windows soient encore d'une certaine manière basées sur MS-DOS.

Longueur

Un système de fichiers peut limiter la longueur d'un fichier. C'était encore plus sérieux à l'époque où MS-DOS était limité à des noms de fichiers 8.3. Ainsi, en laissant de côté les espaces, vous pouviez mettre plus de caractères significatifs dans le nom.

Divers autres systèmes de fichiers ont également défini des limites strictes sur la longueur de leur nom de fichier. Wikipedia propose un tableau dans l'article sur la comparaison des systèmes de fichiers pour ceux qui veulent les détails.

Caractères réservés

MS-DOS a également défini le caractère espace comme un caractère réservé. Cela est dû au fait que le caractère espace était utilisé pour le remplissage dans la FAT. De plus, MS-DOS ne prévoyait pas de système d'échappement dans l'interpréteur de commandes.

Interprétation de la ligne de commande

La plupart des lignes de commandes que je connais utilisent le caractère espace comme délimiteur de paramètres. En négligeant d'échapper correctement un nom de fichier, cela peut avoir des conséquences désastreuses car des parties du nom de fichier peuvent être interprétées comme des paramètres de l'application que vous vouliez appeler.

Considérez la différence entre

rm foo bar

et

rm "foo bar"

L'article WikiPedia lié ci-dessus souligne même l'ambiguïté introduite par le fait de ne pas échapper correctement une commande :

L'ambiguïté peut être évitée soit en interdisant les espaces imbriqués dans les noms de fichiers et de répertoires (par exemple, en les remplaçant par des traits de soulignement '_'), soit, si pris en charge par l'interpréteur de commandes et les programmes prenant ces paramètres comme arguments, en encadrant un nom contenant des espaces entre des guillemets ou en utilisant un caractère d'échappement avant l'espace, généralement un antislash ('\'). Par exemple

Chemin long/Nom de programme long Paramètre un Paramètre deux ...

est ambigu (le "nom de programme" fait-il partie du nom du programme ou de deux paramètres ?) ; cependant

Chemin_long/Nom_de_programme_long Paramètre_un Paramètre_deux ...,
"Chemin long/Nom de programme long" "Paramètre un" "Paramètre deux" ...

et Long\ chemin/Long\ nom\ de\ programme Paramètre\ un Paramètre\ deux ...

ne sont pas ambigus.

Uniform Resource Locators (URL)

Lorsque vous essayez de décrire l'emplacement d'un fichier à l'aide d'une URL, les espaces doivent être échappés.

Les caractères peuvent être dangereux pour diverses raisons. Le caractère espace est dangereux car les espaces significatifs peuvent disparaître et des espaces insignifiants peuvent être introduits lors de la transcription ou de la saisie des URL ou soumis au traitement de programmes de traitement de texte.

Source : RFC1738

Ainsi, un espace doit être remplacé par un %20 à la place. Cela rend la partie du nom de fichier de l'URL moins lisible et incite donc les gens à l'éviter en premier lieu.

Les espaces sont encodés ou convertis en %20 dans les noms de fichiers sur le web, ce qui peut rendre la gestion des ressources d'un site plus difficile.

Avoir Image 1.png et Image%201.png est source de confusion. Il est plus facile d'utiliser Image001.png à la place.

Cela relève vraiment de la même catégorie que les séquences d'échappement pour la ligne de commande.

Parfois, les espaces peuvent poser un problème lorsqu'on travaille en ligne de commande, ou lorsque l'on utilise des systèmes d'exploitation plus anciens, ou lors de l'écriture de programmes qui seront compilés sur différents systèmes d'exploitation, ou lorsque ... il existe de nombreuses raisons qui peuvent poser problème, et je ne pense pas vraiment que ce soit si difficile d'écrire le fichier comme : fichier-sans-espaces.txt ou fichier_sans_espaces.txt. Je préfère le tiret bas car le trait d'union peut parfois devenir invisible lorsqu'on travaille avec, par exemple, une police soulignée.

Mais surtout, c'est une question d'habitude de l'ancienne époque. Ce dont je ne pense pas qu'il y ait assez de raisons pro pour l'abandonner.

Une note supplémentaire, peut-être pas liée, mais néanmoins je vais la mettre ici. Les personnes qui nomment leurs fichiers avec des espaces n'y réfléchissent généralement pas beaucoup ; celles qui ne le font pas savent souvent un peu pourquoi il est bon de les éviter dans les noms de fichiers.
Et, nous pouvons tous être d'accord, il n'y a rien de pire qu'un fichier nommé "Cher Monsieur ou Madame, je vous écris cette lettre pour vous informer de yo.doc".

Et ce ne sont pas seulement les espaces - la longueur du nom du fichier compte aussi, et à mon humble avis, il ne devrait pas dépasser, disons, 30 caractères. Car les longs noms de fichiers avec des espaces à l'intérieur sont également une bénédiction lors de l'enregistrement de CD, de DVD et autres qui doivent être lus sous des systèmes d'exploitation plus anciens, et entre les plates-formes Win et *nix.