Расширение файла: назначение и особенности

Введение

Суффикс имени файла, указывающий на тип файла.

Расширение имени файла, или расширение файла — это суффикс к имени компьютерного файла (например, txt, docx, md). Расширение указывает на характеристику содержимого файла или его предполагаемое назначение. Обычно расширение имени файла отделяется от остальной части имени файла точкой, но в некоторых системах используется пробел. Некоторые файловые системы реализуют расширения имен файлов как функцию самой файловой системы и могут ограничивать длину и формат расширения, в то время как другие рассматривают расширения имен файлов как часть имени файла без какого-либо специального выделения.

Поддержка операционной системы и файловой системы

Файловая система Multics хранит имя файла как единую строку, не разделяя его на имя и расширение, что позволяет использовать точку (".") как обычный символ в имени файла. Она поддерживает имена файлов переменной длины, допускает наличие нескольких точек, а значит, и нескольких суффиксов, а также отсутствие точки, то есть отсутствие суффикса. Некоторые компоненты Multics и приложения, работающие в этой среде, используют суффиксы для обозначения типов файлов, но наличие суффикса не является обязательным для всех файлов — например, исполняемые файлы и обычные текстовые файлы обычно не имеют суффиксов в своих именах. Файловые системы операционных систем, подобных UNIX, также хранят имя файла как единую строку, где точка (".") является обычным символом. Файл с несколькими суффиксами иногда называют файлом с несколькими расширениями, хотя терминология в этом отношении может различаться, и большинство авторов определяют расширение как часть имени файла, не допускающую наличия нескольких расширений. Несколько расширений обычно указывают на вложенные преобразования, например, файлы `tar.gz` (где `tar` указывает, что файл является архивом tar, содержащим один или несколько файлов, а `gz` указывает, что архив tar сжат с помощью gzip). Программы, преобразующие или создающие файлы, могут добавлять соответствующие расширения к именам, полученным из имен входных файлов (если не указано имя выходного файла), но программы, читающие файлы, обычно игнорируют эту информацию, поскольку она предназначена в основном для пользователя. Чаще всего, особенно в бинарных файлах, информация о содержимом файла хранится во внутренних или внешних метаданных. Такая модель обычно требует указания полного имени файла в командах, в то время как подход с использованием метаданных часто позволяет опустить расширение. В DOS и 16-битной Windows имена файлов ограничены 8 символами, точкой и расширением до трех символов. Файловая система FAT для DOS и Windows хранит имена файлов как 8-символьное имя и 3-символьное расширение. Символ точки при этом не сохраняется. Высокопроизводительная файловая система (HPFS), используемая в ОС/2 от Microsoft и IBM, хранит имя файла как единую строку, где точка (".") является обычным символом. Конвенция использования суффиксов сохранилась, несмотря на то, что HPFS поддерживает расширенные атрибуты файлов, позволяющие хранить тип файла в файле как расширенный атрибут. Собственная файловая система Windows NT от Microsoft, NTFS, и более поздняя ReFS, также хранят имя файла как единую строку; при этом конвенция использования суффиксов для имитации расширений сохранилась для обеспечения совместимости с существующими версиями Windows. В Windows NT 3.5 появилась разновидность файловой системы FAT под названием VFAT, поддерживающая более длинные имена файлов, при этом имя файла рассматривается как единая строка. Windows 95 с VFAT представила поддержку длинных имен файлов и отказалась от разделения имени файла и расширения на 8.3 символа в не-NT Windows. Классическая Mac OS полностью отказалась от метаданных расширений, основанных на имени файла, и вместо этого использовала отдельный код типа файла для идентификации формата файла. Кроме того, использовался код создателя, чтобы определить, какое приложение будет запущено при двойном щелчке по значку файла. macOS, однако, использует суффиксы имен файлов, поскольку она является производной от UNIX-подобной операционной системы NeXTSTEP, в дополнение к использованию кодов типа и создателя. В системах Commodore файлы могут иметь только четыре расширения: PRG, SEQ, USR, REL. Однако они используются для разделения типов данных, используемых программой, и не имеют отношения к идентификации их содержимого. С появлением графических пользовательских интерфейсов возникла проблема управления файлами и поведения интерфейса. Microsoft Windows позволяла ассоциировать несколько приложений с данным расширением, и для выбора нужного приложения были доступны различные действия, например, контекстное меню с возможностью выбора между просмотром, редактированием или печатью файла. При этом предполагалось, что любое расширение представляет собой один тип файла, и между расширением и значком существовало однозначное соответствие. Когда наступила эра Интернета, пользователи Windows, все еще ограниченные форматом имен файлов 8.3, должны были создавать веб-страницы с именами, заканчивающимися на HTM, в то время как пользователи компьютеров Macintosh или UNIX могли использовать рекомендуемое расширение html. Это также стало проблемой для программистов, экспериментировавших с языком программирования Java, поскольку он требует четырехбуквенный суффикс `java` для исходных файлов кода и пятибуквенный суффикс `class` для выходных файлов объектного кода компилятора Java.

