Каковы требования к именам файлов каталогов

Обновлено: 21.11.2024

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

Однако создание такого списка требует времени. Утомительно вручную перечислять все файлы и папки, особенно если речь идет о 100, 1000 или даже 100 000 файлов. Конечно, другой путь ведет через различные компьютерные команды в командной строке, но об этом мало кто знает или доволен созданным форматом вывода.

Самый простой способ — использовать Filelist Creator, который можно бесплатно загрузить с этого веб-сайта для Windows, macOS и Linux. С этой программой это не составит большого труда! Достаточно просто перетащить файлы в программу, и ваши файлы появятся в списке автоматически. При этом вы сами выбираете, должны ли быть перечислены только файлы, только каталоги или и то и другое, файлы и каталоги.

Конечно, несмотря на эту простоту, вы можете использовать множество дополнительных настроек. Вы можете определить, какие столбцы в какой форме используются в таблице, вы можете указать, как должен выглядеть дизайн и не только, вы можете настроить вывод по своему усмотрению: в виде электронной таблицы XLSX или ODS для Microsoft Excel или OpenOffice, в виде HTML-сайта. , в виде изображения (PNG, JPG, BMP), файла CSV, в формате обмена данными или, конечно же, в виде простого текста. Кроме того, конечно, также можно распечатать список файлов, используя физический принтер или PDF-принтер.

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

Fillellist Creator полностью совместим с Unicode. Это означает, что вы можете легко создавать списки файлов, содержащих символы Unicode, и вы можете использовать Unicode во всех настройках, например, в заголовках столбцов. Даже при сохранении списка поддерживаются все распространенные форматы Unicode и формат ANSI.

Скачать

Загрузите бесплатно FilelistCreator в разделе загрузки для Windows, Linux или macOS и на первых шагах узнайте, какие преимущества вы можете извлечь из этого приложения. Кроме того, мы собираем для вас часто задаваемые вопросы о FilelistCreator на странице часто задаваемых вопросов. FilelistCreator является портативным, вы можете использовать программу напрямую без установки.

Скриншоты

Вы хотите сначала увидеть, как выглядит FilelistCreator? На странице снимков экрана мы собрали для вас несколько снимков экрана FilelistCreator.

Все файловые системы, поддерживаемые 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». Этот префикс гарантирует, что путь, следующий за ним, соответствует истинному корневому пути диспетчера системных объектов, а не пути, зависящему от сеанса.

Сделать имена файлов и каталогов строчными. Используйте дефисы, а не символы подчеркивания, для разделения слов, например, query-data.html . Используйте только стандартные буквенно-цифровые символы ASCII в именах файлов и каталогов.

Не используйте общие имена страниц, такие как document1.html .

Исключения для согласованности

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

Например, если в каталоге уже есть урок_1.jd , урок_2.jd и урок_3.jd , можно добавить новый файл как урок_4.jd вместо урока-4.jd . Однако во всех остальных случаях используйте дефисы.

Иногда допустимо: избегание_cliches.jd

Не рекомендуется: избегайтеcliches.jd

Не рекомендуется: избегайтеCliches.jd

Не рекомендуется: избегать-clichés.jd

Другие исключения

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

Ссылка на файлы

В следующих разделах обсуждается, как ссылаться на файлы.

Ссылка на имена файлов

При обращении к конкретному файлу сделайте следующее:

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

Рекомендуется: в следующем файле build.sh измените значения по умолчанию для всех параметров:

Обратитесь к взаимодействию с файлами

При взаимодействии с файлами и типами файлов не используйте типы файлов в качестве глагола.

Рекомендуется: распаковать ZIP-файл.

Не рекомендуется: разархивируйте ZIP-файл.

См. типы файлов

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

Рекомендуется: файл PNG

Не рекомендуется: файл .jpg

Рекомендуется: файл Bash

Не рекомендуется: файл .sh

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

Расширение	Имя типа файла
.adoc	Файл AsciiDoc
.csv	CSV-файл
.exe	исполняемый файл
.jpg	GIF-файл
.img	файл образа диска< /td>
.jar	JAR-файл
.jpg , .jpg	Файл JPEG
.json	Файл JSON
.md	Файл Markdown
.pdf	Файл PDF
.jpg	Файл PNG
.ps	Файл PowerShell
.py	Файл Python
.sh	Файл Bash
.sql	Файл SQL
.svg	SVG-файл
.tar	tar-файл
.txt	текстовый файл
.yaml	Файл YAML
.zip	zip-файл

