Расширение имени файла - Filename extension

Расширение имени файла , расширение файла или тип файла является идентификатором , указанным в качестве суффикса к имени в виде компьютерного файла . Расширение указывает на характеристику содержимого файла или его предполагаемое использование. Расширение имени файла обычно отделяется от имени файла точкой (точкой), но в некоторых системах оно отделяется пробелами.

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

использование

Расширения имени файла можно рассматривать как тип метаданных . Они обычно используются для обозначения информации о том, как данные могут храниться в файле. Точное определение, дающее критерии для решения, какая часть имени файла является его расширением, принадлежит правилам конкретной используемой файловой системы ; обычно расширением является подстрока, которая следует за последним вхождением символа точки ( если таковой имеется) ( пример: txt это расширение имени файла readme.txtи htmlрасширение mysite.index.html). В файловых системах некоторых систем мэйнфреймов, таких как CMS в VM , VMS , и в системах ПК, таких как CP / M и производных системах, таких как MS-DOS , расширение является отдельным пространством имен от имени файла. Под Microsoft в DOS и Windows , , расширения , такие как EXE, COMили BATуказывают на то , что файл является программой исполняемого файла . В OS / 360 и последующих версиях часть имени набора данных, следующая за последней точкой, рассматривается как расширение некоторым программным обеспечением, например TSO EDIT, но не имеет особого значения для самой операционной системы; то же самое относится к файлам Unix в MVS.

Файловые системы для UNIX-подобных операционных систем не отделяют метаданные расширения от остальной части имени файла. Точка - это просто еще один символ в основном имени файла. Имя файла не может иметь расширений, одного расширения или нескольких расширений. Более чем одно расширение обычно представляет вложенные преобразования, такие как files.tar.gz( .tarуказывает, что файл является tar-архивом из одного или нескольких файлов, а .gzуказывает, что файл tar-архива сжат с помощью gzip ). Программы, преобразующие или создающие файлы, могут добавлять соответствующее расширение к именам, выводимым из имен входных файлов (если явно не указано имя выходного файла), но программы, читающие файлы, обычно игнорируют эту информацию; он в основном предназначен для человека. Чаще, особенно в двоичных файлах, сам файл содержит внутренние метаданные, описывающие его содержимое. Эта модель обычно требует, чтобы в командах было указано полное имя файла, тогда как подход с использованием метаданных часто позволяет опускать расширение.

В VFAT , NTFS , и рефов файловые системы для Windows , также не отделить метаданные расширения от остальной части имени файла, и позволяют несколько расширений.

С появлением графических пользовательских интерфейсов возникла проблема управления файлами и поведения интерфейса. Microsoft Windows позволяла связывать несколько приложений с данным расширением, и для выбора необходимого приложения были доступны различные действия, такие как контекстное меню, предлагающее выбор между просмотром, редактированием или печатью файла. По-прежнему предполагалось, что любое расширение представляет один тип файла; между расширением и значком было однозначное соответствие.

Классический Mac OS утилизированы имена файлов на основе метаданных расширения целиком; вместо этого он использовал отдельный код типа файла для определения формата файла. Кроме того, код создатель был определен , чтобы определить , какое приложение будет запускаться , когда к файлу значок был двойной щелчок . Однако macOS использует суффиксы имен файлов, а также коды типов и создателей, поскольку они являются производными от UNIX-подобной операционной системы NeXTSTEP .

Улучшения

Расширение имени файла изначально использовалось для определения универсального типа файла. Необходимость сжать тип файла до трех символов часто приводила к сокращению расширений. Примеры включают использование .GFXдля графических файлов, .TXTдля обычного текста и .MUSдля музыки. Однако, поскольку было создано множество различных программ, которые обрабатывают эти (и другие) типы данных различными способами, расширения файлов стали тесно ассоциироваться с определенными продуктами - даже с конкретными версиями продуктов. Например, использовались ранние файлы WordStar.WS или , где n - номер версии программы. Кроме того, были разработаны конфликтующие варианты использования некоторых расширений файлов. Один из примеров - используется как для пакетов диспетчера пакетов RPM, так и для файлов RealPlayer Media. Другие используются шрифтами DESQview , финансовыми книгами Quicken и изображениями QuickTime ; , совместно используемый скриптами GrabIt и образами ROM Game Boy Advance ; , используется для SmallBasic и Scratch ; и используется для Dynamix Three Space и DTS . .WSn.rpm.qif.gba.sb.dts

Некоторые другие операционные системы, которые использовали расширения файлов, обычно имели меньше ограничений на имена файлов. Многие разрешали полную длину имени файла из 14 или более символов, а максимальная длина имени до 255 не была редкостью. Файловые системы в операционных системах, таких как Multics и UNIX, хранят имя файла в виде одной строки, не разделенной на компоненты базового имени и расширения, что позволяет использовать расширение "." быть просто еще одним символом, разрешенным в именах файлов. Такие системы обычно позволяют использовать имена файлов переменной длины, разрешая более одной точки и, следовательно, несколько суффиксов. Некоторые компоненты Multics и UNIX, а также приложения, работающие на них, в некоторых случаях использовали суффиксы для обозначения типов файлов, но они не использовали их так часто, например, исполняемые и обычные текстовые файлы не имели суффиксов в своих именах.

