Имя файла
Текстовая строка, используемая для уникальной идентификации компьютерного файла.

Скриншот командной оболочки Windows , показывающий имена файлов в каталоге
Список имен файлов с длинными именами, содержащими запятые и пробелы, в том виде, в котором они отображаются на дисплее программного обеспечения.

Имя файла или имя файла — это имя, используемое для уникальной идентификации файла компьютера в файловой системе . Различные файловые системы накладывают различные ограничения на длину имени файла.

Имя файла может (в зависимости от файловой системы) включать:

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

Символы, разрешенные в именах файлов, зависят от файловой системы. Буквы A–Z и цифры 0–9 разрешены большинством файловых систем; многие файловые системы поддерживают дополнительные символы, такие как буквы a–z, специальные символы и другие печатные символы, такие как буквы с ударениями, символы в нелатинских алфавитах и ​​символы в неалфавитных шрифтах. Некоторые файловые системы позволяют даже непечатаемым символам, включая Bell , Null , Return и Linefeed , быть частью имени файла, [1] хотя большинство утилит не справляются с ними должным образом.

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

Некоторые люди используют термин имя файла, когда ссылаются на полную спецификацию устройства, подкаталогов и имени файла, например Windows C:\Program Files\Microsoft Games\Chess\Chess.exe . Имя файла в этом случае Chess.exe . Некоторые утилиты имеют настройки для подавления расширения, как в MS Windows Explorer. [ не проверено в тексте ]

История

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

Например, в операционных системах TOPS-10 и RSTS/E от Digital Equipment Corporation файлы идентифицировались по

  • Необязательное имя устройства (один или два символа), за которым следует необязательный номер устройства и двоеточие ":". Если оно отсутствует, предполагается, что это SY:
  • номер счета, состоящий из скобки «[», пары цифр, разделенных запятой, и закрывающей скобки «]». Если он был опущен, то предполагалось, что он ваш.
  • обязательное имя файла, состоящее из 1–6 символов (заглавных букв или цифр)
  • необязательное расширение из 3 символов.

В операционных системах OS/VS1 , MVS и OS/390 от IBM имя файла могло содержать до 44 символов, состоящих из заглавных букв, цифр и точки. Имя файла должно начинаться с буквы или цифры, точка должна встречаться не реже одного раза на каждые 8 ​​символов, две последовательные точки не могли появляться в имени и должны заканчиваться буквой или цифрой. [2] По соглашению буквы и цифры перед первой точкой были номером счета владельца или проекта, к которому он принадлежал, но не было никаких требований использовать это соглашение. [3]

В системе MUSIC/SP Университета Макгилла имена файлов состояли из

  • Необязательный номер учетной записи, который состоял из одного-четырех символов, за которыми следовало двоеточие. Если номер учетной записи отсутствовал, предполагалось, что он находится в вашей учетной записи, а если нет, предполагалось, что он находится в псевдоучетной записи *COM:, где каталогизировались все файлы, помеченные как общедоступные.
  • Имя файла длиной от 1 до 17 символов, которое может состоять из заглавных букв или цифр, и точки, при этом необходимо, чтобы имя не начиналось и не заканчивалось точкой, а также не имело двух последовательных точек.

Операционная система Univac VS/9 имела имена файлов, состоящие из

  • Имя учетной записи, состоящее из знака доллара "$", имени пользователя из 1-7 символов (буквы или цифры) и точки ("."). Если его нет, предполагается, что он находится в вашей учетной записи, но если его там нет, операционная система будет искать в учетной записи системного менеджера $TSOS. Если вы ввели только знак доллара в качестве учетной записи, это будет означать, что файл находится в учетной записи $TSOS, если только первые 1-7 символов имени файла до первой точки не соответствуют фактическому имени учетной записи, тогда эта учетная запись была использована, например, ABLE.BAKER — это файл в вашей учетной записи, но если его там нет, система будет искать $TSOS.ABLE.BAKER, но если был указан $ABLE.BAKER, будет использоваться файл $TSOS.ABLE.BAKER, если только $ABLE не является допустимой учетной записью, тогда он будет искать файл с именем BAKER в этой учетной записи.
  • Имя файла, 1–56 символов (буквы и цифры), разделенных точками. Имена файлов не могут начинаться или заканчиваться точкой, а также не могут появляться две последовательные точки.

