Имя файла

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

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

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

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

• name – базовое имя файла
• расширение – может указывать формат файла (например, .txt для обычного текста , .pdf для формата переносимого документа , .dat для неуказанных двоичных данных и т. д.)

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

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

Имена файлов могут включать такие вещи, как номер версии или поколения файла, например компьютерный код , числовой порядковый номер (широко используемый цифровыми камерами в соответствии со 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 символов (заглавные буквы или цифры)
• необязательное трехзначное расширение.

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

Университета Макгилла В системе 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 официально определил путь как строку символов, которую пользователь должен ввести в файловую систему для идентификации файла.

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

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

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

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

Основная статья: Путь (вычисления)

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

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

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

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

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

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

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

Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эти длины применяются ко всему имени файла, например, в IBM z/OS 44 символа . В других случаях ограничения длины могут применяться к определенным частям имени файла, например имени файла в каталоге или имени каталога. Например, 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), или 255 (например, ранние версии Berkeley Unix) символов или байтов. Ограничения длины часто возникают в результате выделения фиксированного пространства в файловой системе для хранения компонентов имен, поэтому увеличение ограничений часто требует несовместимых изменений, а также резервирования большего пространства.

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

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

Основная статья: Расширение имени файла

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

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

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

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

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

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

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

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

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

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

Совместимость с Юникодом

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

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

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

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

Перспективы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«Зарезервированные персонажи» перенаправляются сюда. О символах, которые нельзя использовать в заголовках страниц Википедии, см. Arc.Ask3.Ru:Соглашения об именах (технические ограничения) § Запрещенные символы .

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

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

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

Утилиты файловой системы и соглашения об именах в различных системах запрещают появление определенных символов в именах файлов или делают их проблематичными: Если не указано иное, символы в столбце «Символ » , « и < например , не могут использоваться в именах файлов 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], которому предшествует \\.) Двоеточие также используется в 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 (и совместимые) и оболочки C (и совместимые) в 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 пробел и точка не могут быть последними символами имени файла. Точка разрешена в качестве первого символа, но некоторые приложения Windows, такие как Проводник Windows , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая впоследствии автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с нужным именем из приложения.

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

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

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

CON, CONIN$, CONOUT$, PRN, AUX, CLOCK$, NUL
COM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9
LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9
LST (only in 86-DOS and DOS 1.xx)
KEYBD$, SCREEN$ (only in multitasking MS-DOS 4.0)
$IDLE$ (only in Concurrent DOS 386, Multiuser DOS and DR DOS 5.0 and higher)
CONFIG$ (only in MS-DOS 7.0-8.0)

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

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

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

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

Основная статья: Сравнение файловых систем

