Какие из предлагаемых символов не разрешены в имени файла

Обновлено: 03.07.2024

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

Хотя подавляющее большинство настольных компьютеров по-прежнему используют ОС Microsoft Windows или Macintosh, существует множество других операционных систем (и файловых систем), которые могут взаимодействовать с файлами в различных точках. Сотовые телефоны, ленточные накопители, сетевое оборудование, телевизоры и даже цифровые камеры сегодня поддерживают файловые системы.

Большинство современных файловых систем и операционных систем, в которых они используются, поддерживают гораздо более длинные имена файлов, чем персональные компьютеры, работающие под управлением Microsoft DOS и ранних версий Windows. Эти компьютеры использовали имя файла 8.3, которое позволяло восемь символов слева от точки и три символа справа, чтобы указать компьютеру, какое приложение использовать для его отображения. Однако по-прежнему можно столкнуться с проблемами, связанными с длиной имени файла.

Принятие правильных соглашений об именах файлов может помочь гарантировать, что файлы будут работать с различными операционными системами и форматами дисков, такими как Windows, Linux, Mac OS X и UNIX. Именование файлов также является важным фактором при передаче файлов через Интернет, когда может быть неочевидно, какая компьютерная платформа использовалась при первоначальном создании файлов.

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

Некоторые приложения и компьютерные скрипты могут не распознавать пробелы или иначе обрабатывать ваши файлы при использовании пробелов. Лучше всего заменять пробелы в именах файлов подчеркиванием (_) или дефисом (-). В приложении B бюллетеня NARA 2015-04 указано, что пробелы в именах файлов запрещены. Веб-среды переводят пробелы и отображают их как «%20». Например, «Имя файла.doc» будет отображаться в URL-адресе как «Файл%20Name.doc», где?. Это изменение может привести к путанице при определении фактического имени файла.

Следует избегать пунктуации, символов или специальных символов (точки, запятые, круглые скобки, амперсанд, звездочки и т. д.). Некоторые из этих символов используются в операционных системах для выполнения определенных задач, например для обозначения уровней папок в продуктах Microsoft и операционных системах Mac. Точки используются для идентификации форматов файлов, таких как .jpg и .doc.

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

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

Некоторые файловые системы, такие как NTFS, поддерживают связанные файлы и каталоги, которые также следуют соглашениям и правилам именования файлов, как и обычные файлы или каталоги. Дополнительные сведения см. в разделах «Жесткие ссылки и соединения» и «Точки повторной обработки и операции с файлами».

Дополнительную информацию см. в следующих подразделах:

Чтобы узнать, как настроить Windows 10 для поддержки длинных путей к файлам, см. статью Ограничение максимальной длины пути.

Имена файлов и каталогов

Все файловые системы следуют одним и тем же общим соглашениям об именах для отдельных файлов: базовое имя файла и необязательное расширение, разделенные точкой. Однако каждая файловая система, такая как NTFS, CDFS, exFAT, UDFS, FAT и FAT32, может иметь определенные и отличающиеся правила формирования отдельных компонентов пути к каталогу или файлу. Обратите внимание, что каталог — это просто файл со специальным атрибутом, определяющим его как каталог, но в остальном он должен соответствовать тем же правилам именования, что и обычный файл.Поскольку термин каталог просто относится к особому типу файла в том, что касается файловой системы, в некоторых справочных материалах используется общий термин файл для охвата обеих концепций каталогов. и файлы данных как таковые. По этой причине, если не указано иное, любые правила или примеры именования или использования файла также должны применяться к каталогу. Термин путь относится к одному или нескольким каталогам, обратной косой черте и, возможно, имени тома. Дополнительные сведения см. в разделе «Пути».

Ограничения по количеству символов также могут различаться в зависимости от файловой системы и используемого формата префикса имени пути. Это еще более усложняется поддержкой механизмов обратной совместимости. Например, более старая файловая система MS-DOS FAT поддерживает не более 8 символов для основного имени файла и 3 символа для расширения, всего 12 символов, включая разделитель точек. Это обычно известно как имя файла 8.3. Файловые системы Windows FAT и NTFS не ограничены именами файлов версии 8.3, поскольку они имеют поддержку длинных имен файлов, но они по-прежнему поддерживают версию 8.3 длинных имен файлов.

Соглашения об именах

Следующие основные правила позволяют приложениям создавать и обрабатывать допустимые имена для файлов и каталогов независимо от файловой системы:

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

