Один мой знакомый сегодня выразил раздражение по поводу тех из нас, кто, например, не использует пробелы в именах файлов, NamingThingsLikeThis.txtнесмотря на то, что большинство современных операционных систем поддерживают пробелы в именах файлов.
Здесьтехнические причинычто все еще часто можно увидеть имена файлов без (соответствующих) пробелов? Если да, то каковы эти технические причины, по которым пробелы в именах файлов избегаются или не приветствуются, и в каких обстоятельствах они уместны?
Самая очевидная причина, которую я смог придумать, и почему я обычно избегаю этого, — это дополнительные кавычки, необходимые в командной строке при работе с такими файлами. Есть ли какие-либо другие существенные технические причины?
решение1
Пробелы в именах файлов могут стать настоящей головной болью во многих контекстах командной строки и в скриптах, где вам нужно быть внимательным и убедиться, что они правильно экранированы, чтобы не выглядеть как разделители для команд, которые вы запускаете.
Просто безопаснее не иметь их там, даже если вы уверены, что файл/каталог/что-либо еще никогда не будет использоваться в таком контексте.
А старые привычки трудно искоренить.
решение2
Помимо других ответов о командной строке и старых привычках, существует также много сетевых протоколов, которые требуют особой осторожности при работе с именами файлов, содержащими пробелы.
(Если вы когда-либо пытались загрузить «Product List.pdf» с веб-сайта и в итоге получали файл с названием «Product», то вас это огорчало, поскольку программист на другом конце не знал или не мог разобраться в правилах цитирования для заголовка http Content-Disposition.)
решение3
Многие причины исторические. Это не значит, что они не имеют смысла сегодня.
Проблемы с переносимостью
При именовании файла вам, возможно, также придется учитывать, как другие (файловые) системы будут обрабатывать это имя файла. Символ в имени файла может быть приемлемым для вашей системы, но он может быть проблемой для другой системы.
Итак, если есть хоть малейшая вероятность того, что вам захочется легко получить доступ к файлу из старой системы, вы бы выбрали толькобезопасныйхарактер. Это может включать загрузку старой системы восстановления, которую вы сохранили, или страх, что последние версии Windows все еще каким-то образом основаны на MS-DOS.
Длина
Файловая система может ограничивать длину файла. Это было еще более серьезно в те дни, когда MS-DOS был ограничен8.3 имена файлов. Таким образом, исключение пробелов позволило вставить в имя больше значимых символов.
Несколько других файловых систем также установили строгие ограничения на длину имени файла. В Википедии есть таблицастатья о сравнении файловых системдля тех, кому нужны подробности.
Зарезервированные символы
MS-DOS также определила символ пробела как зарезервированный символ. Это связано с тем, что символ пробела использовался длязаполнение в FAT. Кроме того, MS-DOS не предусматривала систему экранирования в оболочке.
Интерпретация командной строки
Большинство командных строк, о которых я знаю, используютпробел как разделитель параметров. Если не экранировать имя файла надлежащим образом, это может иметь плачевные последствия, поскольку части имени файла могут быть интерпретированы как параметры приложения, которое вы хотели вызвать.
Подумайте о разнице между
rm foo bar
и
rm "foo bar"
Статья в Википедии, ссылка на которую приведена выше, даже указывает на неоднозначность, возникающую из-за отсутствия правильного экранирования команды:
Неоднозначность можно предотвратить, либо запретив в первую очередь встроенные пробелы в именах файлов и каталогов (например, заменив их подчеркиваниями '_'), либо, если это поддерживается интерпретатором командной строки и программами, принимающими эти параметры в качестве аргументов, заключив имя во встроенные пробелы между символами кавычек или используя экранирующий символ перед пробелом, обычно обратную косую черту ('\'). Например
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\ путь/Long\ программа\ имя Параметр\ один Параметр\ два ...
не являются двусмысленными.
Единые указатели ресурсов (URL)
При попытке описать местоположение файла с помощью URL-адреса необходимо экранировать пробелы.
Символы могут быть небезопасными по ряду причин. Символ пробела небезопасен, поскольку значимые пробелы могут исчезать, а незначимые пробелы могут вводиться при транскрибировании URL-адресов, наборе или обработке текстовыми процессорами.
Источник:RFC1738
Таким образом, пробел должен быть заменен на a %20. Это делает часть имени файла в URL-адресе менее читаемой и, таким образом, заставляет людей избегать его в первую очередь.
решение4
Иногда пробелы могут представлять проблему при работе в командной строке, или при использовании старых ОС, или при написании программ, которые будут компилироваться в других ОС, или когда... существует множество причин, которые могут представлять проблему, и я не думаю, что будет так уж сложно записать файл следующим образом:файл-без-пробелов.txtилифайл_без_пробелов.txt. Я предпочитаю дефис, потому что подчеркивание иногда может стать невидимым, например, при работе с подчеркнутым шрифтом.
Но в основном это дело привычки от старости. Которых, как мне кажется, не так уж и много.пропричины отказаться.
Дополнительное замечание, возможно, не по теме, но тем не менее я его здесь размещу. Люди, которые называют свои файлы пробелами, обычно не придают этому большого значения; те, кто не знает, часто немного знают, почему их лучше избегать в именах файлов.
И, мы все можем согласиться, нет ничего хуже файла, который называется "Уважаемый господин или госпожа, я пишу вам это письмо, чтобы сообщить вам о yo.doc".
Не только пробелы - длина файла тоже имеет значение, и IMHO, она не должна быть длиннее, скажем, 30 символов. Длинные имена файлов с пробелами внутри также являются благословением при записи CD, DVD и подобных им, которые должны читаться в старых ОС, а также между платформами Win и *nix.