Имя файла - Filename

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

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

Имя файла может включать один или несколько из этих компонентов:

  • хост (или сервер ) - сетевое устройство, содержащее файл
  • устройство (или диск ) - аппаратное устройство или диск
  • каталог (или путь ) - дерево каталогов (например, /usr/bin, \TEMP, [USR.LIB.SRC]и т.д.)
  • file - базовое имя файла
  • тип ( формат или расширение ) - указывает тип содержимого файла (например .txt, .exe, .COMи т.д.)
  • версия - номер версии или поколения файла

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

Обсуждение имен файлов осложняется отсутствием стандартизации термина. Иногда «имя файла» используется для обозначения всего имени, например, имени Windows c: \ directory \ myfile.txt . Иногда он будет использоваться для ссылки на компоненты, поэтому имя файла в этом случае будет myfile.txt . Иногда это ссылка, исключающая расширение, поэтому имя файла будет просто myfile .

История

Точка (период или полная остановка) в качестве разделителя расширения имени файла, а также ограничение на три буквы расширение, появилась в 1970 - х годах. Они могли исходить из 16-битных ограничений кодировки символов RAD50 .

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

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

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

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

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

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

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

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

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

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

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

Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эта длина применяется ко всему имени файла, например, 44 символа в IBM S / 370. В других случаях ограничения длины могут применяться к определенным частям имени файла, таким как имя файла в каталоге или имя каталога. Например, 9 (например, 8-битная FAT в автономном диске 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 могут легко превысить это ограничение [2] . В Windows 10 версии 1607 ограничения MAX_PATH были сняты.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перспективы

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

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

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

Миграция Unicode

Одна из проблем заключалась в переходе на 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 , которые должны эффективно взаимодействовать с обеими системами, которые обрабатывают файлы в верхнем и нижнем регистре как разные, и с системами, которые обрабатывают их одинаково.

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

Файловые системы не всегда предоставляют одинаковый набор символов для создания имени файла. До того, как 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), то Interrobang (U + 203d), то перевернутый вопросительный знак ¿ (U + 00BF) и двойной знак вопроса (U + 2047) допускается во всех именах файлов.
% процентов Используется как подстановочный знак в RT-11 ; отмечает одиночный символ. В Windows нет ничего особенного.
* звездочка
или звезда
Используется как подстановочный знак в Unix, DOS, RT-11, VMS и Windows. Marks любая последовательность символов (Unix, Windows, DOS) или любой последовательности символов либо базовое имя или расширение (таким образом , «*. *» В DOS означает «все файлы». Разрешено в Unix именах файлов см Примечание 1 .
См Star ( глиф) для многих символов, подобных звездочке, разрешенных в именах файлов.
: двоеточие Используется для определения точки монтирования / диска в 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 + 01C0) допускается в именах файлов Windows.
" прямая двойная кавычка Одинарные кавычки ' (U + 0027) и ' (U + 2019) и изогнутые двойные кавычки « (U + 201C) и » (U + 201D) разрешены в любом месте в именах файлов. См. Примечание 1 .
< меньше, чем Используется для перенаправления ввода , разрешенного в именах файлов Unix, см. Примечание 1 .
> больше чем Используется для перенаправления вывода , разрешенного в именах файлов Unix, см. Примечание 1 .
. период
или точка
Имена папок не могут заканчиваться точкой в ​​Windows, хотя имя может заканчиваться точкой, за которой следует пробел, например неразрывный пробел . В других местах точка разрешена, но последнее вхождение будет интерпретироваться как разделитель расширений в VMS, DOS и Windows. В других операционных системах это обычно считается частью имени файла, и может быть разрешено более одной точки (точка). В Unix начальная точка означает, что файл или папка обычно скрыты.
, запятая Разрешено, но рассматривается как разделитель интерпретаторами командной строки COMMAND.COM и CMD.EXE в DOS и Windows.
; точка с запятой Разрешено, но рассматривается как разделитель интерпретаторами командной строки COMMAND.COM и CMD.EXE в DOS и Windows.
= знак равенства Разрешено, но рассматривается как разделитель интерпретаторами командной строки COMMAND.COM и CMD.EXE в DOS и 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 нельзя использовать пробел и точку в качестве последнего символа имени файла. Точка разрешена в качестве первого символа, но некоторые приложения Windows, такие как Windows Explorer , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая затем автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем файла из приложения.

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

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

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

