Какие символы следует ограничивать в имени файла Unix?
Рассмотрим диалог Сохранить как с вводом произвольного текста, в котором пользователь вводит имя файла как свободный текст, а затем нажимает кнопку Сохранить. Затем программа проверяет имя файла и сохраняет файл, если имя допустимо.
Какие правила следует применять в файловой системе Unix при проверке, например:
- Имя не составит труда впоследствии манипулировать с точки зрения экранирования специальных символов и т. д.
- Правила не настолько строгие, что сохранение файла становится неудобным для пользователя.
Итак, каков набор символов минимум, который следует ограничить в имени файла Unix?
Ответы 7
Во-первых, вы описываете черный список. Ваш лучший вариант - белый список ваших персонажей, так как легче (с точки зрения пользователя) вставлять символы, а не убирать их.
С точки зрения того, что было бы хорошо в среде unix:
- а-я
- А-Я
- 0-9
- подчеркивание (
_) - тире (
-) - период (
.)
Должен охватывать ваши основы. Пробелы могут быть нормальными, но усложняют задачу. Пользователи Windows любят их, а unix / linux - нет. Так что в зависимости от вашей целевой аудитории выбирайте соответственно.
Есть основания утверждать, что любые символы, классифицированные как 'isalpha ()' в текущей локали, допустимы - это позволяет людям использовать символы с диакритическими знаками в именах. Однако это усложняет историю.
Я, например, буду рассматривать все, что вызывает акцентированные символы, как недружелюбное к пользователю
Что происходит с именами файлов на разных языках?
минимум - это косая черта ('/') и NULL ('\ 0')
Минимум /,; и | чтобы пользователь не запускал произвольные команды (при условии, что он не экранирован :))
Этот. Никакие символы кроме '/' не должны быть запрещены.
И ASCII NUL '\ 0', поскольку это означает конец имени файла: D
Это строгий ответ. Приложение должно быть закодировано таким образом, чтобы предполагалось, что пользователь не ограничен (поэтому при открытии файлов он должен принимать любое имя). Это не такой уж хороший ответ для сохранения (новых) файлов; разумно наложить некоторые ограничения на имена файлов.
@mouviciel: учитывая, что некоторые файловые системы, такие как ꜰᴀᴛ, поддерживают символ ɴᴜʟʟ. Что произойдет, если в середине имени файла присутствует символ.
@ user2284570: Не знаю. Держу пари, что это невозможно в контексте диалогового окна «Сохранить как ...».
@mouviciel: в случае, если имя файла было записано с другого ᴏꜱ, конечно.
Я бы добавил «и», поскольку они могут, по крайней мере, иногда приводить к неприятным ситуациям с несогласованными цитатами. () они тоже не нравятся оболочкам. : разделитель путей.
Позвольте пользователю ввести любое имя, которое он хочет. Искусственное ограничение диапазона символов будет только раздражать пользователей и не будет служить реальной цели.
Или, лучше: '$ (rm -fr $ HOME)' (без одинарных кавычек) в качестве имени файла? Рано или поздно это нанесет серьезный ущерб. Обратные кавычки и $ (...) особенно опасны, поскольку они «работают», когда имя файла указывается в кавычках, в отличие от большинства других специальных символов. Встроенные цитаты тоже сложны.
Это не проблема при сохранении имени файла. fopen () не заботится о ваших именах файлов. При использовании графической оболочки (например, konqueror) она не заботится о ваших именах файлов. Когда вы используете автозаполнение в оболочке, она не заботится о ваших именах файлов. Так каковы ваши точки зрения? :)
@Bombe, то, что может захотеть один пользователь, во многих случаях оттолкнет других пользователей, независимо от того, какой хаос он вносит в процесс разработки пользовательского интерфейса. Плохая идея.
Вот моя точка зрения: выбор странных имен ни к чему не приведет, если только ваше «что-нибудь» не написано плохо. Ни один из стандартных инструментов UNIX не написан плохо. Опять же: о чем вы?
Какой близорукий ответ от человека, которому действительно следует знать лучше. Ваш ответ даже не отвечал должным образом на исходный вопрос. Говорят The name will not be difficult to manipulate later in terms of escaping special characters, etc.. Здесь люди заметили, что есть довольно много символов, которые может присутствуют в допустимых именах файлов, но реально вызывают кучу проблем.
Не забывайте, что вы можете добавить точку (.) в начале, чтобы скрыть файлы и папки ... В противном случае я бы следовал соглашению об именах * NIX (из Википедии):
Большинство файловых систем UNIX
- Обработка регистра: сохранение регистра с учетом регистра
- Допустимый набор символов: любой.
- Зарезервированные символы:
/,null. - Максимальная длина: 255.
- Примечания: ведущий. указывает, что ls и файловые менеджеры по умолчанию не показать файл
Часто забывают: двоеточие (:) - не лучшая идея, так как обычно используется в таких вещах, как $ PATH, то есть в списке каталогов, в которых исполняемые файлы находятся «автоматически». Это может вызвать путаницу с именами каталогов DOS / Windows, где, конечно, двоеточие используется в именах дисков.
также ldd на linux может запутаться при поиске rpaths, если присутствуют двоеточия
Если у вас есть двоеточие в имени файла, и вы используете этот раздел в Windows и удаляете файл, это приведет к повреждению файловой системы. Однако это может быть решено с помощью инструмента Windows «Восстановить диск».
Хотя принятый ответ может быть правдой, я думаю, что есть преимущество в наличии некоторых ограничений, которые могут потенциально раздражать скрипты или другие вещи:
- косая черта (/)
- обратная косая черта (\)
- ПУСТО (\ 0)
- галочка (`)
- начинается с тире (-)
- звезда (*)
- трубы (|)
- точка с запятой (;)
- цитаты ("или")
- двоеточие (:)
(- возможно, пробел, хотя я не хочу это добавлять.)
Как видите, вам может быть лучше добавить в белый список, как предлагает @Gavin ...
Это довольно хороший список. Я бы также предложил исключить "!" хотя, который может использоваться для расширения истории при интерактивном вводе. Да, и начальные точки (скрытые) и «<» или «>» (перенаправление).
И имейте в виду, что вы все равно можете встретить пробелы, табуляции и символы новой строки в именах файлов в Unix. Ваш код не должен взорваться только из-за этого.
Кодировать FTW
Как указывает Бомба в своем ответе, ограничение ввода данных пользователем по крайней мере расстраивает, если не совсем раздражает. Хотя, как разработчики, мы должны предполагать, что любое взаимодействие с нашим кодом является вредоносным, и относиться к ним как к таковым.
Чтобы решить обе проблемы в практическом приложении, вместо того, чтобы вносить определенные символы в белый или черный список, мы просто не должны использовать вводимые пользователем данные в качестве имени файла.
Вместо этого используйте безопасное имя (шестнадцатеричные символы [a-f0-9] только для максимальной безопасности) нашего собственного изобретения, либо закодированный из пользовательского ввода (например, PHP bin2hex), либо случайно сгенерированный идентификатор (например, Uniqid PHP), который затем отображается каким-либо методом (возьмите ваш pick) к пользовательскому вводу.
Кодирование / декодирование можно выполнять на лету, не полагаясь на отображение, поэтому это практически идеальный вариант. Пользователю никогда не нужно знать, как называется файл В самом деле; до тех пор, пока они могут получить / установить файл, и его появляется будет называться так, как они хотят, все в выигрыше.
По этой методике пользователь может называть свой файл как угодно, только хакеры будут разочарованы люди, и ваша файловая система полюбит вас :-)
Отличный совет! Это тот же принцип, что и хранение имен как name, вместо того, чтобы пытаться применять first и last по отдельности (что делает меня так безумно). Или когда я сталкиваюсь с ограничениями любой на пароли, отличные от длины минимум. («Пробелы запрещены?!? По какой земной причине !?») Очевидно, что в одних ситуациях это более уместно, чем в других. Иногда вы используете имеют, чтобы пользователь мог указать фактическое имя файла по вполне веским причинам.
Новые строки - это неприятность. Запятые довольно безобидны. Двоеточие не повредит в Unix, но проблематично, если имя скопировано в Windows - или если «файл» - это каталог, который может потребоваться добавить в PATH.