Многие причины исторические. Это не значит, что они не имеют смысла сегодня.
Проблемы в мобильности
При именовании файла вам также может потребоваться учитывать, как другие (файловые) системы будут обращаться с этим именем файла. Символ в имени файла может подойти для вашей системы, но это может быть проблемой для другой системы.
Таким образом, до тех пор, пока существует малейшая вероятность того, что вы захотите легко получить доступ к файлу из старой системы, вы выбираете только безопасный символ. Это может включать загрузку старой системы восстановления, которую вы держали, или страх, что последние версии Windows по-прежнему основаны на MS-DOS.
длина
Файловая система может ограничивать длину файла. Это было еще серьезнее в те дни, когда MS-DOS ограничивался 8,3 именами файлов. Таким образом, оставляя пробелы, вы можете добавить в имя более значимые символы.
Несколько других файловых систем также определили строгие ограничения на длину имени файла. В статье в Википедии есть таблица сравнения файловых систем для тех, кому нужны подробности.
Зарезервированные персонажи
MS-DOS также определил символ пробела как зарезервированный символ. Это связано с тем, что символ пробела использовался для заполнения в FAT. Кроме того, MS-DOS не обеспечивала экранирующую систему в оболочке.
Интерпретация командной строки
Большинство командных строк, которые мне известны, используют символ пробела в качестве разделителя параметров. Если пренебрегать правильным экранированием имени файла, это может привести к ужасным последствиям, поскольку части имени файла могут быть интерпретированы как параметры приложения, которое вы хотите вызвать.
Рассмотрим разницу между
rm foo bar
а также
rm "foo bar"
В статье WikiPedia, указанной выше, даже указывается на двусмысленность, возникшую из-за отсутствия правильного экранирования команды:
Неоднозначность может быть предотвращена либо путем запрета встроенных пробелов в именах файлов и каталогов в первую очередь (например, путем замены их символами подчеркивания '_'), либо, если поддерживается интерпретатором командной строки и программами, принимающими эти параметры как аргументы, заключая в себе имя со встроенными пробелами между символами кавычек или используя escape-символ перед пробелом, обычно с обратной косой чертой ('\'). Например
Long path/Long program name Parameter one Parameter two ...
является неоднозначным (является ли "имя программы" частью имени программы или двумя параметрами?); тем не мение
Long_path/Long_program_name Parameter_one Parameter_two ...,
LongPath/LongProgramName ParameterOne ParameterTwo ...,
"Long path/Long program name" "Parameter one" "Parameter two" ...
и Long\ path/Long\ program\ name Параметр \ один Параметр \ два ...
не являются двусмысленными.
Унифицированные указатели ресурсов (URL)
При попытке описать местоположение файла, используя URL, пробелы необходимо экранировать.
Персонажи могут быть небезопасными по ряду причин. Символ пробела небезопасен, потому что значительные пробелы могут исчезнуть, а незначительные пробелы могут быть введены, когда URL-адреса транскрибируются, набираются или подвергаются обработке программ обработки текста.
Источник: RFC1738
Таким образом, пробел должен быть заменен на %20 вместо этого. Это делает часть имени файла в URL менее читаемой и, таким образом, заставляет людей избегать его.