Используйте обратную косую черту (\) для разделения компонентов пути. Обратная косая черта отделяет имя файла от пути к нему и одно имя каталога от другого имени каталога в пути. Вы не можете использовать обратную косую черту в имени фактического файла или каталога, потому что это зарезервированный символ, который разделяет имена на компоненты.

При необходимости используйте обратную косую черту в имени тома, например, "C:\" в "C:\path\file" или "\\server\share" в "\\server\share\path". \file" для имен универсального соглашения об именах (UNC). Дополнительные сведения об именах UNC см. в разделе «Ограничение максимальной длины пути».

Не предполагайте чувствительность к регистру. Например, считайте имена OSCAR, Oscar и oscar одинаковыми, хотя некоторые файловые системы (например, POSIX-совместимая файловая система) могут считать их разными. Обратите внимание, что NTFS поддерживает семантику POSIX для учета регистра, но это не поведение по умолчанию. Дополнительные сведения см. в разделе CreateFile.

Обозначения томов (буквы дисков) также нечувствительны к регистру. Например, "D:\" и "d:\" относятся к одному и тому же тому.

Используйте любой символ текущей кодовой страницы для имени, включая символы Unicode и символы расширенного набора символов (128–255), за исключением следующих:

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

  • (больше)
  • : (двоеточие)
  • " (двойные кавычки)
  • / (косая черта)
  • \ (обратная косая черта)
  • | (вертикальная полоса или труба)
    • <ли>? (вопросительный знак)
  • * (звездочка)

Целое значение, равное нулю, иногда называемое символом NUL ASCII.

Символы, целочисленные представления которых находятся в диапазоне от 1 до 31, за исключением альтернативных потоков данных, где эти символы разрешены. Дополнительные сведения о файловых потоках см. в разделе Файловые потоки.

Любой другой символ, который не разрешен целевой файловой системой.

Используйте точку в качестве компонента каталога в пути для представления текущего каталога, например ".\temp.txt". Дополнительные сведения см. в разделе Пути.

Используйте две последовательные точки (..) в качестве компонента каталога в пути для представления родительского каталога текущего каталога, например "..\temp.txt". Дополнительные сведения см. в разделе Пути.

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

CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8 и LPT9. Также избегайте этих имен, за которыми сразу следует расширение; например, NUL.txt не рекомендуется. Дополнительные сведения см. в разделе Пространства имен.

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

Короткие и длинные имена

Длинным именем файла считается любое имя файла, которое выходит за рамки короткого стиля именования MS-DOS (также называемого 8.3). Когда вы создаете длинное имя файла, Windows также может создать короткую форму имени 8.3, называемую псевдонимом 8.3 или коротким именем, и также сохранить ее на диске. Этот псевдоним 8.3 можно отключить по соображениям производительности либо для всей системы, либо для указанного тома, в зависимости от конкретной файловой системы.

Windows Server 2008, Windows Vista, Windows Server 2003 и Windows XP: 8.3 псевдоним нельзя отключить для указанных томов до Windows 7 и Windows Server 2008 R2.

Во многих файловых системах имя файла будет содержать тильду (~) в каждом компоненте имени, которое слишком длинно для соответствия правилам именования 8.3.

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

Чтобы запросить имена файлов формата 8.3, длинные имена файлов или полный путь к файлу из системы, рассмотрите следующие варианты:

  • Чтобы получить форму длинного имени файла в формате 8.3, используйте функцию GetShortPathName.
  • Чтобы получить версию короткого имени с длинным именем файла, используйте функцию GetLongPathName.
  • Чтобы получить полный путь к файлу, используйте функцию GetFullPathName.

В более новых файловых системах, таких как NTFS, exFAT, UDFS и FAT32, Windows сохраняет длинные имена файлов на диске в кодировке Юникод, что означает, что исходное длинное имя файла всегда сохраняется. Это верно, даже если длинное имя файла содержит расширенные символы, независимо от кодовой страницы, которая активна во время операции чтения или записи с диска.

Файлы с длинными именами файлов можно копировать между разделами файловой системы NTFS и разделами файловой системы Windows FAT без потери информации об именах файлов. Это может быть не так для более старых файловых систем MS-DOS FAT и некоторых типов файловых систем CDFS (CD-ROM), в зависимости от фактического имени файла. В этом случае по возможности заменяется короткое имя файла.

Пути

Путь к указанному файлу состоит из одного или нескольких компонентов, разделенных специальным символом (обратной косой чертой), причем каждый компонент обычно представляет собой имя каталога или файла. имя, но с некоторыми заметными исключениями, обсуждаемыми ниже. Часто для интерпретации пути системой очень важно, как выглядит начало или префикс пути. Этот префикс определяет пространство имен, которое использует путь, и, кроме того, какие специальные символы используются в какой позиции пути, включая последний символ.

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

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