Если не указано иное, содержимое этой страницы предоставляется по лицензии Creative Commons Attribution 4.0, а образцы кода — по лицензии Apache 2.0. Подробнее см. в Правилах сайта Google Developers. Java является зарегистрированным товарным знаком Oracle и/или ее дочерних компаний.

Grant-proposal-henry-edits-finalfinal.doc
Grant-proposal-final-Julia_edits_v4.doc
FINAL_proposal_Aug2016_kct-updated.doc

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

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

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

Разработка соглашения об именах файлов

Имя файла может состоять из ряда описательных элементов, таких как ключевые слова, даты, идентификационные номера и т. д. Чтобы разработать соглашение об именовании файлов, вы должны решить, какие типы элементов следует включать и в каком порядке.< /p>

Например, соглашение об именах файлов может включать следующие компоненты в следующем порядке: [ГГММДД]_[Проект]_[Местоположение]_[Событие].xxx

Примеры имен файлов, основанные на этом примерном соглашении, могут быть такими:

160301_HRC_Geneva_launch.jpg
151208_Uwazi_Madrid_inception.pdf
160219_OHCHR_Tunis_meeting.jpg

Ниже приведены некоторые рекомендации по созданию собственного соглашения об именах файлов.

1. Подумайте, как вы хотите сортировать и извлекать файлы

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

Начните имя файла с самого важного параметра. Это позволит вам организовать файлы в алфавитном или хронологическом порядке по этому параметру без необходимости выполнять какой-либо поиск. Например, если основным способом доступа к файлу судебного дела является его номер, то он должен быть первым элементом в вашем соглашении об именовании файлов: когда вы сортируете свои документы в файловом менеджере, вы сначала увидите их по номеру дела.
Для дат используйте ГГГГ-ММ-ДД (или ГГГГММДД, или ГГММДД, или ГГММ). Чтобы обеспечить сортировку файлов в правильном хронологическом порядке, наиболее значимые компоненты даты и времени должны отображаться первыми, а затем наименее значимые компоненты. Если все остальные слова в имени файла совпадают, это соглашение позволит нам сортировать по году, затем по месяцу, а затем по дате. В некоторых соглашениях дата указывается перед каждым именем файла, потому что это наиболее логичный способ извлечения файлов для их команды.
Отметить разные версии одного и того же файла. Если файл будет поддерживаться с течением времени, используйте условное обозначение v1, v2, v3 и т. д., чтобы обозначить его место в последовательности версий. Вы можете отделить букву «v» от типа контента символом подчеркивания («_») или дефисом («-»). По мере создания и обновления версий меняйте версию, но сохраняйте имя файла прежним.
Не забывайте нули, если вам нужны порядковые номера.Если будет более девяти файлов с одинаковыми именами (например, в случае версии или в серии фотографий), убедитесь, что вы настроили номера следующим образом: 01, 02, 03, … Это позволит отсортировать их в хронологическом порядке. То же самое, если файлов более 99, это должно быть 001, …060, …099, …100

2. Используйте соответствующие компоненты в именах файлов, чтобы предоставить описание и контекст

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

Название организации
Программа или тема
Тип документа
Географический охват
Дата или период
Язык документа
Тип содержания, например "счет" или "отчет"

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

3. Держите имя файла разумной длины

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

Сокращение года до двух чисел вместо четырех.
Сокращение компонентов имени файла (например, используйте «inv» вместо «invoice» или «fr» вместо «francais»)
Используйте как можно меньше слов, чтобы передать подлинность документа.

4. Избегайте специальных символов и пробелов

Подчеркивание (например, file_name.xxx)
Дефисы (например, имя-файла.xxx)
Без разделения (например, имя файла.xxx)
Верблюжий регистр, когда первая буква каждого раздела текста пишется с большой буквы (например, FileName.xxx)

5. Задокументируйте свое соглашение об именах файлов и привлеките других пользователей

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

Вот два примера задокументированных соглашений об именах файлов от наших партнеров: один от Африканской комиссии по правам человека и народов (ACHPR), а другой от Международной комиссии юристов (ICJ).

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

Дополнительные ресурсы

