Войти
Снимок экрана командной оболочки Windows, показывающий имена файлов в каталоге 
Список имен файлов с длинными именами файлов, иностранные буквы, запятые, точки и пробелы, как они появляются в программном обеспечении, отображающем имена файлов A имя файла или имя файла - имя, используемое для однозначной идентификации компьютерного файла, хранящегося в файловая система . Различные файловые системы накладывают разные ограничения на длину файлов и допустимые символы в именах файлов.
Имя файла может включать один или несколько из следующих компонентов:
Компоненты, необходимые для идентификации файла, различаются в разных операционных системах, как и синтаксис и формат допустимого имени файла.
Обсуждение имен файлов осложняется отсутствием стандартизации термина. Иногда «имя файла» используется для обозначения полного имени, например, имени Windows c: \ directory \ myfile.txt. Иногда он будет использоваться для ссылки на компоненты, поэтому имя файла в этом случае будет myfile.txt. Иногда это ссылка, исключающая расширение, поэтому имя файла будет просто myfile.
Примерно в это же время появилась точка (точка или точка) в качестве разделителя расширений имени файла, и ограничение до трех буквенных расширений могло происходить из-за ограничений кодировки символов 16-бит RAD50.
Традиционно большинство операционных систем поддерживали имена файлов только с верхним регистром буквенно-цифровые символы, но с течением времени количество разрешенных символов увеличивалось. Это приводило к проблемам совместимости при перемещении файлов между разными файловыми системами.
В 1985 году RFC 959 официально определил путь как строку символов, которая должна быть введена в файловую систему пользователем. для идентификации файла.
Примерно в 1995 г. VFAT, расширение файловой системы MS-DOS FAT, было введено в Windows 95 и Windows NT. Он допускал использование длинных имен файлов (LFN) в смешанном регистре Юникода в дополнение к классическим именам "8.3".
Одной из проблем был переход на Unicode. Для этой цели несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для переноса имен файлов в новую кодировку Unicode.
Mac OS X 10.3 ознаменовала принятие Apple декомпозиции символов Unicode 3.2, заменившей использовавшуюся ранее декомпозицию Unicode 2.1. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X.
Абсолютные ссылки включают все уровни каталогов. В некоторых системах ссылка на имя файла, которая не включает полный путь к каталогу, по умолчанию указывает на текущий рабочий каталог. Это относительная ссылка. Одним из преимуществ использования относительной ссылки в файлах конфигурации программы или сценариях является то, что разные экземпляры сценария или программы могут использовать разные файлы.
Таким образом абсолютный или относительный путь состоит из последовательности имён файлов.
Unix-подобные файловые системы позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix это имена жестких ссылок на индексный дескриптор файла или его эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команду fsutilв Windows XP и mklinkв более поздних версиях для их создания. Жесткие ссылки отличаются от ярлыков Windows , классических Mac OS / macOS псевдонимов или символических ссылок. Введение LFN с VFAT позволило использовать псевдонимы файлов. Например, longfi ~ 1. ???с максимум восемью плюс тремя символами был псевдонимом имени файла «длинное имя файла. ???» как способ соответствия 8.3 ограничения для старых программ.
Это свойство использовалось алгоритмом команды перемещения, который сначала создает второе имя файла, а затем удаляет только первое имя файла.
Другие файловые системы, по замыслу, предоставляют только одно имя файла для каждого файла, что гарантирует, что изменение файла с одним именем файла не изменит файл с другим именем.
Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эта длина применяется ко всему имени файла, например, 44 символа в IBM S / 370. В других случаях ограничения длины могут применяться к определенным частям имени файла, таким как имя файла в каталоге или имя каталога. Например, 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 могут легко превысить этот предел [1].
Многие файловые системы, включая FAT, NTFS и VMS разрешают расширение имени файла , которое состоит из одного или нескольких символов, следующих за последней точкой в имени файла, разделение имени файла на две части: базовое имя или основу и расширение или суффикс, используемый некоторыми приложениями для обозначения типа файла . Несколько выходных файлов, созданных приложением, используют одно и то же базовое имя и разные расширения. Например, компилятор может использовать расширение FORдля исходного входного файла (для кода Fortran), OBJдля вывода объекта и LSTдля листинга. Хотя есть некоторые общие расширения, они произвольны, и другое приложение может использовать RELи RPT. В файловых системах, которые не разделяют расширения, файлы часто имеют более длинные расширения, такие как html.
Не существует общего стандарта кодирования для имен файлов.
Поскольку имена файлов должны обмениваться между программными средами (например, передача файлов по сети, хранилище файловой системы, программное обеспечение для резервного копирования и синхронизации файлов, управление конфигурацией, сжатие и архивирование данных и т. Д.), Очень важно не терять информацию об имени файла между приложениями. Это привело к широкому внедрению Unicode в качестве стандарта для кодирования имен файлов, хотя устаревшее программное обеспечение могло не поддерживать Unicode.
Традиционно, имена файлов допускали использование любых символов в именах файлов, если они были безопасными для файловой системы. Хотя это позволяло использовать любую кодировку и, таким образом, позволяло представлять любой локальный текст в любой локальной системе, это вызывало множество проблем совместимости.
Имя файла может быть сохранено с использованием разных байтовых строк в разных системах внутри одной страны, например, если в одной из них используется японская кодировка Shift JIS и японская кодировка EUC. Преобразование было невозможно, так как большинство систем не отображали описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это заставляло дорогостоящее угадывать кодировку имени файла при каждом доступе к файлу.
Решением было принять Unicode в качестве кодировки для имен файлов.
Однако в классической Mac OS кодировка имени файла хранилась с атрибутами имени файла.
Стандарт Unicode решает проблему определения кодировки.
Тем не менее, остаются некоторые ограниченные проблемы совместимости, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничен Unicode 2.0; В файловой системе macOS HFS + применяется нормализация NFD Unicode и, возможно, учитывается регистр (по умолчанию регистр не учитывается). Максимальная длина имени файла нестандартна и может зависеть от размера единицы кода. Хотя это серьезная проблема, в большинстве случаев она ограничена.
В Linux это означает, что имени файла недостаточно для открытия файла: кроме того, точное байтовое представление имени файла на устройстве хранения необходим. Это может быть решено на уровне приложения с помощью некоторых сложных вызовов нормализации.
Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является ненормализующая осведомленность о композиции Unicode, используемая в технических сообществах Subversion и Apache. Это решение не нормализует пути в репозитории. Пути нормализованы только для сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запрещая ее использование другими сообществами.
Чтобы ограничить проблемы взаимодействия, некоторые идеи, описанные Sun, заключаются в следующем:
Эти соображения создают ограничение, не позволяющее переключиться на будущую кодировку, отличную от UTF-8.
В пределах одного каталога имена файлов должны быть уникальными. Поскольку синтаксис имени файла также применяется к каталогам, невозможно создать файлы и записи каталога с одинаковыми именами в одном каталоге. Несколько файлов в разных каталогах могут иметь одно и то же имя.
Подход к уникальности может различаться как в зависимости от регистра, так и в форме нормализации 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).. Большой обратный знак permitted (U + 29F9) разрешен в именах файлов Windows. |
? | вопросительный знак | Используется как подстановочный знак в Unix, Windows и AmigaOS ; отмечает одиночный символ. Допускается в именах файлов Unix, см. Примечание 1.. заглушка голосовой щели ʔ (U + 0294), интерробанг ‽ (U + 203D), перевернутый вопросительный знак ¿(U + 00BF) и двойной вопросительный знак ⁇ (U + 2047) разрешены во всех именах файлов. |
% | процент | Используется как подстановочный знак в RT-11 ; отмечает один символ. Не особо в Windows. |
* | asterisk. или звездочка | Используется как подстановочный знак в Unix, DOS, RT-11, VMS и Windows. Отмечает любую последовательность символов (Unix, Windows, DOS) или любую последовательность символов в базовом имени или расширении (таким образом, "*. *" В DOS означает "все файлы". Разрешено в именах файлов Unix, см. Примечание 1.. Оператор звездочка * (U + 2217) разрешен в именах файлов Windows |
: | двоеточие | Используется для определения точки монтирования / диска в Windows; используется для определения виртуального устройства или физического устройства, такого как диск на AmigaOS, RT-11 и VMS; используется в качестве разделителя путей в классической Mac OS. Удваивается после имени в VMS, указывает имя узла DECnet (эквивалент NetBIOS (Windows сети) имя хоста, которому предшествует "\\".). Двоеточие также используется в Windows для отделения альтернативного потока данных от основного файла.. Буквенное двоеточие ꞉ (U + A789) и символ соотношения ∶ (U + 2236) разрешены в именах файлов Windows. В шрифте Segoe UI, используемом в Проводнике Windows, глифы для двоеточия и буквы двоеточия идентичны. |
| | по вертикали bar. или pipe | Обозначает конвейерную обработку программного обеспечения в Unix, DOS и Windows; разрешено в именах файлов Unix, см. Примечание 1. стоматологический щелчок ǀ (U + 01C0) разрешен в именах файлов Windows. |
" | прямая двойная кавычка | Одинарные кавычки '(U + 0027) и ’(U + 2019) и изогнутые двойные кавычки« (U + 201C) и »(U + 201D) разрешены в любом месте в именах файлов. См. Примечание 1. |
< | меньше чем | Используется для перенаправления ввода, разрешено в именах файлов Unix, см. Примечание 1. |
> | больше чем | Используется для перенаправления output, разрешено в именах файлов Unix, см. Примечание 1. |
. | точка. или точка | Разрешены, но последнее вхождение будет интерпретироваться как разделитель расширений в 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 требуются определенные символы, такие как пробелы, <,>, |, \, а иногда:, (,),,;, #, а также подстановочные знаки, такие как? и *, в кавычки или экранированный :
пять \ и \ шесть \ 'пять и шесть "пять и шесть
Символ 0xE5не разрешался в качестве первой буквы в имени файла в 86-DOS и MS-DOS / PC DOS 1.x- 2.x, но может использоваться в более поздних версиях.
В утилитах Windows пробел и точка не допускаются в качестве последнего символа имени файла. Точка допускается в качестве первого символа, но в некоторых Windows приложения, такие как Проводник Windows, запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки, когда переименование файла (который впоследствии автоматически удаляется) с использованием альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем из приложения.
Некоторые файловые системы в данной операционной системе tem (особенно файловые системы, изначально реализованные в других операционных системах) и определенные приложения в этой операционной системе могут применять дополнительные ограничения и интерпретации. Подробнее об ограничениях см. сравнение файловых систем.
В Unix-подобных системах, DOS и Windows имена файлов "." и ".." имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98 / ME также использует имена типа «...», «....» и т. Д. Для обозначения каталогов прародителей или прародителей. Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек («...») или более, допустимы в Unix.
Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. Например, DOS файлы устройств :
CON, PRN, AUX, CLOCK $, NUL COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 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, q "uote" s.txt или NUL.txt.
Имена файлов NTFS, которые используются внутри, включают:
$ Mft, $ MftMirr, $ LogFile, $ Volume, $ AttrDef, $ Bitmap, $ Boot, $ BadClus, $ Secure, $ Upcase, $ Extend, $ Quota, $ ObjId и $ Reparse
| Система | Регистр. с учетом | Регистр. с сохранением | Допустимый набор символов | Зарезервированные символы | Зарезервированные слова | Максимальная длина (символы) | Комментарии |
|---|---|---|---|---|---|---|---|
| 8-битная FAT | ? | ? | 7-битный ASCII (но хранится в байтах) | первый символ не может быть 0x00 или 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 filename |
| 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 \ $ Повторная обработка ($ Extend - это каталог) | 255 | Пути могут содержать до 32000 символов. Запрещает использование символов в диапазоне 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 | Нет | Y es | любой 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 | первый символ должен быть алфавитным или национальным ($, #, @) "Qualified" содержит | |
| Файловая система CMS | Нет | Нет | Кодовые страницы EBCDIC | 8 + 8 | Одноуровневый каталог структура с дисковыми буквами (A – Z). Имя файла не более 8 символов, тип файла не более 8 символов, разделенных пробелом. Например, текстовый файл с именем MEMO на диске A будет доступен как «MEMO TEXT A». (В более поздних версиях VM были представлены иерархические структуры файловой системы, SFS и BFS, но исходная плоская структура «минидисков» до сих пор широко используется.) | ||
| ранняя UNIX (ATT Corporation ) | Да | Да | любой 8-битный набор | / | 14 | ведущий . указывает на «скрытый» файл | |
| POSIX «Полностью переносимые имена файлов» | Да | Да | A – Z a – z 0–9. _ - | / null | 14 | дефис не должен быть первым символом | |
| ISO 9660 | Нет | ? | A – Z 0–9 _. | «близко к 180» (уровень 2) или 200 (уровень 3) | Используется на компакт-дисках; макс.8 уровней каталогов (для уровня 1, не уровня 2,3) | ||
| Amiga OFS | Нет | Да | любые 8-битные set | : / null | 30 | Исходная файловая система 1985 | |
| Amiga FFS | Нет | Да | любой 8-битный set | : / null | 30 | Fast File System 1988 | |
| Amiga PFS | Нет | Да | любой 8-битный set | : / null | 107 | Профессиональная файловая система 1993 | |
| Amiga SFS | Нет | Да | любой 8-битный набор | : / null | 107 | Smart File System 1998 | |
| Amiga FFS2 | Нет | Да | любой 8-битный набор | : / null | 107 | Fast File System 2 2002 | |
| BeOS BFS | Да | Да | Unicode, с использованием кодировки UTF-8 | / | 255 | ||
| DEC PDP-11 RT-11 | Нет | Нет | RADIX-50 | 6 + 3 | Плоская файловая система с нет субдира. Полная «спецификация файла» включает устройство, имя файла и расширение (тип файла) в формате: dev: filnam.ext. | ||
| DEC VAX VMS | Нет | Начиная с. v7.2 | A – Z 0–9 $ - _ | 32 на компонент; ранее 9 на компонент; в последнее время 255 для имени файла и 32 для расширения. | полная «спецификация файла» включает имя узла, имя диска, каталог / и, имя файла, расширение и версию в формате: OURNODE :: MYDISK: [THISDIR.THATDIR] FILENAME.EXTENSION; 2 Каталоги могут идти только 8 уровни глубокие. | ||
| Commodore DOS | Да | Да | любой 8-битный набор | :, = | $ | 16 | длина зависит от диск, обычно 16 |
| HP 250 | Да | Да | любой 8-битный набор | SPACE ",: NULL CHR $ (255) | 6 | К дискам и ленточным накопителям обращаются либо с помощью метки (до 8 символов), либо с помощью спецификации устройства. Файловая система HP 250 не использует каталоги и не использует расширения для обозначения типа файла. Вместо этого тип является атрибутом (например, DATA, PROG, BKUP или SYST для файлов данных, программных файлов, резервных копий и самой ОС). |
 | Найдите имя файла или имена файлов в Wiktionary, бесплатном словаре. |
.