В 1985 году RFC  959 официально определил имя пути как строку символов, которую пользователь должен ввести в файловую систему для идентификации файла. [4]

На ранних персональных компьютерах с операционной системой CP/M имена файлов всегда состояли из 11 символов. Это называлось именем файла 8.3 с максимальным именем 8 байт и максимальным расширением 3 байта. Утилиты и приложения позволяли пользователям указывать имена файлов без конечных пробелов и включать точку перед расширением. Точка фактически не хранилась в каталоге. Использование только 7-битных символов позволяло включать несколько атрибутов файла в фактическое имя файла с помощью старшего бита; эти атрибуты включали Readonly, Archive и System. [5] В конце концов это стало слишком ограничительным, и количество разрешенных символов увеличилось. Биты атрибутов были перемещены в специальный блок файла, включающий дополнительную информацию. [ необходима цитата ]

Первоначальная файловая система File Allocation Table (FAT), используемая Standalone Disk BASIC-80 , имела имя файла 6.3 с максимум 6 байтами в имени и максимум 3 байтами в расширении. Файловые системы FAT12 и FAT16 в IBM PC DOS / MS-DOS и Microsoft Windows до Windows 95 использовали то же соглашение 8.3, что и файловая система CP/M. Файловые системы FAT поддерживали 8-битные символы, что позволяло им поддерживать не-ASCII символы в именах файлов, и хранили атрибуты отдельно от имени файла.

Около 1995 года в Windows 95 и Windows NT было введено расширение файловой системы MS-DOS FAT VFAT . Оно позволяло использовать длинные имена файлов (LFN) со смешанным регистром , используя символы Unicode , в дополнение к классическим именам "8.3".

Схемы именования файлов

Программы и устройства могут автоматически присваивать файлам имена, такие как числовой счетчик (например IMG_0001.JPG, ) или временная метка с текущей датой и временем.

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

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

Ссылки: абсолютные и относительные

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

Это создает абсолютный или относительный путь, состоящий из последовательности имен файлов.

Количество имен в файле

Файловые системы в стиле Unix позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix имена являются жесткими ссылками на индексный дескриптор файла или эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команду fsutilв Windows XP и mklinkболее поздних версиях для их создания. [6] [7] Жесткие ссылки отличаются от ярлыков Windows, классических псевдонимов Mac OS/macOS или символических ссылок . Введение LFN с VFAT позволило использовать псевдонимы имен файлов. Например, longfi~1.???псевдоним имени файла " " с максимальным количеством восемь плюс три символа был long file name.???способом соответствия ограничениям 8.3 для старых программ.

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

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

Ограничения по длине

Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эти длины применяются ко всему имени файла, как 44 символа в IBM z/OS . [2] В других случаях ограничения длины могут применяться к определенным частям имени файла, таким как имя файла в каталоге или имя каталога. Например, 9 (например, 8-битный FAT в Standalone Disk BASIC ), 11 (например, FAT12 , FAT16 , FAT32 в DOS), 14 (например, ранний Unix), 21 ( Human68K ), 31, 30 (например, Apple DOS 3.2 и 3.3), 15 (например, Apple ProDOS ), 44 (например, IBM S/370), [2] или 255 (например, ранний Berkeley Unix) символов или байтов. Ограничения по длине часто возникают из-за выделения фиксированного пространства в файловой системе для хранения компонентов имен, поэтому увеличение ограничений часто требует несовместимых изменений, а также резервирования большего пространства.

Конкретная проблема с файловыми системами, которые хранят информацию во вложенных каталогах, заключается в том, что может быть возможным создание файла с полным именем пути, которое превышает ограничения реализации, поскольку проверка длины может применяться только к отдельным частям имени, а не ко всему имени. Многие приложения Windows ограничены значением MAX_PATH260, но имена файлов Windows могут легко превышать этот предел. [8] Начиная с Windows 10 версии 1607 , ограничения MAX_PATH были сняты. [9]

Расширения имени файла

Имена файлов в некоторых файловых системах, таких как FAT и уровни ODS-1 и ODS-2 Files-11 , состоят из двух частей: базового имени или основы и расширения или суффикса, используемого некоторыми приложениями для указания типа файла . Некоторые другие файловые системы, такие как файловые системы Unix , VFAT и NTFS , обрабатывают имя файла как одну строку; соглашение, часто используемое в этих файловых системах, заключается в обработке символов, следующих за последней точкой в ​​имени файла, в имени файла, содержащем точки, как части расширения имени файла.