The Multics file system stores the file name as a single string, not split into base name and extension components, allowing the "." to be just another character allowed in file names. It allows for variable length filenames, permitting more than one dot, and hence multiple suffixes, as well as no dot, and hence no suffix. Some components of Multics, and applications running on it, use suffixes to indicate file types, but not all files are required to have a suffix — for example, executables and ordinary text files usually have no suffixes in their names. File systems for UNIX like operating systems also store the file name as a single string, with "." as just another character in the file name. A file with more than one suffix is sometimes said to have more than one extension, although terminology varies in this regard, and most authors define extension in a way that does not allow more than one in the same file name. More than one extension usually represents nested transformations, such as files. tar. gz (the tar indicates that the file is a tar archive of one or more files, and the gz indicates that the tar archive file is compressed with gzip). Programs transforming or creating files may add the appropriate extension to names inferred from input file names (unless explicitly given an output file name), but programs reading files usually ignore the information; it is mostly intended for the human user. It is more common, especially in binary files, for the file to contain internal or external metadata describing its contents. This model generally requires the full filename to be provided in commands, whereas the metadata approach often allows the extension to be omitted. In DOS and 16 bit Windows, file names have a maximum of 8 characters, a period, and an extension of up to three letters. The FAT file system for DOS and Windows stores file names as an 8 character name and a three character extension. The period character is not stored. The High Performance File System (HPFS), used in Microsoft and IBM's OS/2 stores the file name as a single string, with the "." character as just another character in the file name. The convention of using suffixes continued, even though HPFS supports extended attributes for files, allowing a file's type to be stored in the file as an extended attribute. Microsoft's Windows NT's native file system, NTFS, and the later ReFS, also store the file name as a single string; again, the convention of using suffixes to simulate extensions continued, for compatibility with existing versions of Windows. In Windows NT 3.5, a variant of the FAT file system, called VFAT appeared; it supports longer file names, with the file name being treated as a single string. Windows 95, with VFAT, introduced support for long file names, and removed the 8.3 name/extension split in file names from non NT Windows. The classic Mac OS disposed of filename based extension metadata entirely; it used, instead, a distinct file type code to identify the file format. Additionally, a creator code was specified to determine which application would be launched when the file's icon was double clicked. macOS, however, uses filename suffixes as a consequence of being derived from the UNIX like NeXTSTEP operating system, in addition to using type and creator codes. In Commodore systems, files can only have four extensions: PRG, SEQ, USR, REL. However, these are used to separate data types used by a program and are irrelevant for identifying their contents. With the advent of graphical user interfaces, the issue of file management and interface behavior arose. Microsoft Windows allowed multiple applications to be associated with a given extension, and different actions were available for selecting the required application, such as a context menu offering a choice between viewing, editing or printing the file. The assumption was still that any extension represented a single file type; there was an unambiguous mapping between extension and icon. When the Internet age first arrived, those using Windows systems that were still restricted to 8.3 filename formats had to create web pages with names ending in HTM, while those using Macintosh or UNIX computers could use the recommended html filename extension. This also became a problem for programmers experimenting with the Java programming language, since it requires the four letter suffix java for source code files and the five letter suffix class for Java compiler object code output files.

Тип содержимого