Система	Случай чувствительный	Случай сохранение	Разрешенный набор символов	Зарезервированные персонажи	Зарезервированные слова	Максимальная длина (символов)	Комментарии
8-битная ЖИРА	?	?	7-битный ASCII (но хранится в байтах)	первый символ не может быть 0x00 или 0xFF		9	Максимальное ограничение на базовое имя в 9 символов для последовательных файлов (без расширения) или максимальное расширение в 6 и 3 символа для двоичных файлов; см. имя файла 6.3
ФАТ12 , ФАТ16 , ФАТ32	Нет	Нет	любая SBCS / DBCS OEM-кодовая страница	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
ВФАТ	Нет	Да	Юникод с использованием UCS-2. кодировки	0x00–0x1F 0x7F " * / : < > ? \ |		255
exFAT	Нет	Да	Юникод с использованием UTF-16. кодировки	0x00–0x1F 0x7F " * / : < > ? \ |		255
NTFS	Необязательный	Да	Юникод с использованием UTF-16. кодировки	0x00–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) разрешены, но не рекомендуются. Win32 API удаляет завершающую точку (точку), а также начальные и конечные пробелы из имен файлов, за исключением случаев, когда используются пути UNC. Эти ограничения применимы только к Windows; в дистрибутивах Linux, поддерживающих NTFS, имена файлов записываются с использованием пространства имен Posix NTFS, которое допускает любые символы Юникода, кроме / и NUL.
ОС/2 HPFS	Нет	Да	любой 8-битный набор	|\?*<":>/		254
Mac OS HFS	Нет	Да	любой 8-битный набор	:		255	старые версии Finder ограничены 31 символом
HFS+	Необязательный	Да	Юникод с использованием UTF-16. кодировки	: на диске, в классической Mac OS и на уровне Carbon в macOS; / на уровне Unix в macOS		255	MacOS 8.1 – macOS
АПФС	Необязательный	Да	Юникод с использованием UTF-8. кодировки	В Finder можно создавать имена файлов, содержащие /, но / сохраняется в файловой системе как двоеточие ( :) и отображается как таковое в командной строке. Имена файлов, содержащие :, созданные из командной строки, отображаются в Finder с помощью / вместо : , поэтому невозможно создать файл, который отображается в Finder как имеющий : в имени файла.		255	macOS Sierra (10.12.4) и новее, iOS 10.3 и новее, tvOS 10.2 и новее, watchOS 3.2 и новее, iPadOS
большинство UNIX файловых систем	Да	Да	любой 8-битный набор	/ нулевой		255	ведущий . указывает на то, что ls и файловые менеджеры не будут показывать файл по умолчанию
файловая система z/OS classic MVS (наборы данных)	Нет	Нет	Кодовые страницы EBCDIC	кроме $ # @ - x'C0'		44	первый символ должен быть буквенным или национальным ($, #, @) «Квалифицированный» содержит . после каждых 8 символов или меньше. Секционированные наборы данных (PDS или PDSE) делятся на элементы с именами длиной до 8 символов; имя участника помещается в круглые скобки после имени PDS, например PAYROLL.DEV.CBL(PROG001)
Файловая система CMS	Нет	Нет	Кодовые страницы EBCDIC			8 + 8	Одноуровневая структура каталогов с буквами дисков (A–Z). Имя файла длиной не более 8 символов и тип файла не более 8 символов, разделенные пробелами. Например, к ТЕКСТОВОМу файлу MEMO на диске A можно будет обращаться как к «MEMO TEXT A». (Более поздние версии VM представили иерархические структуры файловой системы, SFS и BFS, но исходная плоская структура каталогов «минидиск» все еще широко используется.)
ранняя UNIX ( корпорация AT&T )	Да	Да	любой 8-битный набор	/		14	ведущий . указывает на «скрытый» файл
POSIX «Полностью переносимые имена файлов»	Да	Да	A–Z a–z 0–9 . _ -	/ нулевой		14	дефис не должен быть первым символом. Утилита командной строки, проверяющая соответствие, «pathchk», является частью стандарта IEEE 1003.1 и открытой группы. базовых спецификаций
ИСО 9660	Нет	?	А–Я 0–9 _ .			«около 180» (уровень 2) или 200 (уровень 3)	Используется на компакт-дисках; Максимум 8 уровней каталогов (для уровня 1, а не для уровней 2,3)
друг ОФС	Нет	Да	любой 8-битный набор	: / нулевой		30	Оригинальная файловая система 1985 г.
друг ФФС	Нет	Да	любой 8-битный набор	: / нулевой		30	Быстрая файловая система 1988 г.
ПФС друг	Нет	Да	любой 8-битный набор	: / нулевой		107	Профессиональная файловая система 1993 г.
Друг СФС	Нет	Да	любой 8-битный набор	: / нулевой		107	Умная файловая система 1998 г.
Друг ФФС2	Нет	Да	любой 8-битный набор	: / нулевой		107	Быстрая файловая система 2 2002 г.
BeOS БФС	Да	Да	Юникод с использованием UTF-8. кодировки	/		255
ДЕК ПДП-11 РТ-11	Нет	Нет	РАДИКС-50			6 + 3	Плоская файловая система без подкаталогов. Полная «спецификация файла» включает устройство, имя файла и расширение (тип файла) в формате: dev:filnam.ext.
Декабрь VAX VMS	Нет	От v7.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 для файлов данных, программных файлов, резервных копий и самой ОС).

См. также

• Файловая система
• Полное имя файла
• Длинное имя файла
• Путь (вычисления)
• Слизень (веб-публикация)
• Символическая ссылка
• Единый идентификатор ресурса (URI)
• Единый указатель ресурса (URL) и интернационализированный идентификатор ресурса.
• Соглашения об именах файлов Windows (Win32) (независимо от файловой системы)

Внешние ссылки

• Имя файла форматов данных в Curlie
• Библиотека расширений файлов
• ФАЙЛExt
• WikiExt — Энциклопедия расширений файлов
• «Именование файлов, путей и пространств имен» . Документы Майкрософт . 15 декабря 2022 г.
• Набор символов переносимого имени файла POSIX 2009 г.
• Стандарт ECMA-208, декабрь 1994 г., системно-независимый формат данных.
• Рекомендации по именованию файлов , США: Библиотеки Стэнфордского университета , Службы управления данными, заархивировано из оригинала 30 июля 2021 г.