Несколько выходных файлов, созданных приложением, могут использовать одно и то же базовое имя и различные расширения. Например, компилятор Fortran может использовать расширение FORдля исходного входного файла, OBJдля выходного объекта и LSTдля листинга. Хотя есть некоторые общие расширения, они произвольны, и другое приложение может использовать RELи RPT. Расширения были ограничены, по крайней мере исторически в некоторых системах, длиной в 3 символа, но в целом могут иметь любую длину, например, html.

Совместимость кодирования

Общего стандарта кодирования имен файлов не существует.

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

Совместимость кодировки индикации

Традиционно в именах файлов допускались любые символы, при условии, что они были безопасны для файловой системы. [10] Хотя это позволяло использовать любую кодировку и, таким образом, позволяло представлять любой локальный текст в любой локальной системе, это вызывало множество проблем с совместимостью.

Имя файла могло храниться с использованием различных строк байтов в различных системах в пределах одной страны, например, если бы одна использовала японскую кодировку Shift JIS , а другая японскую кодировку EUC . Преобразование было невозможно, поскольку большинство систем не раскрывали описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это вынуждало дорогостоящее угадывание кодировки имени файла при каждом доступе к файлу. [10]

Решением стало принятие Unicode в качестве кодировки имен файлов.

Однако в классической Mac OS кодировка имени файла сохранялась вместе с атрибутами имени файла. [10]

Совместимость с Unicode

Стандарт Unicode решает проблему определения кодировки.

Тем не менее, некоторые ограниченные проблемы взаимодействия остаются, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничена Unicode 2.0; файловая система HFS+ macOS применяет нормализацию NFD Unicode и опционально чувствительна к регистру (по умолчанию нечувствительна к регистру). Максимальная длина имени файла не является стандартной и может зависеть от размера кодовой единицы. Хотя это серьезная проблема, в большинстве случаев она ограничена. [10]

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

Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является Non-normalizing Unicode Composition Awareness, используемый в технических сообществах Subversion и Apache. [12] Это решение не нормализует пути в репозитории. Пути нормализуются только для целей сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запретив ее использование другими сообществами. [ необходимо разъяснение ]

Перспективы

Чтобы ограничить проблемы взаимодействия, Sun предлагает следующие идеи:

  • использовать одну кодировку Unicode (например, UTF-8)
  • выполнять прозрачные преобразования кодов в именах файлов
  • не хранить нормализованные имена файлов
  • проверьте каноническую эквивалентность имен файлов, чтобы избежать двух канонически эквивалентных имен файлов в одном каталоге. [10]

Эти соображения создают ограничение, не позволяющее в будущем перейти на кодировку, отличную от UTF-8.

Миграция в Юникод

Одной из проблем была миграция в Unicode. Для этой цели несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для миграции имен файлов в новую кодировку Unicode.

  • Microsoft обеспечила прозрачную для пользователя миграцию с помощью технологии VFAT
  • Apple предоставила «Утилиту восстановления кодировки имени файла v1.0». [13]
  • Сообщество Linux предоставило " convmv ". [14]

Mac OS X 10.3 ознаменовала принятие Apple декомпозиции символов Unicode 3.2, заменяющей декомпозицию Unicode 2.1, использовавшуюся ранее. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X. [15]

Уникальность

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

Подход к уникальности может различаться как в зависимости от чувствительности к регистру, так и в зависимости от формы нормализации Unicode , такой как NFC, NFD. Это означает, что могут быть созданы два отдельных файла с одинаковым текстовым именем файла и разной реализацией байта имени файла, например L"\x00C0.txt" (UTF-16, NFC) (латинская заглавная A с грависом) и L"\x0041\x0300.txt" (UTF-16, NFD) (латинская заглавная A с грависом). [16]

Сохранение регистра букв

Некоторые файловые системы, такие как FAT до введения VFAT , хранят имена файлов в верхнем регистре независимо от регистра букв , использованного для их создания. Например, файл, созданный с именем "MyName.Txt" или "myname.txt", будет сохранен с именем "MYNAME.TXT" (VFAT сохраняет регистр букв). Любая вариация верхнего и нижнего регистра может использоваться для ссылки на один и тот же файл. Такие типы файловых систем называются нечувствительными к регистру и не являются сохраняющими регистр . Некоторые файловые системы вообще запрещают использование строчных букв в именах файлов.

