Имя файла или имя файла - это имя, используемое для однозначной идентификации компьютерного файла, хранящегося в файловой системе . Разные файловые системы накладывают разные ограничения на длину файлов и допустимые символы в именах файлов.
Имя файла может включать один или несколько из следующих компонентов:
- хост (или сервер ) - сетевое устройство, содержащее файл
- устройство (или диск ) - аппаратное устройство или диск
- каталог (или путь ) - дерево каталогов (например, / usr / bin , \ TEMP , [USR.LIB.SRC] и т. д.)
- file - базовое имя файла
- тип ( формат или расширение ) - указывает тип содержимого файла (например, .txt , .exe , .COM и т. д.)
- версия - номер версии или поколения файла
Компоненты, необходимые для идентификации файла, различаются в зависимости от операционной системы, как и синтаксис и формат допустимого имени файла.
Обсуждение имен файлов осложняется отсутствием стандартизации термина. Иногда «имя файла» используется для обозначения всего имени, например, имени Windows c: \ directory \ myfile.txt . Иногда он будет использоваться для ссылки на компоненты, поэтому имя файла в этом случае будет myfile.txt . Иногда это ссылка, исключающая расширение, поэтому имя файла будет просто myfile .
История [ править ]
![[значок]](/wiki/File:Wiki_letter_w_cropped.svg){kind=small} | Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( Июль 2012 г. ) |
Точка (период или полная остановка) в качестве разделителя расширения имени файла, а также ограничение на три буквы расширение, появилась в 1970 - х годах. Они могли исходить из 16-битных ограничений кодировки символов RAD50 . [ необходима цитата ]
Традиционно большинство операционных систем поддерживало имена файлов только с прописными буквенно-цифровыми символами, но со временем количество допустимых символов увеличивалось. Это приводило к проблемам совместимости при перемещении файлов между разными файловыми системами. [1]
В 1985 году RFC 959 официально определил имя пути как строку символов, которая должна быть введена в файловую систему пользователем для идентификации файла. [2]
Примерно в 1995 году VFAT , расширение файловой системы MS-DOS FAT, было представлено в Windows 95 и Windows NT . Это позволило использовать длинные имена файлов Unicode (LFN) в смешанном регистре в дополнение к классическим именам «8.3».
Перенос Unicode [ править ]
| Этот раздел нуждается в расширении . Вы можете помочь, добавив к нему . ( Июль 2012 г. ) |
Одна из проблем заключалась в переходе на Unicode. С этой целью несколько компаний-разработчиков программного обеспечения предоставили программное обеспечение для перевода имен файлов в новую кодировку Unicode.
- Microsoft предоставила прозрачную для пользователя миграцию в рамках технологии VFAT.
- Apple предоставила «Утилиту восстановления кодировки имен файлов v1.0». [3]
- Сообщество Linux предоставило « convmv ». [4]
Mac OS X 10.3 ознаменовала принятие Apple декомпозиции символов Unicode 3.2, которая заменила использовавшуюся ранее декомпозицию Unicode 2.1. Это изменение вызвало проблемы у разработчиков, пишущих программное обеспечение для Mac OS X. [5]
Ссылки: абсолютные и относительные [ править ]
Абсолютная ссылка включает все уровни каталогов. В некоторых системах ссылка на имя файла, которая не включает полный путь к каталогу, по умолчанию указывает на текущий рабочий каталог . Это относительная ссылка. Одним из преимуществ использования относительной ссылки в файлах конфигурации программы или сценариях является то, что разные экземпляры сценария или программы могут использовать разные файлы.
Таким образом, абсолютный или относительный путь состоит из последовательности имен файлов.
Количество имен в файле [ править ]
Unix-подобные файловые системы позволяют файлу иметь более одного имени; в традиционных файловых системах в стиле Unix имена являются жесткими ссылками на индексный дескриптор файла или его эквивалент. Windows поддерживает жесткие ссылки в файловых системах NTFS и предоставляет команды для их создания fsutilв Windows XP и mklinkболее поздних версиях. [6] [7] Жесткие ссылки отличаются от ярлыков Windows , классических псевдонимов Mac OS / macOS или символических ссылок . Введение LFN с VFAT позволило использовать псевдонимы файлов. Например, longfi ~ 1. ???с максимум восемью плюс тремя символами был псевдоним имени файла « длинное имя файла. ??? » как способ соответствовать ограничениям 8.3 для старых программ.
Это свойство использовалось алгоритмом команды перемещения, который сначала создает второе имя файла, а затем удаляет только первое имя файла.
Другие файловые системы, по замыслу, предоставляют только одно имя файла для каждого файла, что гарантирует, что изменение файла с одним именем файла не повлияет на файл с другим именем.
Ограничения по длине [ править ]
Некоторые файловые системы ограничивают длину имен файлов. В некоторых случаях эта длина применяется ко всему имени файла, например, 44 символа в IBM S / 370. [8] В других случаях ограничения длины могут применяться к определенным частям имени файла, таким как имя файла в каталоге или имя каталога. Например, 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), [8]или 255 (например, ранний Беркли Unix) символов или байтов. Ограничения длины часто возникают из-за выделения фиксированного пространства в файловой системе для хранения компонентов имен, поэтому увеличение ограничений часто требует несовместимого изменения, а также резервирования большего пространства.
Особая проблема с файловыми системами, которые хранят информацию во вложенных каталогах, заключается в том, что можно создать файл с полным путем, превышающим ограничения реализации, поскольку проверка длины может применяться только к отдельным частям имени, а не ко всему имени. Многие приложения Windows ограничены значением MAX_PATH, равным 260, но имена файлов Windows могут легко превысить это ограничение [2] . В Windows 10 версии 1607 ограничения MAX_PATH были сняты. [9]
Расширения имен файлов [ править ]
Многие файловые системы, включая FAT , NTFS , и VMS системы, позволяют расширение имени файла , который состоит из одного или нескольких символов , следующий за последний период в имени файла, разделяя имя файла на две части: базовое имя или стебель и расширение или суффикс используется некоторыми приложениями для указания типа файла . Несколько выходных файлов, созданных приложением, используют одно и то же базовое имя и разные расширения. Например, компилятор может использовать расширение FORдля исходного входного файла (для кода Fortran), OBJдля вывода объекта иLSTдля листинга. Хотя есть несколько распространенных расширений, они произвольны, и другое приложение может использовать RELи RPT. В файловых системах, которые не разделяют расширения, файлы часто имеют более длинные расширения, например html.
Совместимость кодирования [ править ]
Не существует общего стандарта кодировки для имен файлов.
Поскольку имена файлов должны обмениваться между программными средами (например, передача файлов по сети, хранение файловой системы, программное обеспечение для резервного копирования и синхронизации файлов, управление конфигурацией, сжатие и архивирование данных и т. Д.), Очень важно не терять информацию об именах файлов между приложениями. . Это привело к широкому внедрению Unicode в качестве стандарта для кодирования имен файлов, хотя устаревшее программное обеспечение могло не поддерживать Unicode.
Совместимость индикации кодирования [ править ]
Этот раздел, возможно, придется переписать, чтобы он соответствовал стандартам качества Википедии . ( Сентябрь 2012 г. ) |
Традиционно имена файлов допускали использование любых символов в именах файлов, если они были безопасными для файловой системы. [1] Хотя это позволяло использовать любую кодировку и, таким образом, позволяло представлять любой локальный текст в любой локальной системе, это вызывало множество проблем с совместимостью.
Имя файла может быть сохранено с использованием разных байтовых строк в разных системах внутри одной страны, например, если в одной из них используется японская кодировка Shift JIS и другая японская кодировка EUC . Преобразование было невозможно, поскольку большинство систем не отображало описание кодировки, используемой для имени файла, как часть расширенной информации о файле. Это заставляло дорогостоящее угадывать кодировку имени файла при каждом доступе к файлу. [1]
Решением было принять Unicode в качестве кодировки имен файлов.
Однако в классической Mac OS кодировка имени файла сохранялась с атрибутами имени файла. [1]
Совместимость с Unicode [ править ]
Стандарт Unicode решает проблему определения кодировки.
Тем не менее, некоторые ограниченные проблемы совместимости остаются, такие как нормализация (эквивалентность) или используемая версия Unicode. Например, UDF ограничен Unicode 2.0; В файловой системе MacOS HFS + применяется нормализация NFD Unicode и, при необходимости, учитывается регистр (по умолчанию регистр не учитывается). Максимальная длина имени файла нестандартна и может зависеть от размера единицы кода. Хотя это серьезная проблема, в большинстве случаев она носит ограниченный характер. [1]
В Linux это означает, что имени файла недостаточно для открытия файла: кроме того, требуется точное байтовое представление имени файла на устройстве хранения. Это можно решить на уровне приложения с помощью некоторых сложных вызовов нормализации. [10]
Проблема эквивалентности Unicode известна как «конфликт нормализованных имен». Решением является ненормализующая осведомленность о композиции Unicode, используемая в технических сообществах Subversion и Apache. [11] Это решение не нормализует пути в репозитории. Пути нормализованы только для сравнения. Тем не менее, некоторые сообщества запатентовали эту стратегию, запрещая ее использование другими сообществами. [ требуется разъяснение ]
Перспективы [ править ]
Чтобы ограничить проблемы взаимодействия, некоторые идеи, описанные Sun, заключаются в следующем:
- используйте одну кодировку Unicode (например, UTF-8)
- делать прозрачные преобразования кода для имен файлов
- не хранить нормализованные имена файлов
- проверьте каноническую эквивалентность между именами файлов, чтобы избежать двух канонически эквивалентных имен файлов в одном каталоге. [1]
Эти соображения создают ограничение, не позволяющее переключиться на будущую кодировку, отличную от UTF-8.
Уникальность [ править ]
В пределах одного каталога имена файлов должны быть уникальными. Поскольку синтаксис имени файла также применяется к каталогам, невозможно создать файлы и записи каталога с одинаковыми именами в одном каталоге. Несколько файлов в разных каталогах могут иметь одно и то же имя.
Подход уникальности может отличаться как от чувствительности к регистру, так и от формы нормализации Unicode, такой как NFC, NFD. Это означает, что могут быть созданы два отдельных файла с одним и тем же текстовым именем файла и разной байтовой реализацией имени файла, например L "\ x00C0.txt" (UTF-16, NFC) (латинская заглавная A с могилой) и L "\ x0041 \ x0300.txt "(UTF-16, NFD) (латинская заглавная A, объединение могил). [12]
Сохранение регистра букв [ править ]
Некоторые файловые системы, такие как 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 , которые должны эффективно взаимодействовать с обеими системами, которые обрабатывают файлы в верхнем и нижнем регистре как разные, и с системами, которые обрабатывают их одинаково. [13]
Зарезервированные символы и слова [ править ]
Файловые системы не всегда предоставляют одинаковый набор символов для создания имени файла. До того, как Unicode стал стандартом де-факто, файловые системы в основном использовали набор символов, зависящий от локали. Напротив, некоторые новые системы позволяют составлять имя файла практически из любого символа репертуара Unicode и даже некоторых байтовых последовательностей, отличных от Unicode. Ограничения могут быть наложены файловой системой, операционной системой, приложением или требованиями к взаимодействию с другими системами.
Многие утилиты файловой системы запрещают использование управляющих символов в именах файлов. В Unix-подобных файловых системахнулевой символ [14] и разделитель путей /запрещены.
В Windows [ править ]
Утилиты файловой системы и соглашения об именах в Windows запрещают использование определенных символов в именах файлов: [15]
| Характер | Имя | Причина запрета |
|---|---|---|
/ | слэш | Используется в качестве разделителя компонентов имени пути в 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 нельзя использовать пробел и точку в качестве последнего символа имени файла. [16] Точка разрешена в качестве первого символа, но некоторые приложения Windows, такие как Windows Explorer , запрещают создание или переименование таких файлов (несмотря на то, что это соглашение используется в Unix-подобных системах для описания скрытых файлов и каталогов). Обходные пути включают добавление точки при переименовании файла (которая затем автоматически удаляется), использование альтернативных файловых менеджеров , создание файла с помощью командной строки или сохранение файла с желаемым именем файла из приложения. [17]
Некоторые файловые системы в данной операционной системе (особенно файловые системы, изначально реализованные в других операционных системах) и определенные приложения в этой операционной системе могут применять дополнительные ограничения и интерпретации. Подробнее об ограничениях см. Сравнение файловых систем .
В Unix-подобных системах, DOS и Windows имена файлов "." и ".." имеют особое значение (текущий и родительский каталог соответственно). Windows 95/98 / ME также использует такие имена, как «...», «....» и т. Д. Для обозначения каталогов прародителей или прародителей. [18] Все версии Windows запрещают создание имен файлов, состоящих только из точек, хотя имена, состоящие из трех точек («...») или более, допустимы в Unix.
Кроме того, в утилитах Windows и DOS некоторые слова также зарезервированы и не могут использоваться в качестве имен файлов. [17] Например, файлы устройств DOS : [19]
CON, PRN, AUX, CLOCK $, NULCOM0, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9 [20] LPT0, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9 [20] 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, [21] 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 имя файла |
| 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 год | первый символ должен быть буквенным или национальным ($, #, @) «Квалифицированный» содержит не более | |
| Файловая система CMS | Нет | Нет | Кодовые страницы EBCDIC | 8 + 8 | Одноуровневая структура каталогов с буквами дисков (A – Z). Имя файла не более 8 символов и тип файла не более 8 символов, разделенных пробелом. Например, текстовый файл с именем MEMO на диске A будет доступен как «MEMO TEXT A». (В более поздних версиях VM были представлены иерархические структуры файловой системы, SFS и BFS, но исходная плоская структура «минидиск» по-прежнему широко используется.) | ||
| ранний UNIX ( AT&T Corporation ) | да | да | любой 8-битный набор | / | 14 | ведущий . указывает на "скрытый" файл | |
| POSIX «Полностью переносимые имена файлов» [23] | да | да | А – Я а – Я 0–9. _ - | / ноль | 14 | дефис не должен быть первым символом | |
| ISO 9660 | Нет | ? | А – Я 0–9 _. | «около 180» (уровень 2) или 200 (уровень 3) | Используется на компакт-дисках; Максимум 8 уровней каталогов (для уровня 1, а не уровня 2, 3) | ||
| Амига ОФС | Нет | да | любой 8-битный набор | : / ноль | 30 | Исходная файловая система 1985 г. | |
| Амига FFS | Нет | да | любой 8-битный набор | : / ноль | 30 | Быстрая файловая система 1988 | |
| Amiga PFS | Нет | да | любой 8-битный набор | : / ноль | 107 | Профессиональная файловая система 1993 | |
| Амига 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 | А – Я 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 для файлов данных, программных файлов, резервных копий и самой ОС). [24] |
См. Также [ править ]
- Файловая система
- Полное имя файла
- Длинное имя файла
- Путь (вычисления)
- Slug (веб-публикация)
- Символическая ссылка
- Универсальный идентификатор ресурса (URI)
- Единый указатель ресурса (URL) и интернационализированный идентификатор ресурса
Ссылки [ править ]
- ^ a b c d e е Дэвид Робинсон; Иенуп Сун; Николас Уильямс (март 2006 г.). «Презентации Solaris: файловые системы, Unicode и нормализация» (PDF) . Сан-Франциско: Sun.com. Архивировано из оригинального (PDF) 4 июля 2012 года.
- ^ RFC 959 IETF.org RFC 959 , протокол передачи файлов (FTP)
- ^ "Утилита восстановления кодировки имен файлов v1.0" . Support.apple.com. 1 июня 2006 . Проверено 2 октября 2018 года .
- ^ "convmv - преобразует имена файлов из одной кодировки в другую" . J3e.de . Проверено 17 сентября 2013 года .
- ^ «Re: git на MacOSX и файлы с разложенными именами файлов utf-8» . KernelTrap. 7 мая 2010 года Архивировано из оригинального 15 марта 2011 года . Проверено 5 июля 2010 года .
- ^ "Страница описания команды Fsutil" . Microsoft.com . Проверено 15 сентября 2013 года .
- ^ «Жесткие ссылки NTFS, соединения каталогов и ярлыки Windows» . Гибкий шестигранник . Inv Softworks . Проверено 12 марта 2011 года .
- ^ a b «Поддержка ddname с FTP, z / OS V1R11.0 Communications Server IP. Руководство пользователя и команды z / OS V1R10.0-V1R11.0 SC31-8780-09» . IBM.com.
- ^ [1]
- ^ «Имена файлов с акцентами» . Нед Батчелдер . Проверено 17 сентября 2013 года .
- ^ "NonNormalizingUnicodeCompositionAwareness - Subversion Wiki" . Wiki.apache.org. 21 января 2013 . Проверено 17 сентября 2013 года .
- ^ «Соглашения об именах межплатформенных путей к файлам - Общее программирование» . GameDev.net . Проверено 17 сентября 2013 года .
- ^ "CaseInsensitiveFilenames - Официальная вики по Wine" . Wiki.winehq.org. 8 ноября 2009 года Архивировано из оригинального 18 августа 2010 года . Проверено 20 августа 2010 года .
- ^ «Выпуск 6 базовых спецификаций открытой группы» . IEEE Std 1003.1-2001 . Открытая группа. 2001 г.
- ^ «Именование файлов, путей и пространств имен (Windows)» . Msdn.microsoft.com. 26 августа 2013 . Проверено 17 сентября 2013 года .
- ^ «Соглашения об именах Windows» . MSDN , Microsoft.com. См. Последний отмеченный пункт.
- ^ a b Именование файла msdn.microsoft.com (MSDN), ограничения имени файла в Windows
- ^ Microsoft Windows 95 README for Tips and Tricks , Microsoft , получено 27 августа 2015 г.
- ^ Имена драйверов устройств MS-DOS не могут использоваться в качестве имен файлов. , Microsoft
- ^ a b Именование файлов, путей и пространств имен , Microsoft
- ↑ Риттер, Гуннар (30 января 2007 г.). «Сказка о« aux.c » » . Фамильный проект .
- ^ «Определение подпараметра, z / OS V1R11.0 MVS JCL Reference» . IBM.com . Проверено 17 сентября 2013 года .
- ^ Левин, Дональд. Руководство программиста POSIX: Написание переносимых программ UNIX 1991 O'Reilly & Associates, Inc. Севастополь, Калифорния, стр. 63-64
- ^ Hewlett-Packard Company Roseville, CA Справочник по синтаксису HP 250 Ред. 1/84 Руководство Номер детали 45260-90063
Внешние ссылки [ править ]
 | Найдите имя файла или имена файлов в Викисловаре, бесплатном словаре. |
- Форматы данных Имя файла в Curlie
- Библиотека расширений файлов
- FILExt
- WikiExt - энциклопедия расширений файлов
- Именование файлов, путей и пространств имен (MSDN)
- Набор символов переносимого имени файла POSIX 2009 г.
- Стандарт ECMA-208, декабрь 1994 г., системно-независимый формат данных
- Лучшие практики для именования файлов , США: библиотеки Стэнфордского университета , службы управления данными
