Имя файла или имя файла — это имя, используемое для уникальной идентификации компьютерного файла в файловой системе . Различные файловые системы накладывают разные ограничения на длину имен файлов.
Имя файла может (в зависимости от файловой системы) включать:
.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 файлы идентифицировались по
В операционных системах OS/VS1 , MVS и OS/390 от IBM имя файла имело длину до 44 символов и состояло из заглавных букв, цифр и точки. Имя файла должно начинаться с буквы или цифры, точка должна встречаться хотя бы один раз каждые 8 символов, в имени не должно быть двух последовательных точек и должно заканчиваться буквой или цифрой. [1] По соглашению буквы и цифры перед первой точкой обозначали номер счета владельца или проекта, к которому он принадлежал, но не было никаких требований использовать это соглашение. [2]
В системе MUSIC/SP Университета Макгилла имена файлов состояли из
В операционной системе Univac VS/9 имена файлов состояли из
В 1985 году RFC 959 официально определил путь как строку символов, которую пользователь должен ввести в файловую систему для идентификации файла. [3]
На первых персональных компьютерах , использующих операционную систему CP/M , имена файлов всегда состояли из 11 символов. Это называлось именем файла 8.3 с максимальным именем 8 байт и расширением максимум 3 байта. Утилиты и приложения позволяли пользователям указывать имена файлов без конечных пробелов и включать точку перед расширением. На самом деле точка не хранилась в каталоге. Использование только 7-битных символов позволило включить несколько атрибутов файла в фактическое имя файла с использованием старшего бита; эти атрибуты включали «Только для чтения», «Архив» и «Система». [4] В конечном итоге это стало слишком ограничительным, и количество разрешенных символов увеличилось. Биты атрибутов были перенесены в специальный блок файла, включающий дополнительную информацию. [ нужна цитата ]
Исходная файловая система таблицы размещения файлов (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 году VFAT , расширение файловой системы MS-DOS FAT, было представлено в Windows 95 и Windows NT . Он позволял использовать длинные имена файлов (LFN) в смешанном регистре с использованием символов Юникода в дополнение к классическим именам «8.3».
Абсолютная ссылка включает все уровни каталогов. В некоторых системах ссылка на имя файла, не включающая полный путь к каталогу, по умолчанию указывает на текущий рабочий каталог . Это относительная ссылка. Одним из преимуществ использования относительной ссылки в файлах конфигурации программы или сценариях является то, что разные экземпляры сценария или программы могут использовать разные файлы.
Это создает абсолютный или относительный путь, состоящий из последовательности имен файлов.
Unix-подобные файловые системы позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix имена представляют собой жесткие ссылки на индексный дескриптор файла или его эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команду fsutilв Windows XP и mklinkболее поздних версиях для их создания. [5] [6] Жесткие ссылки отличаются от ярлыков Windows , классических псевдонимов Mac OS/macOS или символических ссылок . Введение LFN с VFAT позволило использовать псевдонимы имен файлов. Например, longfi~1.???псевдоним имени файла, содержащий максимум восемь плюс три символа, был « long file name.???» как способ соответствовать ограничениям 8.3 для старых программ.
Это свойство использовалось алгоритмом команды перемещения, который сначала создает второе имя файла, а затем удаляет только первое имя файла.
Другие файловые системы по своей конструкции предоставляют только одно имя файла для каждого файла, что гарантирует, что изменение файла с одним именем файла не приведет к изменению файла с другим именем.
Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эти длины применяются ко всему имени файла, например, в IBM z/OS 44 символа . [1] В других случаях ограничения длины могут применяться к определенным частям имени файла, например имени файла в каталоге или имени каталога. Например, 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), [1] или 255 (например, ранняя версия Berkeley Unix) символов или байтов. Ограничения на длину часто возникают в результате выделения фиксированного пространства в файловой системе для хранения компонентов имен, поэтому увеличение ограничений часто требует несовместимых изменений, а также резервирования большего пространства.
Особая проблема с файловыми системами, которые хранят информацию во вложенных каталогах, заключается в том, что может оказаться возможным создать файл с полным путем, превышающим ограничения реализации, поскольку проверка длины может применяться только к отдельным частям имени, а не ко всему имени. Многие приложения Windows ограничены значением MAX_PATH260, но имена файлов Windows могут легко превысить это ограничение. [7] В Windows 10 версии 1607 ограничения MAX_PATH были удалены. [8]
Имена файлов в некоторых файловых системах, таких как FAT и уровни ODS-1 и ODS-2 в Files-11 , состоят из двух частей: базового имени или основы и расширения или суффикса , используемого некоторыми приложениями для обозначения типа файла . Некоторые другие файловые системы, такие как файловые системы Unix , VFAT и NTFS , рассматривают имя файла как одну строку; соглашение, часто используемое в этих файловых системах, заключается в том, чтобы рассматривать символы, следующие за последней точкой в имени файла, в имени файла, содержащем точки, как часть расширения имени файла.
Несколько выходных файлов, созданных приложением, могут использовать одно и то же базовое имя и различные расширения. Например, компилятор Фортрана может использовать расширение FORдля исходного входного файла, OBJдля вывода объекта и LSTдля листинга. Хотя существуют некоторые общие расширения, они произвольны, и другое приложение может использовать RELи RPT. Расширения были ограничены, по крайней мере исторически в некоторых системах, длиной в 3 символа, но в целом могут иметь любую длину, например, html.
Общего стандарта кодирования имен файлов не существует.
Имена файлов должны обмениваться между программными средами для сетевой передачи файлов, хранения файловой системы, программного обеспечения для резервного копирования и синхронизации файлов, управления конфигурацией, сжатия и архивирования данных и т. д. Поэтому очень важно не потерять информацию об именах файлов между приложениями. Это привело к широкому принятию Unicode в качестве стандарта для кодирования имен файлов, хотя устаревшее программное обеспечение могло не поддерживать Unicode.
Традиционно имена файлов допускали использование любых символов в именах файлов, если они безопасны для файловой системы. [9] Хотя это позволяло использовать любую кодировку и, таким образом, позволяло представлять любой локальный текст в любой локальной системе, это вызывало множество проблем с совместимостью.
Имя файла может храниться с использованием разных байтовых строк в разных системах в пределах одной страны, например, если в одной используется японская кодировка Shift JIS , а другая — японская кодировка EUC . Преобразование было невозможно, поскольку большинство систем не отображали описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это приводило к дорогостоящему угадыванию кодировки имени файла при каждом доступе к файлу. [9]
Решением было использование Unicode в качестве кодировки имен файлов.
Однако в классической Mac OS кодировка имени файла сохранялась с помощью атрибутов имени файла. [9]
Стандарт Unicode решает проблему определения кодировки.
Тем не менее, остаются некоторые ограниченные проблемы совместимости, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничен Unicode 2.0; Файловая система HFS+ в macOS применяет нормализацию Unicode NFD и может быть чувствительна к регистру (по умолчанию нечувствительна к регистру). Максимальная длина имени файла не является стандартной и может зависеть от размера кодовой единицы. Хотя это серьезная проблема, в большинстве случаев она носит ограниченный характер. [9]
В Linux это означает, что имени файла недостаточно для открытия файла: кроме того, необходимо точное байтовое представление имени файла на устройстве хранения. Эту проблему можно решить на уровне приложения с помощью некоторых хитрых вызовов нормализации. [10]
Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является ненормализующая функция распознавания композиции Unicode, используемая в технических сообществах Subversion и Apache. [11] Это решение не нормализует пути в репозитории. Пути нормализуются только для целей сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запретив ее использование другими сообществами. [ нужны разъяснения ]
Чтобы ограничить проблемы совместимости, Sun предлагает следующие идеи:
Эти соображения создают ограничение, не позволяющее переключиться на будущую кодировку, отличную от UTF-8.
Одной из проблем был переход на Unicode. С этой целью несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для перевода имен файлов в новую кодировку Unicode.
Mac OS X 10.3 ознаменовала принятие Apple разложения символов Unicode 3.2, заменяющего используемое ранее разложение Unicode 2.1. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X. [14]
В пределах одного каталога имена файлов должны быть уникальными. Поскольку синтаксис имени файла также применим к каталогам, невозможно создать файлы и записи каталогов с одинаковым именем в одном каталоге. Несколько файлов в разных каталогах могут иметь одно и то же имя.
Подход к уникальности может отличаться как по чувствительности к регистру, так и по форме нормализации Unicode, такой как NFC, NFD. Это означает, что могут быть созданы два отдельных файла с одинаковым текстовым именем и разной байтовой реализацией имени файла, например L"\x00C0.txt" (UTF-16, NFC) (латинская заглавная буква A с могилой) и L"\x0041 \x0300.txt" (UTF-16, NFD) (латинская заглавная буква A, объединение могил). [15]
Некоторые файловые системы, такие как 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 , которое должно эффективно взаимодействовать как с системами, которые рассматривают файлы верхнего и нижнего регистра как разные, так и с системами, которые обрабатывают их одинаково. [16]
Файловые системы не всегда предоставляют один и тот же набор символов для составления имени файла. До того, как Unicode стал стандартом де-факто, файловые системы в основном использовали набор символов, зависящий от локали. Напротив, некоторые новые системы допускают, чтобы имя файла состояло практически из любого символа репертуара Unicode и даже из некоторых последовательностей байтов, не входящих в Unicode. Ограничения могут налагаться файловой системой, операционной системой, приложением или требованиями совместимости с другими системами.
Многие утилиты файловой системы запрещают появление управляющих символов в именах файлов. В Unix-подобных файловых системахнулевой символ [17] и разделитель пути /запрещены.
Утилиты файловой системы и соглашения об именах в различных системах запрещают появление определенных символов в именах файлов или делают их проблематичными: [7] Если не указано иное, символы в столбце «Символ », например « и < , не могут использоваться в именах файлов 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 пробел и точка не могут быть последними символами имени файла. [18] Точка разрешена в качестве первого символа, но некоторые приложения Windows, такие как Windows Explorer , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая впоследствии автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с нужным именем из приложения. [19]
Некоторые файловые системы в конкретной операционной системе (особенно файловые системы, изначально реализованные в других операционных системах) и отдельные приложения в этой операционной системе могут применять дополнительные ограничения и интерпретации. См. сравнение файловых систем для получения более подробной информации об ограничениях.
В Unix-подобных системах, DOS и Windows имена файлов «.» и «..» имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98/ME также использует такие имена, как «...», «...» и т. д. для обозначения родительских или прадедовских каталогов. [20] Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек («...») и более, разрешены в Unix.
Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. [19] Например, файлы устройств DOS : [21]
CON, CONIN$, CONOUT$, PRN, AUX, CLOCK$, NULCOM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 [7] LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 [7] LST (только в 86- ДОС и ДОС 1.хх)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, [22] q"uote"s.txt или NUL.txt.
Имена файлов NTFS, используемые внутри, включают:
$Mft, $MftMirr, $LogFile, $Volume, $AttrDef, $Bitmap, $Boot, $BadClus, $Secure,$Upcase, $Extend, $Quota, $ObjId и $Reparse