Некоторые файловые системы хранят имена файлов в том виде, в котором они были изначально созданы; они называются сохраняющими регистр или регистр . Такая файловая система может быть чувствительной к регистру или нечувствительной к регистру . Если чувствительна к регистру, то "MyName.Txt" и "myname.txt" могут ссылаться на два разных файла в одном каталоге, и каждый файл должен ссылаться на точную регистровую комбинацию, с которой он назван. С другой стороны, в нечувствительной к регистру файловой системе, сохраняющей регистр, только одно из "MyName.Txt", "myname.txt" и "Myname.TXT" может быть именем файла в данном каталоге в данный момент времени, и на файл с одним из этих имен можно ссылаться с помощью любой регистровой комбинации имени.

С самого начала файловые системы в Unix и производных от него системах были чувствительны к регистру и сохраняли регистр. Однако не все файловые системы в этих системах чувствительны к регистру; по умолчанию HFS+ и APFS в macOS нечувствительны к регистру, но сохраняют регистр, а серверы SMB обычно обеспечивают поведение без учета регистра (даже если базовая файловая система чувствительна к регистру, например, Samba в большинстве Unix-подобных систем), а клиентские файловые системы SMB обеспечивают поведение без учета регистра. Чувствительность к регистру в файловой системе является значительной проблемой для программного обеспечения, такого как Samba и Wine , которое должно эффективно взаимодействовать как с системами, которые обрабатывают файлы с заглавными и строчными буквами как разные, так и с системами, которые обрабатывают их одинаково. [17]

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

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

Многие утилиты файловой системы запрещают использование управляющих символов в именах файлов. В файловых системах типа UnixНулевой символ [18] и разделитель пути /запрещены.

Проблемные персонажи

Утилиты файловой системы и соглашения об именовании в различных системах запрещают использование определенных символов в именах файлов или делают их проблематичными: [8] Если не указано иное, символы в столбце «Символ » , например « и < » , нельзя использовать в именах файлов Windows.

