Quelles sont les raisons techniques pour ne pas utiliser d'espaces dans les noms de fichiers?

Quelqu'un de ma connaissance a-t-il exprimé aujourd'hui une irritation à l'égard de ceux d'entre nous qui ont tendance à ne pas utiliser les espaces dans nos noms de fichiers, par exemple NamingThingsLikeThis.txt, malgré la plupart des systèmes d'exploitation modernes prenant en charge les espaces dans les noms de fichiers.

Y a-t-il des raisons techniques pour lesquelles il est toujours courant de voir des noms de fichiers sans espaces (appropriés)? Si tel est le cas, quelles sont les raisons techniques pour lesquelles les espaces dans les noms de fichiers sont évités ou découragés, et dans quelles circonstances sont-elles pertinentes?

La raison la plus évidente à laquelle je puisse penser, et pourquoi je l’évite généralement, est les guillemets supplémentaires requis sur la ligne de commande pour traiter de tels fichiers. Y a-t-il d'autres raisons techniques importantes?

Les caractères d'espacement dans les noms de fichiers peuvent être une douleur royale dans la proverbiale dans de nombreux contextes sur la ligne de commande et dans les scripts, où vous devez faire attention à vous assurer qu'ils sont correctement échappés afin de ne pas ressembler à des séparateurs des commandes que vous êtes fonctionnement.

Il est juste plus prudent 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.

Outre les autres réponses concernant la ligne de commande et les anciennes habitudes, il existe également de nombreux protocoles réseau qui nécessitent une attention particulière lors de l'utilisation 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 êtes retrouvé avec un fichier simplement appelé "Product", vous avez été piqué par ceci, parce que le programmeur de l'autre côté ne savait ni ne pouvait ne pas comprendre les règles de citations pour l'en-tête http Content-Disposition.)

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

Problèmes de portabilité

Lorsque vous nommez un fichier, vous devrez peut-être é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 pour un autre système.

Ainsi, dans la mesure où il est tout à fait possible que vous souhaitiez pouvoir accéder facilement au fichier à partir d'un système ancien, vous ne choisissez que des caractères sûrs . 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 reposent encore sur MS-DOS.

Longueur

Un système de fichiers peut limiter la longueur d'un fichier. Cela était encore plus grave à l'époque où MS-DOS était limité à 8,3 noms de fichiers . Ainsi, laisser des espaces vous a permis de mettre des noms plus significatifs dans le nom.

Plusieurs autres systèmes de fichiers ont également défini des limites strictes pour la longueur des noms de fichiers. L'article de Wikipédia contient une table sur la comparaison du système de fichiers pour ceux qui veulent des détails

Caractères réservés

MS-DOS a également défini le caractère d'espace en tant que caractère réservé. Cela est dû au fait que le caractère espace a été utilisé pour le remplissage dans la FAT . En outre, MS-DOS n'a pas fourni de système d'échappement dans le shell.

Interprétation en ligne de commande

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

Considérez la différence entre

rm foo bar

et

rm "foo bar"

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

On peut éviter l’ambiguïté en interdisant d’abord les espaces incorporés dans les noms de fichiers et de répertoires (par exemple, en les remplaçant par des tirets bas "_"), ou, si pris en charge par l’interpréteur de ligne de commande et les programmes prenant ces paramètres comme arguments, en insérant un nom avec des espaces incorporés entre guillemets ou en utilisant un caractère d'échappement avant l'espace, généralement une barre oblique inversée ('\'). Par exemple

Long path/Long program name Parameter one Parameter two ...

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

Long_path/Long_program_name Parameter_one Parameter_two ...,
LongPath/LongProgramName ParameterOne ParameterTwo ...,
"Long path/Long program name" "Parameter one" "Parameter two" ...

et Long \ path / Long \ program \ name Parameter \ one Parameter \ two ...

ne sont pas ambigus.

Uniform Resource Locators (URL)

Lorsque vous essayez de décrire l'emplacement d'un fichier à l'aide d'une URL, vous devez échapper des espaces.

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

Source: RFC1738

Ainsi, un espace doit être remplacé par un %20. Cela rend le nom de fichier de l'URL moins lisible et, par conséquent, empêche les gens de l'éviter en premier lieu.

Les espaces sont codés ou convertis %20en noms de fichiers sur le Web, ce qui peut compliquer la gestion des actifs d'un site.

Avoir Image 1.pnget Image%201.pngc'est déroutant. C'est plus facile à utiliser à la Image001.pngplace.

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

Parfois, les espaces peuvent présenter un problème lorsque vous utilisez la ligne de commande, lorsque vous utilisez des systèmes d'exploitation plus anciens, ou lorsque vous écrivez des programmes qui seront compilés sur différents systèmes d'exploitation, ou lorsque ... il y a de nombreuses raisons qui peuvent présenter des problèmes, et je ne le fais pas. t vraiment l'impression qu'il est si difficile d'écrire le fichier comme suit : file-without-blanks.txt ou file_without_blanks.txt . Je préfère le masque car le trait de soulignement peut parfois devenir invisible lorsqu'il s'agit, par exemple, d'une police soulignée.

Mais surtout, il s’agit d’une habitude de la vieillesse. Ce que je ne pense pas, il y a assez de raisons pro pour abandonner.

Une note supplémentaire, peut-être pas liée, mais je vais quand même la mettre ici. Les personnes qui nomment leurs fichiers avec des espaces ne pensent généralement pas beaucoup à cela; ceux qui ne savent pas souvent pourquoi il est bon de les éviter dans les noms de fichiers.
Et, nous pouvons tous convenir, il n’ya rien de pire qu'un fichier qui porte les noms "Cher Monsieur ou Madame, je vous écris cette lettre pour vous informer de votre décision".

Pas seulement les espaces - la longueur du fichier compte également pour quelque chose, et à mon humble avis, elle ne devrait pas dépasser 30 caractères. Les noms de fichier longs avec des espaces sont également une bénédiction lors de l’enregistrement de CD, DVD, etc., qui doivent être lus sous des systèmes d’exploitation plus anciens, ainsi qu’entre des présentations Win et * nix.