Полный и относительный пути

Для функций Windows API, управляющих файлами, имена файлов часто могут указываться относительно текущего каталога, а для некоторых API требуется полный путь. Имя файла относится к текущему каталогу, если оно не начинается с одного из следующих символов:

  • Имя UNC любого формата, которое всегда начинается с двух символов обратной косой черты ("\\"). Дополнительные сведения см. в следующем разделе.
  • Обозначение диска с обратной косой чертой, например "C:\" или "d:\".
  • Одна обратная косая черта, например, "\directory" или "\file.txt". Его также называют абсолютным путем.

Если имя файла начинается только с обозначения диска, но не с обратной косой черты после двоеточия, оно интерпретируется как относительный путь к текущему каталогу на диске с указанной буквой. Обратите внимание, что текущий каталог может быть или не быть корневым каталогом в зависимости от того, что он был установлен во время самой последней операции «изменить каталог» на этом диске. Ниже приведены примеры этого формата:

  • «C:tmp.txt» относится к файлу с именем «tmp.txt» в текущем каталоге на диске C.
  • "C:tempdir\tmp.txt" относится к файлу в подкаталоге текущего каталога на диске C.

Путь также считается относительным, если он содержит "двойные точки"; то есть два периода вместе в одном компоненте пути. Этот специальный спецификатор используется для обозначения каталога над текущим каталогом, также известного как «родительский каталог». Ниже приведены примеры этого формата:

  • "..\tmp.txt" указывает файл с именем tmp.txt, расположенный в родительском каталоге текущего каталога.
  • "..\..\tmp.txt" указывает файл, который находится на два каталога выше текущего каталога.
  • "..\tempdir\tmp.txt" указывает файл с именем tmp.txt, расположенный в каталоге с именем tempdir, который является равноправным каталогом для текущего каталога.

Относительные пути могут сочетать оба типа примеров, например "C.\tmp.txt".Это полезно, потому что, хотя система отслеживает текущий диск вместе с текущим каталогом этого диска, она также отслеживает текущие каталоги в каждой из разных букв диска (если в вашей системе их несколько), независимо от какое обозначение диска установлено в качестве текущего диска.

Ограничение максимальной длины пути

В выпусках Windows до Windows 10 версии 1607 максимальная длина пути — MAX_PATH, которая определяется как 260 символов. В более поздних версиях Windows для снятия ограничения требуется изменение раздела реестра или использование инструмента групповой политики. Полную информацию см. в разделе Ограничение максимальной длины пути.

Пространства имен

Существует две основные категории соглашений о пространствах имен, используемых в Windows API, обычно называемых пространствами имен NT и пространствами имен Win32. Пространство имен NT было разработано как пространство имен самого низкого уровня, в котором могут существовать другие подсистемы и пространства имен, включая подсистему Win32 и, соответственно, пространства имен Win32. POSIX — еще один пример подсистемы Windows, созданной поверх пространства имен NT. Ранние версии Windows также определяли несколько предопределенных или зарезервированных имен для определенных специальных устройств, таких как коммуникационные (последовательные и параллельные) порты и консоль дисплея по умолчанию, как часть того, что сейчас называется пространством имен устройств NT, и все еще поддерживаются в текущих версиях. Windows для обратной совместимости.

Пространства имен файлов Win32

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

При файловом вводе-выводе префикс "\\?\" к строке пути указывает API Windows отключить всю строку синтаксического анализа и отправить строку, следующую за ней, прямо в файловую систему. Например, если файловая система поддерживает большие пути и имена файлов, вы можете превысить ограничения MAX_PATH, которые в противном случае применяются API-интерфейсами Windows. Дополнительные сведения об обычном ограничении максимального пути см. в предыдущем разделе Ограничение максимальной длины пути.

Поскольку он отключает автоматическое расширение строки пути, префикс "\\?\" также позволяет использовать ".." и "." в именах путей, что может быть полезно, если вы пытаетесь выполнить операции с файлом с этими в противном случае зарезервированными спецификаторами относительного пути как части полного пути.

Многие, но не все API файлового ввода/вывода поддерживают "\\?\"; вы должны посмотреть справочную тему для каждого API, чтобы быть уверенным.

Обратите внимание, что API Unicode следует использовать, чтобы убедиться, что префикс "\\?\" позволяет превысить MAX_PATH

Пространства имен устройств Win32