ХарактерИмяПричина запрета
/слэшИспользуется в качестве разделителя компонентов имени пути в системах типа Unix, Windows и Amiga. (Пока параметр SwitChar установлен в значение / , оболочка DOS COMMAND.COM будет использовать его как символ-переключатель, но сами DOS и Windows всегда принимают его в качестве разделителя на уровне API.)
Большая косая черта ⧸ ( кодовая точка Unicode U+29F8) разрешена в именах файлов Windows.
\обратная косая чертаИспользуется как разделитель компонентов имени пути по умолчанию в DOS, OS/2 и Windows (даже если SwitChar установлен на '-'; разрешено в именах файлов Unix, см. Примечание 1).
Большая обратная косая черта ⧹ (U+29F9) разрешена в именах файлов Windows.
?знак вопросаИспользуется как подстановочный знак в Unix, Windows и AmigaOS ; обозначает один символ. Разрешено в именах файлов Unix, см. Примечание 1.
Гортанная смычка ʔ (U+0294), интерробанг ‽ (U+203D), перевернутый вопросительный знак ¿ (U+00BF), двойной вопросительный знак ⁇ (U+2047) и черный вопросительный знак❓ (U+2753) разрешены во всех именах файлов.
%процентИспользуется как подстановочный знак в RT-11 ; обозначает один символ. Не является специальным в Windows.
*звездочка
или звездочка		Используется как подстановочный знак в Unix, DOS, RT-11, VMS и Windows. Отмечает любую последовательность символов (Unix, Windows, DOS) или любую последовательность символов в базовом имени или расширении (таким образом *.*в DOS означает «все файлы»). Разрешено в именах файлов Unix, см. Примечание 1.
См. Звезда (глиф) для многих символов, похожих на звездочку, разрешенных в именах файлов.
:толстая кишкаИспользуется для определения точки монтирования / диска в Windows; используется для определения виртуального устройства или физического устройства, такого как диск в AmigaOS, RT-11 и VMS; используется в качестве разделителя пути в классической Mac OS . Удваивается после имени в VMS, указывает имя узла DECnet (эквивалентно имени хоста NetBIOS [Windows networking], которому предшествует \\.) Двоеточие также используется в Windows для отделения альтернативного потока данных от основного файла.
Буква двоеточия ꞉ (U+A789) и символ отношения ∶ (U+2236) разрешены в именах файлов Windows. В шрифте Segoe UI , используемом в проводнике Windows , глифы для двоеточия и буквы двоеточия идентичны.
|вертикальная планка
или труба		Обозначает программную конвейеризацию в Unix, DOS и Windows; разрешено в именах файлов Unix, см. Примечание 1. Математический оператор деления ∣ (U+2223) разрешен в именах файлов Windows.
"прямая двойная кавычкаОграничение, унаследованное от DOS. Одинарные кавычки ' (U+0027), ' (U+2018) и ' (U+2019) и изогнутые двойные кавычки левая двойная кавычка “ (U+201C) и правая двойная кавычка ” (U+201D) разрешены в любом месте имен файлов. См. Примечание 1.
<меньше, чемИспользуется для перенаправления ввода , разрешено в именах файлов Unix, см. Примечание 1. Модификатор пробела в виде левой стрелки ˂ (U+02C2) разрешен в именах файлов Windows.
>больше чемИспользуется для перенаправления вывода , разрешено в именах файлов Unix, см. Примечание 1. Модификатор пробела в виде стрелки вправо ˃ (U+02C3) разрешен в именах файлов Windows.
.точка
или точка		Имена папок не могут заканчиваться точкой в ​​Windows, хотя имя может заканчиваться точкой, за которой следует пробельный символ, такой как неразрывный пробел . В других местах точка разрешена, но последнее вхождение будет интерпретироваться как разделитель расширения в VMS, DOS и Windows. В других ОС обычно рассматривается как часть имени файла, и может быть разрешено более одной точки (точки). В Unix начальная точка означает, что файл или папка обычно скрыты.
,запятаяРазрешено, но рассматривается как разделитель интерпретаторами командной строки COMMAND.COM и CMD.EXE в DOS и Windows.
;точка с запятойРазрешено, но рассматривается как разделитель интерпретаторами командной строки Bourne shell (и совместимыми) и C shell (и совместимыми) в Unix-подобных системах, а также COMMAND.COM и CMD.EXE в DOS и Windows. См. Примечание 1.
=знак равенстваРазрешено, но рассматривается как разделитель интерпретаторами командной строки COMMAND.COM и CMD.EXE в DOS и Windows.
космос
Разрешено, но пробел также используется как разделитель параметров в приложениях командной строки ; см. Примечание 1.

Примечание 1: Хотя они разрешены в именах файлов и папок Unix, большинство оболочек Unix требуют, чтобы определенные символы, такие как пробелы, <, >, |, \ и иногда :, (, ), &, ;, #, а также подстановочные знаки, такие как ? и *, были заключены в кавычки или экранированы :

five\ and\ six\<seven(пример экранирования)
'five and six<seven'или "five and six<seven"(примеры цитирования)

Символ å ( 0xE5) не допускался в качестве первой буквы в имени файла в 86-DOS и MS-DOS/PC DOS 1.x-2.x, но мог использоваться в более поздних версиях.

В утилитах Windows пробел и точка не допускаются в качестве последнего символа имени файла. [19] Точка допускается в качестве первого символа, но некоторые приложения Windows, такие как Windows Explorer , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая затем автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем из приложения. [20]

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

В Unix-подобных системах, DOS и Windows, имена файлов "." и ".." имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98/ME также использует имена типа "...", "...." и т. д. для обозначения родительских или прародительских каталогов. [21] Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек ("...") или более, являются допустимыми в Unix.

Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. [20] Например, файлы устройств DOS : [22]

CON, CONIN$, CONOUT$, PRN, AUX, CLOCK$, NULCOM0, COM1, COM2, COM3, COM4, ​​COM5, COM6, COM7, COM8, COM9 [8]
LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 [8]
LST (только в 86-DOS и DOS 1.xx)KEYBD$, SCREEN$ (только в многозадачном MS-DOS 4.0 )$IDLE$ (только в Concurrent DOS 386 , Multiuser DOS и DR DOS 5.0 и выше)CONFIG$ (только в MS-DOS 7.0-8.0)