CON, 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-битный FAT ? ? 7-битный ASCII (но хранится в байтах) первый символ не может быть 0x00 или 0xFF 9 Максимальный предел базового имени 9 символов для последовательных файлов (без расширения) или максимальное расширение 6 и 3 символа для двоичных файлов; см. 6.3 имя файла
FAT12 , FAT16 , FAT32 Нет Нет любая кодовая страница SBCS / DBCS OEM 0x00-0x1F 0x7F "* /: <>? \ | +,.; = [] (В некоторых средах также:! @; DOS 1/2 не допускает 0xE5 в качестве первого символа) Имена устройств, включая: $ IDLE $ AUX COM1… COM4 CONFIG $ CLOCK $ KEYBD $ LPT1… LPT4 LST NUL PRN SCREEN $ (в зависимости от статуса AVAILDEV везде или только в виртуальном каталоге \ DEV \) 11 Максимальный предел базового имени 8 символов и расширение 3 символа; см. 8.3 имя файла
VFAT Нет да Unicode , используя кодировку UCS-2 0x00-0x1F 0x7F "* /: <>? \ | 255
exFAT Нет да Unicode , используя UTF-16 кодирования 0x00-0x1F 0x7F "* /: <>? \ | 255
NTFS По желанию да Unicode , используя 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, CLOCK $, COM1,…, COM9, CON, LPT1,…, LPT9, NUL и PRN, а также этих имен с любым расширением (например, AUX.txt) , кроме случаев использования длинных путей UNC (например, \\. \ C: \ nul.txt или \\? \ D: \ aux \ con). (CLOCK $ может использоваться, если предоставляется расширение.) Win32 API удаляет конечную точку (точку), а также начальные и конечные символы пробела из имен файлов, за исключением случаев, когда используются пути UNC. Эти ограничения применимы только к Windows; в дистрибутивах Linux, поддерживающих NTFS, имена файлов записываются с использованием пространства имен NTFS Posix, которое допускает любые символы Unicode, кроме / и NUL.

OS / 2 HPFS Нет да любой 8-битный набор | \? * <":> / 254
Mac OS HFS Нет да любой 8-битный набор : 255 старые версии Finder ограничены 31 символом
Mac OS HFS + По желанию да Unicode , используя UTF-16 кодирования : на диске в классической Mac OS и на уровне Carbon в macOS; / на уровне Unix в macOS 255 Mac OS 8.1 - macOS
большинство файловых систем UNIX да да любой 8-битный набор / null 255 ведущий . указывает, что lsи файловые менеджеры не будут отображать файл по умолчанию
z / OS классическая файловая система 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 Corporation ) да да любой 8-битный набор / 14 ведущий . указывает на "скрытый" файл
POSIX "Полностью переносимые имена файлов" да да A – Z a – z 0–9. _ - / ноль 14 дефис не должен быть первым символом. Утилита командной строки, проверяющая соответствие, "pathchk", является частью стандарта IEEE 1003.1 и базовых спецификаций Open Group.
ISO 9660 Нет ? А – Я 0–9 _. «около 180» (уровень 2) или 200 (уровень 3) Используется на компакт-дисках; Максимум 8 уровней каталогов (для уровня 1, а не уровня 2, 3)
Амига ОФС Нет да любой 8-битный набор : / ноль 30 Исходная файловая система 1985 г.
Амига FFS Нет да любой 8-битный набор : / ноль 30 Быстрая файловая система 1988
Amiga PFS Нет да любой 8-битный набор : / ноль 107 Профессиональная файловая система 1993
Amiga SFS Нет да любой 8-битный набор : / ноль 107 Умная файловая система 1998
Амига FFS2 Нет да любой 8-битный набор : / ноль 107 Быстрая файловая система 2 2002
BeOS BFS да да Unicode , используя UTF-8 кодирование / 255
ДЭК ПДП-11 РТ-11 Нет Нет РАДИКС-50 6 + 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
HP 250 да да любой 8-битный набор ПРОБЕЛ ",: NULL CHR $ (255) 6 Диски и ленточные накопители адресуются либо с помощью метки (до 8 символов), либо с помощью спецификации устройства. Файловая система HP 250 не использует каталоги и не использует расширения для обозначения типа файлов. Вместо этого типом является атрибут (например, DATA, PROG, BKUP или SYST для файлов данных, программных файлов, резервных копий и самой ОС).

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