Префикс "\\.\" обеспечивает доступ к пространству имен устройств Win32 вместо пространства имен файлов Win32. Так осуществляется доступ к физическим дискам и томам напрямую, минуя файловую систему, если API поддерживает такой тип доступа. Таким образом вы можете получить доступ ко многим устройствам, кроме дисков (например, с помощью функций CreateFile и DefineDosDevice).

Например, если вы хотите открыть последовательный порт 1 системы, вы можете использовать "COM1" в вызове функции CreateFile. Это работает, потому что COM1–COM9 являются частью зарезервированных имен в пространстве имен NT, хотя использование префикса «\\.\» также будет работать с этими именами устройств. Для сравнения, если у вас установлена ​​плата последовательного расширения на 100 портов и вы хотите открыть COM56, вы не сможете открыть ее с помощью «COM56», поскольку для COM56 нет предопределенного пространства имен NT. Вам нужно будет открыть его с помощью "\\.\COM56", потому что "\\.\" переходит непосредственно к пространству имен устройства, не пытаясь найти предопределенный псевдоним.

Другим примером использования пространства имен устройств Win32 является использование функции CreateFile с "\\.\PhysicalDiskX" (где X – допустимое целочисленное значение) или " \\.\CdRomX". Это позволяет вам обращаться к этим устройствам напрямую, минуя файловую систему. Это работает, потому что эти имена устройств создаются системой по мере перечисления этих устройств, а некоторые драйверы также создают другие псевдонимы в системе. Например, драйвер устройства, реализующий имя "C:\", имеет собственное пространство имен, которое также является файловой системой.

API, использующие функцию CreateFile, обычно работают с префиксом "\\.\", поскольку функция CreateFile используется для открытия как файлов, так и устройств, в зависимости от используемых вами параметров.

Если вы работаете с функциями Windows API, вы должны использовать префикс "\\.\" для доступа только к устройствам, а не к файлам.

Большинство API не поддерживают "\\.\"; только те, которые предназначены для работы с пространством имен устройств, распознают его. Всегда проверяйте справочную тему для каждого API, чтобы быть уверенным.

Пространства имен NT

Существуют также API, позволяющие использовать соглашение о пространстве имен NT, но диспетчер объектов Windows в большинстве случаев делает это ненужным. Для иллюстрации полезно просматривать пространства имен Windows в обозревателе системных объектов с помощью инструмента Windows Sysinternals WinObj. Когда вы запускаете этот инструмент, вы видите пространство имен NT, начинающееся с корня, или "\". Подпапка под названием "Global??" где находится пространство имен Win32. Объекты именованных устройств находятся в пространстве имен NT в подкаталоге «Device». Здесь вы также можете найти Serial0 и Serial1, объекты устройств, представляющие первые два COM-порта, если они есть в вашей системе. Объект устройства, представляющий том, может иметь вид HarddiskVolume1, хотя числовой индекс может отличаться. Имя "DR0" в подкаталоге "Harddisk0" является примером объекта устройства, представляющего диск, и т. д.

Чтобы сделать эти объекты устройств доступными для приложений Windows, драйверы устройств создают символическую ссылку (символическую ссылку) в пространстве имен Win32 "Global??" на соответствующие объекты устройств. Например, COM0 и COM1 в разделе "Глобальные??" подкаталог — это просто символическая ссылка на Serial0 и Serial1, «C:» — это символическая ссылка на HarddiskVolume1, «Physicaldrive0» — это символическая ссылка на DR0 и так далее. Без символической ссылки указанное устройство «Xxx» не будет доступно ни одному приложению Windows, использующему соглашения о пространстве имен Win32, как описано ранее. Однако дескриптор этого устройства может быть открыт с помощью любых API, поддерживающих абсолютный путь пространства имен NT в формате "\Device\Xxx".

С добавлением многопользовательской поддержки через службы терминалов и виртуальные машины возникла необходимость в виртуализации общесистемного корневого устройства в пространстве имен Win32. Это было достигнуто путем добавления символической ссылки с именем «GLOBALROOT» в пространство имен Win32, которое вы можете увидеть в «Global??» подкаталог инструмента браузера WinObj, который обсуждался ранее, и может получить доступ через путь «\\?\GLOBALROOT». Этот префикс гарантирует, что путь, следующий за ним, соответствует истинному корневому пути диспетчера системных объектов, а не пути, зависящему от сеанса.

Я пишу процедуру ввода/вывода имени файла на языке ассемблера x86-16. Он берет восемь символов (мне не нужно поддерживать длинные имена файлов) с клавиатуры и печатает их в поле ввода текста на экране.

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