Системы, имеющие эти ограничения, вызывают несовместимость с некоторыми другими файловыми системами. Например, Windows не сможет обрабатывать или выдавать отчеты об ошибках для следующих допустимых имен файлов UNIX: aux.c, [23] q"uote"s.txt или NUL.txt.

Имена файлов NTFS, используемые внутри системы, включают:

$Mft, $MftMirr, $LogFile, $Volume, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure,$Upcase, $Extend, $Quota, $ObjId и $Reparse

Сравнение ограничений имен файлов

Система
С учетом регистра
Сохранение дела		Разрешенный набор символовЗарезервированные символыЗарезервированные словаМаксимальная длина (символов)Комментарии
8-битный FAT-файл??7-битный ASCII (но хранится в виде байтов)Первый символ не может быть 0x00 или 0xFF9Максимальное базовое имя для последовательных файлов (без расширения) составляет 9 символов, а для двоичных файлов — 6 и 3 символа расширения; см. 6.3 Имя файла
FAT12 , FAT16 , FAT32НетНетлюбая кодовая страница OEM SBCS / DBCS 0x00–0x1F 0x7F " * / : < > ? \ | + , . ; = [ ](в некоторых средах также: ! @; DOS 1/2 не допускал 0xE5 в качестве первого символа)Имена устройств, включая: $IDLE$ AUX COM1...COM4 CON CONFIG$ CLOCK$ KEYBD$ LPT1...LPT4 LST NUL PRN SCREEN$ (в зависимости от AVAILDEVстатуса везде или только в виртуальном \DEV\каталоге)11Максимальное количество символов в базовом имени — 8, а в расширении — 3; см. 8.3 Имя файла
ВФАТНетДаUnicode , использующий кодировку UCS-20x00–0x1F 0x7F " * / : < > ? \ |255
эксFATНетДаUnicode , использующий кодировку UTF-160x00–0x1F 0x7F " * / : < > ? \ |255
NTFSНеобязательныйДаUnicode , использующий кодировку UTF-160x00–0x1F 0x7F " * / : < > ? \ |Только в корневом каталоге: $AttrDef $BadClus $Bitmap $Boot $LogFile $MFT $MFTMirr pagefile.sys $Secure $UpCase $Volume $Extend $Extend\$ObjId $Extend\$Quota $Extend\$Reparse ($Extend — это каталог)255Длина пути может составлять до 32 000 символов.

Запрещает использование символов в диапазоне 1–31 (0x01–0x1F) и символов " * / : < > ? \ |, если имя не помечено как принадлежащее пространству имен Posix. NTFS допускает длину каждого компонента пути (каталога или имени файла) 255 символов [ сомнительно – обсудить ] .

Windows запрещает использование имен устройств MS-DOS AUX, COM0, ..., COM9, COM¹, ..., COM³, CON, LPT0, ..., LPT9, LPT¹, ..., LPT³, NUL и PRN. Эти имена с расширением (например, AUX.txt) разрешены, но не рекомендуются. [24] Win32 API удаляет конечную точку (точку), а также начальные и конечные пробелы из имен файлов, за исключением случаев, когда используются пути UNC. Эти ограничения применяются только к Windows; в дистрибутивах Linux, поддерживающих NTFS, имена файлов записываются с использованием пространства имен Posix NTFS, которое допускает любые символы Unicode, кроме / и NUL.

OS/2 HPFSНетДалюбой 8-битный набор|\?*<":>/254
Mac OS HFSНетДалюбой 8-битный набор:255старые версии Finder ограничены 31 символом
ХФС+НеобязательныйДаUnicode , использующий кодировку UTF-16: на диске, в классической Mac OS и на уровне Carbon в macOS; / на уровне Unix в macOS255Mac OS 8.1 - macOS
АПФСНеобязательныйДаUnicode , использующий кодировку UTF-8 [25]В Finder можно создавать имена файлов, содержащие /, но / сохраняется в файловой системе как двоеточие ( : ) и отображается как таковой в командной строке. Имена файлов, содержащие : , созданные из командной строки, отображаются с / вместо : в Finder, поэтому невозможно создать файл, который Finder отображает как имеющий : в своем имени.255macOS Sierra (10.12.4) и более поздние версии, iOS 10.3 и более поздние версии, tvOS 10.2 и более поздние версии, watchOS 3.2 и более поздние версии, iPadOS
большинство файловых систем UNIXДаДалюбой 8-битный набор/ нулевой255точка в начале указывает на то, что lsи файловые менеджеры не будут отображать файл по умолчанию
Классическая файловая система MVS z/OS (наборы данных)НетНетКодовые страницы EBCDICкроме $ # @ - x'C0'44Первый символ должен быть буквенным или национальным ($, #, @)

«Квалифицированный» содержит .после каждых 8 символов или меньше. [2] Разделенные наборы данных (PDS или PDSE) делятся на элементы с именами длиной до 8 символов; имя элемента помещается в скобках после имени PDS, напримерPAYROLL.DEV.CBL(PROG001)

Файловая система CMSНетНетКодовые страницы EBCDIC8 + 8Одноуровневая структура каталогов с буквами дисков (A–Z). Имя файла максимум из 8 символов с типом файла максимум из 8 символов, разделенных пробелом. Например, файл TEXT с именем MEMO на диске A будет доступен как "MEMO TEXT A". (Более поздние версии VM представили иерархические структуры файловых систем, SFS и BFS, но исходная структура плоского каталога "минидиск" по-прежнему широко используется.)
ранний UNIX ( корпорация AT&T )ДаДалюбой 8-битный набор/14начальная точка указывает на «скрытый» файл
POSIX «Полностью переносимые имена файлов» [26]ДаДаA–Z a–z 0–9 . _ -/ нулевой14Дефис не должен быть первым символом. Утилита командной строки, проверяющая соответствие, "pathchk", является частью стандарта IEEE 1003.1 и спецификаций Open Group Base [27]
ИСО 9660Нет?А–Я 0–9 _ ."близко к 180"(Уровень 2) или 200(Уровень 3)Используется на компакт-дисках; максимум 8 уровней каталогов (для уровня 1, а не для уровня 2, 3)
Амига ОФСНетДалюбой 8-битный набор: / нулевой30Оригинальная файловая система 1985 г.
Амига FFSНетДалюбой 8-битный набор: / нулевой30Быстрая файловая система 1988
Амига ПФСНетДалюбой 8-битный набор: / нулевой107Профессиональная файловая система 1993 г.
Амига SFSНетДалюбой 8-битный набор: / нулевой107Интеллектуальная файловая система 1998
Амига FFS2НетДалюбой 8-битный набор: / нулевой107Быстрая файловая система 2 2002
BeOS BFSДаДаUnicode , использующий кодировку UTF-8/255
ДЕК ПДП-11 РТ-11НетНетРАДИКС-506 + 3Плоская файловая система без подкаталогов. Полная «спецификация файла» включает устройство, имя файла и расширение (тип файла) в формате: dev:filnam.ext.
DEC VAX VMSНетИз
версии 7.2		A–Z 0–9 $ - _32 на компонент; ранее 9 на компонент; в последнее время 255 для имени файла и 32 для расширения.Полная «спецификация файла» включает в себя имя узла, имя диска, каталог(и), имя файла, расширение и версию в следующем формате: OURNODE::MYDISK:[THISDIR.THATDIR]FILENAME.EXTENSION;2Каталоги могут иметь только 8 уровней вложенности.
Коммодор DOSДаДалюбой 8-битный набор:, =$16длина зависит от привода, обычно 16
250 л.с.ДаДалюбой 8-битный наборSPACE ", : NULL CHR$(255)6Диски и ленточные накопители адресуются либо с помощью метки (до 8 символов), либо спецификации блока. Файловая система HP 250 не использует каталоги и не использует расширения для указания типа файла. Вместо этого тип является атрибутом (например, DATA, PROG, BKUP или SYST для файлов данных, программных файлов, резервных копий и самой ОС). [28]

Смотрите также