Библиотеки Стэнфордского университета предлагают два иллюстративных тематических исследования для дальнейшего изучения соглашений об именах файлов:

Однако мне нужно подробное руководство, учитывающее двухбайтовые символы. Ссылки на внешние ресурсы меня не устраивают.

Сначала мне нужно создать каталог в файловой системе, используя имя, которое может содержать запрещенные символы, поэтому я планирую заменить эти символы символами подчеркивания. Затем мне нужно записать этот каталог и его содержимое в zip-файл (используя Java), поэтому любые дополнительные советы относительно имен zip-каталогов будут оценены.

Некоторые символы, которые вы упомянули, действительно разрешены в Windows. Проверьте это: echo abc > "ab.;,=[1]"

@DavidC.Bishop: В этом сообщении SO утверждается, что ядро Linux не позволит вам работать с именем файла, содержащим косую черту. Удалось ли вам заставить это работать?

«/ не является незаконным в Linux. Вам просто нужно экранировать его с помощью \ при вводе» — это утверждение совершенно неверно. Компоненты имени файла не могут содержать /, и его экранирование не имеет никакого эффекта.

19 ответов 19

Давайте не будем усложнять и сначала ответим на вопрос.

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

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

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

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

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

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

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

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

Вы не просили об этом, но на всякий случай: двоеточие : и косая черта / в зависимости от контекста не разрешены (например, Finder поддерживает косые черты, терминал поддерживает двоеточия). (Подробнее)

Новые строки не запрещены в Linux. Хотя я бы сказал, что они должны быть. и если NUL запрещен в Linux, то он запрещен и в Windows, он служит той же цели.

@Soaku: конечно, нет, поскольку мир не вращается вокруг Microsoft. Зачем добавлять ненужные ограничения, когда есть только два символа, которые абсолютно необходимо запретить?

@firegurafiku «/» — это просто условность — имена каталогов в любом случае хранятся отдельно друг от друга, поэтому «/» может без проблем появляться в именах (если разрешено). Если используется в имени каталога/файла внутри пути, он должен быть экранирован, но это относится и ко многим другим символам. Работа с '\0' потребует отдельного хранения длины строки везде, что на самом деле сложнее.

"В большинстве дистрибутивов Linux вы можете назвать файл с помощью косой черты." -- Нет, нельзя. '/' всегда рассматривается ядром, а не только оболочкой, как разделитель каталогов. Невозможно обойти это с помощью программы C, скрипта Python или любого другого способа.

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

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

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

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

Ключевая фраза из ссылки MSDN: «[и] любой другой символ, который не разрешен целевой файловой системой». В Windows могут быть разные файловые системы. Некоторые могут разрешать Unicode, другие — нет. Как правило, единственный безопасный способ проверить имя — попробовать его на целевом устройстве.

Есть некоторые рекомендации, и "существует бесконечное количество имен, состоящих только из допустимых запрещенных символов" неконструктивно. Точно так же «Windows не различает символы верхнего и нижнего регистра» является глупым исключением — ОП спрашивает о синтаксисе, а не о семантике, и ни один здравомыслящий человек не скажет, что имя файла например, файл A.txt был недействительным, поскольку файл .TXT может существовать.

COPY CON PRN означает чтение с клавиатуры или, возможно, стандартного ввода и копирование на принтер. Не уверен, что это все еще действует в современных окнах, но определенно было в течение длительного времени. В старые времена вы могли использовать его для ввода текста, а матричный принтер просто выводил его.

@JimBalter Если я не ошибаюсь, это неконструктивно, потому что «бесконечное количество имен, состоящих только из допустимых запрещенных символов» довольно бессмысленно, если правила для имен файлов четко определены и сами по себе не бесконечны. Ничто в этом ответе не оправдывает описание возможностей как бесконечных таким образом, чтобы это было полезно или полезно для читателя. Например. сравните следующее: (1) В Linux «/» не допускается. (2) Полное руководство для Linux невозможно, потому что существует бесконечное количество запрещенных имен, например. "/", "//", "///", "а/а", "б/б" и т. д.

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

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

Другие люди рассмотрели правила для имен файлов Windows со ссылками на Microsoft и Википедию по этой теме.

Обратите внимание, что в MacOS X файловая система нечувствительна к регистру. Текущие версии позволяют двоеточие : в именах файлов, хотя исторически это не всегда было так:

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

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

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

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