Я бы хотел разрешить все разрешенные символы, но не могу найти официальный список запрещенных символов. Здравый смысл подсказывает мне, что косые черты незаконны, но если бы мне пришлось угадывать, я бы сказал, что символ плюса разрешен. (изменить: это не так!)

Я уже игнорирую символ точки, поскольку мой код автоматически обрабатывает добавление точки и расширения файла.

Попробуйте создать папку в Windows и поставьте '?' во имя. Подсказка сообщает вам, какие символы запрещены. Это дает вам начало :).

@Mixxiphoid, это не сработает, потому что набор разрешенных символов в Windows намного больше. Например, +,;[] , пробел и az разрешены в Windows, но не в DOS. Проводник выдает ошибку "Имя файла не может содержать ни один из следующих символов \ / : * ?" | который является лишь подмножеством запрещенных символов в DOS

@phuclv вот почему я сказал: «Это дает вам возможность начать», а также почему это комментарий, а не ответ.

4 ответа 4

Краткое изложение можно найти в Википедии:

А вот что официально сказано в руководстве пользователя MS-DOS 6

Это из PC-DOS 7:

  • Он может содержать не более восьми символов.

  • Он может состоять из букв от A до Z, цифр от 0 до 9 и следующих специальных символов:

  • Имя не может содержать пробелы, запятые, обратную косую черту или точки (кроме точки, которая отделяет имя от расширения).
  • Имя не может быть одним из следующих зарезервированных имен файлов: CLOCK$, CON, AUX, COM1, COM2, COM3, COM4, ​​LPT1, LPT2, LPT3, LPT4, NUL и PRN.
  • Имя не может совпадать с именем другого файла в каталоге.

Первый байт имени не должен быть 0x20 (пробел). Короткие имена или расширения дополняются пробелами. Специальные символы ASCII 0x22 ( " ), 0x2a ( * ), 0x2b ( + ), 0x2c ( , ), 0x2e ( . ), 0x2f ( / ), 0x3a ( : ), 0x3b ( ; ), 0x3c ( ), 0x3d ( = ), 0x3e ( > ), 0x3f ( ? ), 0x5b ( [ ), 0x5c ( \ ), 0x5d ( ] ), 0x7c ( | ) не допускаются.

В настоящее время я использую для большинства своих файлов имя ГГММДД-ИМЯ+СТРАНИЦА. NAME содержит пробелы, преобразованные в символы подчеркивания.

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

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

- символ безопасен для использования в Windows 7.. возможно, другие современные операционные системы делают то же самое.. вы можете использовать символ минус для разделения..

4 ответа 4

Обзор:

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

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

Окна

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

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

Линукс, OS-X

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

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

Заключение

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

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

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

(Windows 10 NTFS).

В целом хороший ответ, но я бы воздержался от использования имен файлов в пробелах. Правильный побег от них во всех контекстах доставляет больше хлопот, чем пользы. Обратите внимание, что Microsoft перестала использовать пробел в именах системных каталогов. Если вам нужно указать границы слов в именах, отлично подойдет CamelCase.

"C:\Program files (x86)" все еще существует в Win8 - это не системный каталог? Я согласен с тем, что пробелы могут вызвать проблемы.

Да, но его можно переименовать во что угодно. Конечно, многие программы будут в бешенстве, если вы переименуете его в "]:\foobar", но Windows все равно обращается к нему как к "%programfiles(x86)%".

Здесь следует иметь в виду, что система Linux может рассматривать прописные и строчные буквы как разные, в то время как Windows считает их одинаковыми.

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

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

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

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

Квадратные скобки ( [] ) являются частью регулярных выражений и также имеют особое значение в оболочке. Но с ними не так уж и плохо работать, за исключением некоторых неприятных угловых случаев.

В zsh символы, которые могут интерпретироваться по-разному, включают []()^; , поэтому я думаю, что правильным ответом на самом деле может быть [0-9a-zA-Z.,_-] Запятая также может быть исключена только потому, что это странно видеть в имени файла, хотя я не могу вспомнить реальный случай, когда это вызовет проблемы.

Не думаю, что буду включать . в списке символов, которые «не раздражают в использовании». Очевидно, что есть вероятность неправильного истолкования как расширения и т. д.

Если вы собираетесь запретить использование пробелов, поскольку они могут быть интерпретированы оболочкой, вам необходимо запретить использование точки с запятой ';' также.

Alt-1. начальные заглавные буквы могут заменять пробелы: ГГММДД-ЧЧММ-FileName.ext или ГГММДД-ЧЧММ_FileName.ext

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

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

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

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

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

Читайте также: