Какие символы безопасны в кроссплатформенных именах файлов для Linux, Windows и OS-X

В настоящее время я использую имя YYMMDD-NAME + PAGE для большинства своих файлов. В NAME пробелы преобразованы в подчеркивания.

Я хотел бы использовать формат даты ГГГГ-ММ-ДД , но Я не знаю, как отделить это от имени. - выглядел бы странно, если бы имя начиналось с числа. Если я использую _ , тогда он конфликтует с подчеркиванием, представляющим пробел.

Какие символы в именах файлов достаточно безопасны, которые здесь будут работать? Я использую Linux, но могу делиться файлами с другими людьми (Windows 7, Mac OS X).


Резюме:

  • Windows: все, кроме управляющих символов ASCII и /:*?"|
  • Linux, OS- X: все, кроме null или /

На всех платформах лучше избегать непечатаемых символов, таких как управляющие символы ASCII.

Windows

В Windows проводник Windows не позволяет использовать управляющие символы или /: *? " | Вы можете использовать пробелы. Если вы используете пробелы, вам часто придется заключать имя файла в кавычки при использовании из командной строки (но, насколько мне известно, приложения с графическим интерфейсом не затрагиваются). Файловая система Windows, такая как NTFS, по-видимому, хранит кодировку с именем файла, но UTF-16 является стандартным.

Некоторые части Windows чувствительны к регистру, другие — без учета регистра. В файловой системе Windows NTFS легко создать отдельные имена файлов, такие как «Ab» и «ab». Эти имена относятся к отдельным файлам, которые содержат отдельный отдельный контент. Однако, хотя в командной строке Windows оба файла будут перечислены с помощью dir , вы не сможете легко получить доступ к одному из них или управлять им с помощью таких команд, как type . См. Ниже.

Linux, OS-X

Только в Linux и OS-X / из печатного набора ASCII, я считаю, запрещен. Некоторые символы (метасимволы оболочки, такие как * ?! ) вызовут проблемы в командных строках и потребуют, чтобы имя файла было соответствующим образом заключено в кавычки или экранировано.

Файловые системы Linux, такие как ext2, ext3 не зависят от набора символов (я думаю, они просто рассматривают его более или менее как поток байтов — запрещены только нули и /). Это означает, что вы можете хранить имена файлов в кодировке UTF-8. Я считаю, что оболочка или другое приложение должны знать, какую кодировку использовать для правильного преобразования имени файла для отображения или обработки.

Заключение

Таким образом, вы, вероятно, могли бы безопасно использовать что-то вроде (если бы это было не так сложно набрать)


Чувствительность к регистру в Windows

  C> dir/BAbaBаBC> type AbbbC> type aBbbC> type аBunicode homograph  

Обратите внимание, что мы не можем ввести содержимое второго файла, команда Windows type просто возвращает вместо этого содержимое Ab. Третий файл также будет отличаться от aB в Linux.

(Windows 10 NTFS).


Хотя ответ RedGrittyBrick технически верен, безопасность — не единственная проблема: также важно удобство использования. Я думаю, что лучше спросить, «какие символы лучше использовать в имени файла».

Некоторые возможные рекомендации:

  • [0-9a-zA-Z_] — буквенно-цифровые символы и подчеркивание можно использовать всегда.
  • /: *? " | и нулевой байт проблематичны по крайней мере в одной системе, и их следует всегда избегать.
  • Пробелы используются в качестве разделителей аргументов во многих системах, поэтому по возможности следует избегать имен файлов с пробелами. Другие пробелы (например, табуляции) тем более.
  • Точки с запятой (;) используются для разделения команд во многих системах. Точки с запятой и запятые (,) используются для разделения аргументов командной строки в (некоторые версии?) командной строки Windows.
  • [] () ^ #% &! @: + = {} '~ и [`] все имеют особое значение во многих оболочках, и их раздражает работа, и т. следует избегать. Они также имеют тенденцию выглядеть ужасно в URL-адресах.
  • Начальные символы , которых следует избегать:
    • Многие программы командной строки используют дефис [-] для обозначения специальных аргументов.
    • * системы на базе nix используют точку [.] в качестве ведущего символа для скрытых файлов и каталогов.
  • Все, что не входит в набор ASCII , может вызвать проблемы в старых или более простых системах (например, в некоторых встроенные системы), и их следует использовать с осторожностью.

Это в основном оставляет вас с:

которые всегда безопасно и не раздражает в использовании (если вы начинаете имя файла с буквенно-цифрового) 🙂

23


Вы можете:

  1. заменить текущие символы подчеркивания на # (символ корректора вместо пробела)
  2. подчеркивание перед ‘разделом’ дата от имени файла (или второй дефис — легче набирать)

Alt-1. начальные буквы могут заменять пробелы: YYMMDD-HHMM-FileName.ext или YYMMDD-HHMM_FileName.ext

Минимальные символы для четкое отображение с автоматической сортировкой с добавлением заполненных нулей для января-сентября (и с 1-го по 9-е число).


К персонажам в основном обращались другие люди, хотя я отмечу дополнительный аспект, который следует учитывать. Во-первых, я обращаюсь к выбору ГГММДД, который имеет две проблемы..

Первая проблема с YYMMDD заключается в том, что он не работает с историческими данными. 1997 год будет намного позже 2035 года, а не раньше. Проблема в том, может зависеть от того, насколько широко вы хотите распространить формат.

Другая проблема с YYMMDD связана с зависимостью от календаря. Хотя григорианский календарь в настоящее время является самым популярным в мире, не все его используют или знают о дне, указанном в нем. К счастью, григорианский год общеизвестен и принят даже теми, кто использует разные годы, но номенклатура месяца/дня может быть бессмысленной. Для большей переносимости формат ГГГГДДД, где DDD — день в году, является более переносимым. Однако для тех из нас, кто пользуется григорианским календарем , это затруднительно, потому что мы обычно не знаем день года. Формат MMDD по-прежнему можно сортировать, даже если он ничего не значит для человека, который сам может создать дату, например 20221442 (год по григорианскому календарю и их месяц и день) или 20220047 (16 февраля по григорианскому календарю, 47-й день года), полагая, что они соответствуют вашему формату.

Продолжая тему о том, насколько широко будет использоваться формат, необходимо учитывать символы, доступные во всем мире. Короткое тире ‘-‘ доступно везде (?), Потому что это знак минус, используемый во всем мире. Подчеркивание — большая проблема, даже для тех, кто использует латинский алфавит. Обычно они могут добраться до этого тем или иным способом, но не на каждой клавиатуре. В некоторых алфавитах подчеркивание является символом или модификатором символа, поэтому возникает путаница. Во многих персидских языках знак подчеркивания читается как кашида. Во многих алфавитах для обозначения того, что мы используем подчеркивание, используется верхняя черта: что-то, что трудно достать на нашей клавиатуре. На большинстве клавиатур для технических специалистов имеется простой латинский алфавит (иногда сбоку от клавиши), поэтому они могут печатать буквы. Но не всегда подчеркивание.



Linux/Windows/Unix/… Имена файлов: какие символы разрешены? Какие из них неэкранированы?

Какие символы разрешены и какие из них необходимо экранировать в командной строке в разных операционных системах?


Есть обсуждение символов имени файла в статье Википедии об именах файлов.

Вы можете найти это эссе информативным: Исправление имен файлов Unix/Linux/POSIX.

В этой статье сравниваются OS X и Windows XP: X vs. XP: запрещенные символы в именах файлов (PDF, см. Стр. Примерно 64-66).

То, чего не должно быть в именах файлов за 1000 долларов, Алекс

Я не знаю, какие символы должны быть un — экранирование, но в Linux, вероятно, не рекомендуется экранировать символы, которые могут иметь особое значение, такие как «n» (новая строка), «t» (табуляция) и другие, но обычно это не проблема при файловых операциях. Возможно, вы имеете в виду «сбежавший», а не «не сбежавший». Наиболее распространены те, которые интерпретируются оболочкой, например, пробел, «>», «


В имени файла в * nix запрещены только символы NUL и / . В Windows действительно запрещены только NUL , : и , но многие приложения также ограничивают это предотвращение ? , * , + и % .

Ни в коем случае не нужно экранировать какие-либо символы в имени файла , за исключением случаев, когда это необходимо для того, чтобы их не интерпретировала оболочка.

2


Если вы создадите файл в Windows с помощью проводника, используя один из следующих символов, он будет жаловаться, что символы не разрешены:

  /: *?  " |  

Здесь хорошая ссылка:

Именование файлов, путей и пространств имен
http://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx

Далее Microsoft заявляет:

«… на настольных платформах на базе Windows недопустимые символы пути могут включать символы ASCII/Unicode от 1 до 31, а также кавычки («), меньше (), вертикальную черту (|), обратный пробел ( b), null ( 0) и табуляция ( t) «.

http://msdn.microsoft.com/en-us/library/system.io.path.getinvalidpathchars.aspx

2


В Linux и других системах, совместимых с POSIX, «/» зарезервирован как разделитель каталогов, а « 0» (символ NULL) обозначает конец строки. Все остальное разрешено.

1

Оцените статью
clickpad.ru
Добавить комментарий