Рекомендации

  1. ^ a b c d e е Дэвид Робинсон; Иенуп Сун; Николас Уильямс (март 2006 г.). «Презентации Solaris: файловые системы, Unicode и нормализация» (PDF) . Сан-Франциско: Sun.com. Архивировано из оригинального (PDF) 4 июля 2012 года.
  2. ^ RFC  959 IETF.org RFC  959 , протокол передачи файлов (FTP)
  3. ^ "Страница описания команды Fsutil" . Microsoft.com . Проверено 15 сентября 2013 года .
  4. ^ «Жесткие ссылки NTFS, соединения каталогов и ярлыки Windows» . Гибкий шестигранник . Inv Softworks . Проверено 12 марта 2011 года .
  5. ^ a b «Поддержка ddname с FTP, z / OS V1R11.0 Communications Server IP. Руководство пользователя и команды z / OS V1R10.0-V1R11.0 SC31-8780-09» . IBM.com.
  6. ^ [1]
  7. ^ «Имена файлов с акцентами» . Нед Батчелдер . Проверено 17 сентября 2013 года .
  8. ^ "NonNormalizingUnicodeCompositionAwareness - Subversion Wiki" . Wiki.apache.org. 21 января 2013 . Проверено 17 сентября 2013 года .
  9. ^ "Утилита восстановления кодировки имен файлов v1.0" . Support.apple.com. 1 июня 2006 . Проверено 2 октября 2018 года .
  10. ^ "convmv - преобразует имена файлов из одной кодировки в другую" . J3e.de . Проверено 17 сентября 2013 года .
  11. ^ «Re: git на MacOSX и файлы с разложенными именами файлов utf-8» . KernelTrap. 7 мая 2010 года Архивировано из оригинального 15 марта 2011 года . Проверено 5 июля 2010 года .
  12. ^ «Соглашения об именах межплатформенных путей к файлам - Общее программирование» . GameDev.net . Проверено 17 сентября 2013 года .
  13. ^ "CaseInsensitiveFilenames - Официальная вики по Wine" . Wiki.winehq.org. 8 ноября 2009 года Архивировано из оригинального 18 августа 2010 года . Проверено 20 августа 2010 года .
  14. ^ «Проблема 6 базовых спецификаций открытой группы» . IEEE Std 1003.1-2001 . Открытая группа. 2001 г.
  15. ^ «Именование файлов, путей и пространств имен (Windows)» . Msdn.microsoft.com. 26 августа 2013 . Проверено 17 сентября 2013 года .
  16. ^ «Соглашения об именах Windows» . MSDN , Microsoft.com. См. Последний отмеченный пункт.
  17. ^ a b Именование файла msdn.microsoft.com (MSDN), ограничения имени файла в Windows
  18. ^ Microsoft Windows 95 README for Tips and Tricks , Microsoft , получено 27 августа 2015 г.
  19. ^ Имена драйверов устройств MS-DOS не могут использоваться в качестве имен файлов. , Microsoft
  20. ^ a b Именование файлов, путей и пространств имен , Microsoft
  21. Риттер, Гуннар (30 января 2007 г.). «Сказка о« aux.c » » . Фамильный проект .
  22. ^ «Определение подпараметра, z / OS V1R11.0 MVS JCL Reference» . IBM.com . Проверено 17 сентября 2013 года .
  23. ^ Левин, Дональд. Руководство программиста POSIX: Написание переносимых программ UNIX 1991 O'Reilly & Associates, Inc. Севастополь, Калифорния, стр. 63-64
  24. ^ pathchk - проверять пути
  25. ^ Hewlett-Packard Company Roseville, CA Справочное руководство по синтаксису HP 250 Ред. 1/84 Номер детали 45260-90063

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