Расширения имен файлов могут рассматриваться как тип метаданных. Они обычно используются для указания информации о том, как данные могут быть сохранены в файле. Точное определение, определяющее критерии для установления того, какая часть имени файла является его расширением, зависит от правил конкретной используемой файловой системы; как правило, расширение — это подстрока, следующая за последним (если он есть) символом точки (например, txt — это расширение имени файла readme.txt, а html — расширение index.html). В файловых системах некоторых мейнфрейм-систем, таких как CMS в VM, VMS, а также в ПК-системах, таких как CP/M и производных от них системах, таких как MS DOS, расширение является отдельным пространством имен от имени файла. В DOS и Windows от Microsoft расширения, такие как EXE, COM или BAT, указывают на то, что файл является исполняемой программой. В OS/360 и последующих версиях часть имени набора данных, следующая за последней точкой, называемая квалификатором нижнего уровня, рассматривается некоторыми программами, например, TSO EDIT, как расширение, но она не имеет особого значения для самой операционной системы; то же самое относится и к файлам Unix в MVS. Изначально расширение имени файла использовалось для определения общего типа файла. Необходимость сокращения типа файла до трех символов часто приводила к использованию сокращенных расширений. Примеры включают использование GFX для графических файлов, TXT для обычного текста и MUS для музыки. Однако, поскольку было создано множество различных программ, обрабатывающих эти типы данных (и другие) различными способами, расширения имен файлов стали тесно ассоциироваться с определенными продуктами — даже с конкретными версиями продуктов. Например, ранние файлы WordStar использовали WS или WSn, где n — номер версии программы. Также возникли конфликты в использовании некоторых расширений имен файлов. Одним из примеров является rpm, используемый как для пакетов RPM Package Manager, так и для медиафайлов RealPlayer. Другие примеры: qif, используемый шрифтами DESQview, финансовыми документами Quicken и изображениями QuickTime; gba, используемый скриптами GrabIt и образами ROM для Game Boy Advance; sb, используемый для SmallBasic и Scratch; и dts, используемый для Dynamix Three Space и DTS.

Filename extensions may be considered a type of metadata. They are commonly used to imply information about the way data might be stored in the file. The exact definition, giving the criteria for deciding what part of the file name is its extension, belongs to the rules of the specific file system used; usually the extension is the substring which follows the last occurrence, if any, of the dot character (example: txt is the extension of the filename readme. txt, and html the extension of index. html). On file systems of some mainframe systems such as CMS in VM, VMS, and of PC systems such as CP/M and derivative systems such as MS DOS, the extension is a separate namespace from the filename. Under Microsoft's DOS and Windows, extensions such as EXE, COM or BAT indicate that a file is a program executable. In OS/360 and successors, the part of the dataset name following the last period, called the low level qualifier, is treated as an extension by some software, e. g., TSO EDIT, but it has no special significance to the operating system itself; the same applies to Unix files in MVS. The filename extension was originally used to determine the file's generic type. The need to condense a file's type into three characters frequently led to abbreviated extensions. Examples include using GFX for graphics files, TXT for plain text, and MUS for music. However, because many different software programs have been made that all handle these data types (and others) in a variety of ways, filename extensions started to become closely associated with certain products—even specific product versions. For example, early WordStar files used WS or WSn, where n was the program's version number. Also, conflicting uses of some filename extensions developed. One example is rpm, used for both RPM Package Manager packages and RealPlayer Media files;. Others are qif, shared by DESQview fonts, Quicken financial ledgers, and QuickTime pictures; gba, shared by GrabIt scripts and Game Boy Advance ROM images; sb, used for SmallBasic and Scratch; and dts, being used for Dynamix Three Space and DTS.

По сравнению с типом MIME

