Имя файла или имя файла — это имя, используемое для уникальной идентификации файла компьютера в файловой системе . Различные файловые системы накладывают различные ограничения на длину имени файла.
Имя файла может (в зависимости от файловой системы) включать:
.txtдля простого текста ,.pdfдля Portable Document Format ,.datдля неопределенных двоичных данных и т. д.)Компоненты, необходимые для идентификации файла утилитами и приложениями, различаются в разных операционных системах, равно как и синтаксис и формат допустимого имени файла.
Символы, разрешенные в именах файлов, зависят от файловой системы. Буквы 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 файлы идентифицировались по
В операционных системах OS/VS1 , MVS и OS/390 от IBM имя файла могло содержать до 44 символов, состоящих из заглавных букв, цифр и точки. Имя файла должно начинаться с буквы или цифры, точка должна встречаться не реже одного раза на каждые 8 символов, в имени не может быть двух последовательных точек, и имя должно заканчиваться буквой или цифрой. [2] По соглашению буквы и цифры перед первой точкой были номером счета владельца или проекта, к которому он принадлежал, но не было никаких требований использовать это соглашение. [3]
В системе MUSIC/SP Университета Макгилла имена файлов состояли из
Операционная система Univac VS/9 имела имена файлов, состоящие из
В 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. Например, UDF ограничена Unicode 2.0; файловая система HFS+ macOS применяет нормализацию NFD Unicode и опционально чувствительна к регистру (по умолчанию нечувствительна к регистру). Максимальная длина имени файла не является стандартной и может зависеть от размера кодовой единицы. Хотя это серьезная проблема, в большинстве случаев она ограничена. [10]
В Linux это означает, что имени файла недостаточно для открытия файла: кроме того, необходимо точное байтовое представление имени файла на устройстве хранения. Это можно решить на уровне приложения с помощью некоторых сложных вызовов нормализации. [11]
Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является Non-normalizing Unicode Composition Awareness, используемый в технических сообществах Subversion и Apache. [12] Это решение не нормализует пути в репозитории. Пути нормализуются только для целей сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запретив ее использование другими сообществами. [ необходимо разъяснение ]
Чтобы ограничить проблемы взаимодействия, Sun предлагает следующие идеи:
Эти соображения создают ограничение, не позволяющее в будущем перейти на кодировку, отличную от UTF-8.
Одной из проблем была миграция в Unicode. Для этой цели несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для миграции имен файлов в новую кодировку Unicode.
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.
Примечание 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
