Какие символы запрещены в именах каталогов Windows и Linux?

Ответ 1

"Полное руководство" запрещенных имен файлов не будет работать в Windows, поскольку оно хранит имена файлов, а также символы. Да, персонажи вроде * " ?, а другие запрещены, но существует бесконечное количество имен, состоящих только из допустимых символов, которые запрещены. Например, пробелы и точки являются действительными именами имен файлов, но имена, состоящие только из этих символов, запрещены.

В Windows не проводится различие между строчными и строчными символами, поэтому вы не можете создать папку с именем A, если один из них с именем A уже существует. Хуже, по-видимому, такие имена, как PRN и CON, и многие другие, зарезервированы и не разрешены. Windows также имеет несколько ограничений длины; имя файла, действительное в одной папке, может стать недействительным, если оно перемещено в другую папку. Правила для именование файлов и папок находится на MSDN.

Вы не можете, в общем, использовать созданный пользователем текст для создания имен каталога Windows. Если вы хотите, чтобы пользователи написали что-либо, что они хотят, вы должны создать безопасные имена, такие как A, AB, A2 и др., Хранить созданные пользователем имена и их эквиваленты путей в файле данных приложения и выполните сопоставление маршрутов в вашем приложении.

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

Ответ 2

Пусть будет проще и ответь сначала на вопрос.

1. Запрещенные печатные символы ASCII:

   • Linux/Unix:

     / (forward slash)
     

   • Окна:

     < (less than)
     > (greater than)
     : (colon - sometimes works, but is actually NTFS Alternate Data Streams)
     " (double quote)
     / (forward slash)
     \ (backslash)
     | (vertical bar or pipe)
     ? (question mark)
     * (asterisk)
     

2. Непечатные символы

   Если ваши данные поступают из источника, который разрешает непечатные символы, есть еще что проверить.

   • Linux/Unix:

     0 (NULL byte)
     

   • Окна:

     0-31 (ASCII control characters)
     

   Примечание. Хотя в файловых системах Linux/Unix разрешено создавать файлы с управляющими символами в имени файла, пользователям может показаться кошмарным иметь дело с такими файлами.

3. Зарезервированные имена файлов

   Следующие имена файлов зарезервированы:

   • Окна:

     CON, PRN, AUX, NUL 
     COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
     LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
     

     (как самостоятельно, так и с произвольными расширениями файлов, например LPT1.txt).

4. Другие правила

   • Окна:

     Имена файлов не могут заканчиваться пробелом или точкой.

Ответ 3

В Linux и других Unix-системах есть только два символа, которые не могут появляться в имени файла или каталога, и это NUL '\0' и косая черта '/'. Разумеется, косая черта может появляться в имени пути, разделяющем компоненты каталога.

Слух ¹ гласит, что у Стивена Борна (известной как 'shell') был каталог, содержащий 254 файла, по одному на каждую букву (код символа), которая может появляться в имени файла (исключая /, '\0'; имя . Было текущий каталог, конечно). Он использовался для тестирования оболочки Bourne и регулярно наносил ущерб неосторожным программам, таким как программы резервного копирования.

Другие люди рассмотрели правила Windows.

Обратите внимание, что MacOS X имеет регистронезависимую файловую систему.

Когда Стив Борн писал свою оболочку Unix (известную как оболочка Борна), он создал каталог из 254 файлов с односимвольными именами, по одному на каждое значение байта, кроме '\0' и косой черты, двух символов, которые не может появиться в именах файлов Unix. Он использовал этот каталог для всевозможных тестов сопоставления с образцом и токенизации. (Тестовый каталог, конечно, был создан программой.) В течение многих лет этот каталог был бичем программ для обхода файловых деревьев; это проверило их на разрушение.

^{Обратите внимание, что каталог должен содержать записи .и .., так что, возможно, было 253 файла (и 2 каталога) или 255 записей имен, а не 254 файла.Это не влияет на эффективность анекдота или тщательное тестирование, которое он описывает.}

Ответ 4

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

Это не решает проблему зарезервированных имен в целевой файловой системе, но с белым списком легче снизить риски в источнике.

В этом духе это ряд символов, которые можно считать безопасными:

• Буквы (az AZ) - также символы Unicode, если это необходимо
• Цифры (0-9)
• Нижнее подчеркивание (_)
• Дефис (-)
• Космос
• Точка (.)

И любые дополнительные безопасные символы, которые вы хотите разрешить. Помимо этого, вам просто нужно применить некоторые дополнительные правила, касающиеся пробелов и точек. Обычно этого достаточно:

• Имя должно содержать хотя бы одну букву или цифру (чтобы избежать только точек/пробелов)
• Имя должно начинаться с буквы или цифры (чтобы избежать начальных точек/пробелов)
• Имя не может заканчиваться точкой или пробелом (просто обрезать их, если они есть, как в Проводнике)

Это уже позволяет довольно сложные и бессмысленные имена. Например, эти имена будут возможны с этими правилами, и будут действительными именами файлов в Windows/Linux:

• A...........ext
• B -.-.ext

По сути, даже с таким количеством символов в белом списке вы все равно должны решить, что на самом деле имеет смысл, и соответствующим образом проверить/скорректировать имя. В одном из моих приложений я использовал те же правила, что и выше, но удалил все дублирующие точки и пробелы.

Ответ 5

Хорошо, если только в исследовательских целях, то лучше всего посмотреть на эту запись в Википедии по именам файлов.

Если вы хотите написать портативную функцию для проверки ввода пользователя и создания имен файлов на основе этого, короткий ответ не. Взгляните на переносимый модуль, например Perl File:: Spec, чтобы взглянуть на все прыжки, необходимые для выполнения такой "простой" задачи.

Ответ 6

Легкий способ заставить Windows сказать вам ответ - попытаться переименовать файл через Explorer и ввести/для нового имени. В Windows появится окно с сообщением о списке недопустимых символов.

A filename cannot contain any of the following characters:
    \ / : * ? " < > | 

https://support.microsoft.com/en-us/kb/177506

Ответ 7

Для Windows вы можете проверить его с помощью PowerShell

$PathInvalidChars = [System.IO.Path]::GetInvalidPathChars() #36 chars

Для отображения кодов UTF-8 вы можете конвертировать

$enc = [system.Text.Encoding]::UTF8
$PathInvalidChars | foreach { $enc.GetBytes($_) }

$FileNameInvalidChars = [System.IO.Path]::GetInvalidFileNameChars() #41 chars

$FileOnlyInvalidChars = @(':', '*', '?', '\', '/') #5 chars - as a difference

Ответ 8

По состоянию на 18/04/2017 среди простых ответов на эту тему нет простого черного или белого списка символов и имен файлов - и ответов много.

Лучшее предложение, которое я мог придумать, состояло в том, чтобы позволить пользователю называть файл так, как ему нравится. Используя обработчик ошибок, когда приложение пытается сохранить файл, перехватите все исключения, предположите, что виновато имя файла (очевидно, после того, как убедитесь, что путь сохранения тоже был в порядке), и запросите у пользователя новое имя файла. Для достижения наилучших результатов поместите эту процедуру проверки в цикл, который продолжается до тех пор, пока пользователь не поймет это правильно или не сдастся. Лучше всего сработало для меня (по крайней мере, в VBA).

Ответ 9

Хотя единственными незаконными символами Unix могут быть / и NULL, хотя необходимо учитывать некоторое отношение к интерпретации командной строки.

Например, хотя может быть законным назвать файл 1>&2 или 2>&1 в Unix, имена файлов, такие как это, могут быть неверно истолкованы при использовании в командной строке.

Аналогичным образом можно было бы назвать файл $PATH, но при попытке получить к нему доступ из командной строки оболочка переведет $PATH в значение переменной.

Ответ 10

В Windows 10 (2019) следующие символы запрещены из-за ошибки при попытке их ввести:

Имя файла не может содержать следующие символы:

\ / : * ? " < > |

Ответ 11

При создании интернет-ярлыков в Windows, чтобы создать имя файла, он пропускает недопустимые символы, кроме косой черты, которая преобразуется в минус.

Ответ 12

В оболочках Unix вы можете цитировать почти каждый символ в одинарных кавычках '. Кроме самой одиночной кавычки, и вы не можете выразить управляющие символы, потому что \ не расширяется. Доступ к одиночной кассе изнутри указанной строки возможен, потому что вы можете объединить строки с одинарными и двойными кавычками, например 'I'"'"'m', которые можно использовать для доступа к файлу с именем "I'm" (здесь также возможна двойная цитата).

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

Если вы хотите быть красивой, не используйте ни один из символов, которые оболочка и типичные команды используют в качестве синтаксических элементов, иногда зависимых от положения, например, вы все равно можете использовать -, но не как первый символ; то же самое с ., вы можете использовать его как первый символ только тогда, когда вы имеете в виду его ( "скрытый файл" ). Когда вы имеете в виду, ваши имена файлов - это escape-последовательности VT100;-), так что ls искажает вывод.

Ответ 13

У меня была такая же потребность, и я искал рекомендации или стандартные ссылки и наткнулся на эту тему. Мой текущий черный список символов, которых следует избегать в именах файлов и каталогов:

$CharactersInvalidForFileName = {
    "pound" -> "#",
    "left angle bracket" -> "<",
    "dollar sign" -> "$",
    "plus sign" -> "+",
    "percent" -> "%",
    "right angle bracket" -> ">",
    "exclamation point" -> "!",
    "backtick" -> "`",
    "ampersand" -> "&",
    "asterisk" -> "*",
    "single quotes" -> """,
    "pipe" -> "|",
    "left bracket" -> "{",
    "question mark" -> "?",
    "double quotes" -> """,
    "equal sign" -> "=",
    "right bracket" -> "}",
    "forward slash" -> "/",
    "colon" -> ":",
    "back slash" -> "\\",
    "lank spaces" -> "b",
    "at sign" -> "@"
};