Во многих интернет-протоколах, таких как HTTP и MIME электронная почта, тип битового потока указывается как тип медиафайла или тип MIME, а не расширение имени файла. Эта информация приводится в текстовой строке, предшествующей потоку данных, например, "Content-Type: text/plain". Отсутствует стандартное соответствие между расширениями имен файлов и типами медиафайлов, что может приводить к разночтениям при интерпретации данных авторами, веб-серверами и клиентским программным обеспечением при передаче файлов через Интернет. Например, автор контента может указать расширение svgz для сжатого файла Scalable Vector Graphics, но веб-сервер, не распознающий это расширение, может не отправить корректный тип контента application/svg+xml и соответствующий заголовок сжатия, из-за чего веб-браузер не сможет правильно интерпретировать и отобразить изображение. BeOS, файловая система BFS которой поддерживает расширенные атрибуты, присваивает файлу тип медиафайла в виде расширенного атрибута. Некоторые графические среды, такие как KDE и GNOME, определяют тип медиафайла, анализируя как суффикс имени файла, так и содержимое файла, подобно команде `file`, используя это как эвристический метод. Они выбирают приложение для запуска при открытии файла, основываясь на этом типе медиафайла, что снижает зависимость от расширений имен файлов. macOS использует как расширения имен файлов, так и типы медиафайлов, а также коды типов файлов для выбора единого идентификатора типа (Uniform Type Identifier), который используется для внутренней идентификации типа файла.

Исполняемые программы

Использование расширения имени файла в имени команды встречается изредка, как правило, как побочный эффект реализации команды в виде скрипта, например, для оболочки Bourne или Python, когда к имени команды добавляется имя интерпретатора – практика, распространенная в системах, полагающихся на ассоциации между расширением имени файла и интерпретатором, но решительно не рекомендуемая в Unix-подобных системах, таких как Linux, Oracle Solaris, BSD-системы и macOS от Apple, где интерпретатор обычно указывается в заголовке скрипта ("shebang"). В системах, основанных на ассоциациях, расширение имени файла обычно сопоставляется с единственным, общесистемным выбором интерпретатора для этого расширения (например, ".py" означает использование Python), и саму команду можно выполнить из командной строки, даже если расширение опущено (при условии соответствующей настройки). Если язык реализации изменяется, изменяется и расширение имени команды, а ОС предоставляет согласованный API, позволяя использовать одну и ту же версию команды без расширения в обоих случаях. Этот метод несколько страдает из-за глобального характера сопоставления ассоциаций, а также из-за недостаточной практики разработчиков избегать расширений при вызове программ, и невозможности для разработчиков принудительно обеспечить такое избегание. Windows – единственная широко распространенная система, продолжающая использовать этот механизм. В системах с директивами интерпретатора, включая практически все версии Unix, расширения имен команд не имеют специального значения и, согласно общепринятой практике, не используются, поскольку основным способом указания интерпретатора для скриптов является запуск их со строки, определяющей используемый интерпретатор (что можно рассматривать как вырожденную форму ресурсной вилки). В таких средах включение расширения в имя команды излишне раскрывает деталь реализации, которая подвергает риску все ссылки на команду из других программ в случае изменения реализации. Например, совершенно нормально, если скрипт оболочки будет переписан на Python или Ruby, а затем на C или C++, и во всех этих случаях имя команды изменилось бы, если бы использовались расширения. Без расширений программа всегда имеет одно и то же имя без расширения, меняется только директива интерпретатора и/или магическое число, а ссылки на программу из других программ остаются действительными.

The use of a filename extension in a command name appears occasionally, usually as a side effect of the command having been implemented as a script, e. g., for the Bourne shell or for Python, and the interpreter name being suffixed to the command name, a practice common on systems that rely on associations between filename extension and interpreter, but sharply deprecated in Unix like systems, such as Linux, Oracle Solaris, BSD based systems, and Apple's macOS, where the interpreter is normally specified as a header in the script ("shebang"). On association based systems, the filename extension is generally mapped to a single, system wide selection of interpreter for that extension (such as ". py" meaning to use Python), and the command itself is runnable from the command line even if the extension is omitted (assuming appropriate setup is done). If the implementation language is changed, the command name extension is changed as well, and the OS provides a consistent API by allowing the same extensionless version of the command to be used in both cases. This method suffers somewhat from the essentially global nature of the association mapping, as well as from developers' incomplete avoidance of extensions when calling programs, and that developers can not force that avoidance. Windows is the only remaining widespread employer of this mechanism. On systems with interpreter directives, including virtually all versions of Unix, command name extensions have no special significance, and are by standard practice not used, since the primary method to set interpreters for scripts is to start them with a single line specifying the interpreter to use (which could be viewed as a degenerate resource fork). In these environments, including the extension in a command name unnecessarily exposes an implementation detail which puts all references to the commands from other programs at future risk if the implementation changes. For example, it would be perfectly normal for a shell script to be reimplemented in Python or Ruby, and later in C or C++, all of which would change the name of the command were extensions used. Without extensions, a program always has the same extension less name, with only the interpreter directive and/or magic number changing, and references to the program from other programs remain valid.