Ссылки

  1. ^ Дэвид А. Уилер (22 августа 2023 г.). «Исправление имен файлов Unix/Linux/POSIX: управляющие символы (такие как новая строка), начальные тире и другие проблемы». Архивировано из оригинала 25 мая 2024 г. Получено 14 июля 2024 г.
  2. ^ abcd "Правила именования наборов данных". z/OS TSO/E Руководство пользователя . IBM.
  3. ^ «Соглашения об именовании наборов данных». z/OS TSO/E Руководство пользователя . IBM.
  4. ^ Протокол передачи файлов (FTP). doi : 10.17487/RFC0959 . RFC 959.
  5. ^ "CPM - Формат диска и файловой системы CP/M".
  6. ^ "Страница описания команды Fsutil". Microsoft.com. Архивировано из оригинала 6 октября 2013 г. Получено 15 сентября 2013 г.
  7. ^ "NTFS Hard Links, Directory Junctions, and Windows Shortcuts". Flex hex . Inv Softworks. Архивировано из оригинала 11 июля 2011 г. Получено 12 марта 2011 г.
  8. ^ abcd "Именование файлов, путей и пространств имен". 15 декабря 2022 г. Получено 8 октября 2023 г.
  9. ^ «Ограничение максимальной длины пути — приложения Win32». 18 июля 2022 г.
  10. ^ abcde Дэвид Робинсон; Иенуп Санг; Николас Уильямс (март 2006 г.). "Презентации Solaris: файловые системы, Unicode и нормализация" (PDF) . Сан-Франциско: Sun.com. Архивировано из оригинала (PDF) 4 июля 2012 г.
  11. ^ "Имена файлов с акцентами". Нед Батчелдер. Июнь 2011 г. Получено 17 сентября 2013 г.
  12. ^ "NonNormalizingUnicodeCompositionAwareness - Subversion Wiki". Wiki.apache.org. 21 января 2013 г. Получено 8 октября 2023 г.
  13. ^ "File Name Encoding Repair Utility v1.0". Support.apple.com. 1 июня 2006 г. Получено 2 октября 2018 г.
  14. ^ "convmv - преобразует имена файлов из одной кодировки в другую". J3e.de . Получено 17 сентября 2013 г. .
  15. ^ "Re: git на MacOSX и файлы с разложенными именами файлов utf-8". KernelTrap. 7 мая 2010 г. Архивировано из оригинала 15 марта 2011 г. Получено 5 июля 2010 г.
  16. ^ "Кроссплатформенные соглашения об именовании путей к файлам - Общее программирование". GameDev.net . Получено 8 октября 2023 г. .
  17. ^ "CaseInsensitiveFilenames - The Official Wine Wiki". Wiki.winehq.org. 8 ноября 2009 г. Архивировано из оригинала 18 августа 2010 г. Получено 20 августа 2010 г.
  18. ^ "The Open Group Base Specifications Issue 6". IEEE Std 1003.1-2001 . The Open Group. 2001.
  19. ^ "Windows Naming Conventions". MSDN , Microsoft.com. См. последний маркированный пункт.
  20. ^ ab Именование файла msdn.microsoft.com (MSDN), ограничения на имена файлов в Windows
  21. ↑ Microsoft Windows 95 README для советов и рекомендаций, Microsoft, архивировано из оригинала 1 ноября 2014 г.
  22. ^ Имена драйверов устройств MS-DOS не могут быть использованы в качестве имен файлов, Microsoft , архивировано из оригинала 20 марта 2014 г.
  23. ↑ Риттер, Гуннар (30 января 2007 г.). «Сказка о «aux.c»». Семейный проект .
  24. ^ alvinashcraft (26 февраля 2024 г.). «Именование файлов, путей и пространств имен — приложения Win32». learn.microsoft.com . Получено 11 июня 2024 г. .
  25. ^ "Справочник по файловой системе Apple" (PDF) . Apple Inc.
  26. ^ Левин, Дональд. Руководство программиста POSIX: написание переносимых программ UNIX 1991 O'Reilly & Associates, Inc. Севастополь, Калифорния, стр. 63–64
  27. ^ pathchk - проверка путей
  28. ^ Компания Hewlett-Packard Roseville, CA HP 250 Syntax Reference Rev 1/84 Руководство по эксплуатации Номер детали 45260-90063
Найдите имя  или имена файлов в Викисловаре, бесплатном словаре.
  • Библиотека расширений файлов
  • FILExt
  • WikiExt — Энциклопедия расширений файлов
  • «Именование файлов, путей и пространств имен». Microsoft Docs . 15 декабря 2022 г.
  • Набор символов для переносимых имен файлов POSIX 2009 г.
  • Стандарт ECMA-208, декабрь 1994 г., Системно-независимый формат данных
  • Лучшие практики именования файлов, США: библиотеки Стэнфордского университета , службы управления данными, архивировано с оригинала 30 июля 2021 г.
Получено с "https://en.wikipedia.org/w/index.php?title=ИмяФайла&oldid=1269238099"