Файл High Performance System (HPFS), используемый в Microsoft и IBM «ы OS / 2 также поддерживает длинные имена файлов и не разделить имя файла в имя и расширение. Соглашение об использовании суффиксов продолжалось, даже несмотря на то, что HPFS поддерживал расширенные атрибуты для файлов, позволяя сохранять тип файла в файле как расширенный атрибут.

Собственная файловая система Microsoft Windows NT , NTFS , поддерживала длинные имена файлов и не разделяла имя файла на имя и расширение, но опять же, соглашение об использовании суффиксов для имитации расширений сохранялось для совместимости с существующими версиями Windows.

Когда наступила эра Интернета , те, кто использовал системы Windows, которые все еще были ограничены форматами файлов 8.3 , должны были создавать веб-страницы с именами, оканчивающимися на .HTM, в то время как те, кто использовал компьютеры Macintosh или UNIX, могли использовать рекомендованное .htmlрасширение имени файла. Это также стало проблемой для программистов, экспериментирующих с языком программирования Java , поскольку он требует четырехбуквенного суффикса .javaдля файлов исходного кода и пятибуквенного суффикса .classдля выходных файлов объектного кода компилятора Java .

В конце концов, Windows 95 представила поддержку длинных имен файлов и удалила разделение имени / расширения 8.3 в именах файлов из Windows, отличной от NT, в расширенной версии широко используемой файловой системы FAT, называемой VFAT . VFAT впервые появился в Windows NT 3.5 и Windows 95 . Внутренняя реализация длинных имен файлов в VFAT в значительной степени считается кладжем , но она сняла важное ограничение на длину и позволила файлам иметь сочетание букв верхнего и нижнего регистра на машинах, которые плохо работали с Windows NT .

Проблемы с названием команды

Использование расширения имени файла в имени команды появляется иногда, обычно как побочный эффект того, что команда была реализована как сценарий, например, для оболочки Bourne или для Python , и имя интерпретатора добавлено к имени команды суффиксом. практика, распространенная в системах, которые полагаются на ассоциации между расширением имени файла и интерпретатором, но резко устарела в Unix-подобных системах, таких как Linux , Oracle Solaris , системы на основе BSD и MacOS от Apple , где интерпретатор обычно указывается как заголовок в сценарий (« шебанг »).

В системах на основе ассоциаций расширение имени файла обычно сопоставляется с одним общесистемным выбором интерпретатора для этого расширения (например, «.py» означает использование Python), а сама команда запускается из командной строки, даже если расширение опущено (при условии, что выполнена соответствующая настройка). При изменении языка реализации изменяется и расширение имени команды, и ОС предоставляет согласованный API , позволяя использовать одну и ту же версию команды без расширения в обоих случаях. Этот метод в некоторой степени страдает от по существу глобального характера сопоставления ассоциаций, а также от того, что разработчики не полностью избегают расширений при вызове программ, и что разработчики не могут принудительно этого избежать. Windows - единственный оставшийся широко распространенный работодатель этого механизма.

В системах с директивами интерпретатора , включая практически все версии Unix, расширения имен команд не имеют особого значения и по стандартной практике не используются, поскольку основным методом установки интерпретаторов для сценариев является их запуск с одной строки, в которой указывается, что интерпретатор должен use (что можно рассматривать как выродившуюся вилку ресурсов ). В этих средах включение расширения в имя команды излишне раскрывает детали реализации, которые подвергают все ссылки на команды из других программ будущему риску, если реализация изменится. Например, было бы совершенно нормально, если бы сценарий оболочки был переопределен на Python или Ruby, а затем на C или C ++, и все это изменило бы имя команды, если бы использовались расширения. Без расширений программа всегда имеет одно и то же имя без расширения, с изменением только директивы интерпретатора и / или магического числа , а ссылки на программу из других программ остаются действительными.

Проблемы с безопасностью

По умолчанию проводник , обозреватель файлов, входящий в состав 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 (command) , и они будут читать заголовок файла, чтобы определить его содержимое.

Альтернативы

Во многих Интернет- протоколах, таких как электронная почта HTTP и MIME , тип битового потока указывается как тип мультимедиа или MIME-тип потока, а не как расширение имени файла. Это дается в строке текста, предшествующей потоку, например Content-type: text / plain .

Не существует стандартного сопоставления между расширениями файлов и типами носителей, что приводит к возможным несоответствиям в интерпретации между авторами, веб-серверами и клиентским программным обеспечением при передаче файлов через Интернет. Например, автор содержимого может указать расширение svgz для сжатого файла масштабируемой векторной графики , но веб-сервер, который не распознает это расширение, может не отправить соответствующий тип содержимого application / svg + xml и его требуемый заголовок сжатия, в результате чего веб-браузеры не может правильно интерпретировать и отобразить изображение.

BeOS , чья файловая система BFS поддерживает расширенные атрибуты, пометит файл с его типом носителя как расширенный атрибут. В KDE и GNOME окружения рабочего стола ассоциировать тип носителя с файлом путем изучения как имя файла суффикса и содержимого файл, в моде файл команды, как эвристики . Они выбирают приложение для запуска при открытии файла на основе этого типа носителя, уменьшая зависимость от расширений файлов. macOS использует как расширения файлов, так и типы мультимедиа, а также коды типов файлов , чтобы выбрать унифицированный идентификатор типа, по которому будет определяться тип файла внутри.

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

использованная литература

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