Вопросы безопасности

По умолчанию, в File Explorer, файловом браузере, поставляемом с Microsoft Windows, расширения имен файлов не отображаются. Злоумышленники пытались распространять компьютерные вирусы и черви, используя имена файлов, сформированные как LOVE LETTER FOR YOU. TXT. vbs. Цель состоит в том, чтобы это выглядело как LOVE LETTER FOR YOU. TXT, безобидный текстовый файл, не предупреждая пользователя о том, что это вредоносная компьютерная программа, в данном случае написанная на VBScript. В ReactOS по умолчанию расширения имен файлов отображаются в ReactOS Explorer. Более поздние версии Windows (начиная с Windows XP Service Pack 2 и Windows Server 2003) включали настраиваемые списки расширений имен файлов, которые считаются "опасными" в определенных "зонах" работы, например, при загрузке из Интернета или получении в виде вложения к электронной почте. Современное антивирусное программное обеспечение также помогает защитить пользователей от подобных атак, когда это возможно. Некоторые вирусы используют сходство между доменным именем верхнего уровня ".com" и расширением имени файла ".COM", рассылая по электронной почте вредоносные исполняемые файлы команд с именами, поверхностно похожими на URL-адреса (например, "myparty.yahoo.com"), в результате чего пользователи, не осознавая этого, переходят по ссылкам в электронных письмах, которые, как им кажется, ведут на веб-сайты, но на самом деле загружают и запускают вредоносные вложения. Имелись случаи создания вредоносных программ, использующих уязвимости в некоторых приложениях Windows, которые могли вызывать переполнение буфера на основе стека при открытии файла с чрезмерно длинным, не обработанным расширением имени файла. Расширение имени файла – это всего лишь маркер, и содержимое файла не обязано ему соответствовать. Это можно использовать для маскировки вредоносного содержимого. Поэтому при попытке идентификации файла с точки зрения безопасности полагаться только на расширение считается опасным, и предпочтительнее проводить надлежащий анализ содержимого файла. Например, в UNIX-подобных системах часто встречаются файлы без расширений, поскольку вместо этого используются команды, такие как `file`, которые считывают заголовок файла для определения его содержимого.

The default behavior of File Explorer, the file browser provided with Microsoft Windows, is for filename extensions to not be displayed. Malicious users have tried to spread computer viruses and computer worms by using file names formed like LOVE LETTER FOR YOU. TXT. vbs. The hope is that this will appear as LOVE LETTER FOR YOU. TXT, a harmless text file, without alerting the user to the fact that it is a harmful computer program, in this case, written in VBScript. Default behavior for ReactOS is to display filename extensions in ReactOS Explorer. Later Windows versions (starting with Windows XP Service Pack 2 and Windows Server 2003) included customizable lists of filename extensions that should be considered "dangerous" in certain "zones" of operation, such as when downloaded from the web or received as an e mail attachment. Modern antivirus software systems also help to defend users against such attempted attacks where possible. Some viruses take advantage of the similarity between the ". com" top level domain and the ". COM" filename extension by emailing malicious, executable command file attachments under names superficially similar to URLs (e. g., "myparty. yahoo. com"), with the effect that unaware users click on email embedded links that they think lead to websites but actually download and execute the malicious attachments. There have been instances of malware crafted to exploit vulnerabilities in some Windows applications which could cause a stack based buffer overflow when opening a file with an overly long, unhandled filename extension. The filename extension is just a marker and the content of the file does not have to match it. This can be used to disguise malicious content. When trying to identify a file for security reasons, it is therefore considered dangerous to rely on the extension alone and a proper analysis of the content of the file is preferred. For example, on UNIX like systems, it is not uncommon to find files with no extensions at all, as commands such as file are meant to be used instead, and will read the file's header to determine its content.