Войти
A расширение имени файла или тип файла - это идентификатор, указанный как суффикс к имени компьютерного файла . Расширение указывает на характеристику содержимого файла или его предполагаемое использование. Расширение имени файла обычно отделяется от имени файла точкой (точка), но в некоторых системах оно отделяется пробелами.
Некоторые файловые системы реализуют расширения имени файла как функцию самой файловой системы и могут ограничивать длину и формат расширения, в то время как другие рассматривают расширения файлов как часть имени файла без особого различия.
Расширения имени файла можно рассматривать как тип метаданных. Они обычно используются для обозначения информации о том, как данные могут храниться в файле. Точное определение, дающее критерии для определения того, какая часть имени файла является его расширением, принадлежит правилам конкретной используемой файловой системы ; обычно расширением является подстрока, которая следует за последним вхождением символа точки , если таковое имеется (например: 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 и ReFS для Windows также не отделяют метаданные расширения от остальная часть имени файла и разрешить несколько расширений.
С появлением графических пользовательских интерфейсов возникла проблема управления файлами и поведения интерфейса. Microsoft Windows позволяла связывать несколько приложений с одним расширением, и для выбора необходимого приложения были доступны различные действия, такие как контекстное меню , предлагающее выбор между просмотром, редактированием или печатью файла. Все еще предполагалось, что любое расширение представляет один тип файла; между расширением и значком было однозначное соответствие.
В классической Mac OS полностью удалены метаданные расширения на основе имени файла; вместо этого он использовал отдельный файл код типа для идентификации формата файла. Кроме того, был указан код создателя , чтобы определить, какое приложение будет запущено при двойном щелчке значка файла. Однако macOS использует суффиксы имен файлов, а также коды типов и создателей, поскольку они являются производными от UNIX-подобной операционной системы NeXTSTEP.
Расширение имени файла изначально использовалось для определения универсального типа файла. Необходимость сжать тип файла до трех символов часто приводила к сокращенным расширениям. Примеры включают использование .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.
. Некоторые другие операционные системы, которые использовали расширения файлов, обычно имели гораздо более либеральные размеры для имен файлов. Многие разрешали полную длину имени файла из 14 и более символов, а максимальная длина имени до 255 не была редкостью. Файловые системы в операционных системах, таких как Multics и UNIX, хранят имя файла в виде одной строки, не разделенной на компоненты базового имени и расширения, с символом "." это просто еще один символ, разрешенный в именах файлов. Такие системы обычно допускают использование имен файлов переменной длины, допускающих использование более одной точки и, следовательно, нескольких суффиксов. Некоторые компоненты Multics и UNIX, а также приложения, работающие на них, в некоторых случаях использовали суффиксы для обозначения типов файлов, но они не использовали их так часто - например, исполняемые и обычные текстовые файлы не имели суффиксов в своих именах.
Высокопроизводительная файловая система (HPFS), используемая в Microsoft и IBM OS / 2, также поддерживала длинные имена файлов и действительно не разделять имя файла на имя и расширение. Соглашение об использовании суффиксов продолжалось, хотя HPFS поддерживал расширенные атрибуты для файлов, позволяя хранить тип файла в файле как расширенный атрибут.
Собственная файловая система Microsoft Windows NT, NTFS, поддерживала длинные имена файлов и не разделяла имя файла на имя и расширение, но опять же, соглашение об использовании суффиксов для имитации расширений продолжено для совместимости с существующими версиями Windows.
Когда впервые наступила эпоха Интернета, те, кто использовал системы Windows, которые все еще были ограничены форматом файлов 8.3, должны были создавать веб-страницы с именами, заканчивающимися на .HTM, тогда как пользователи компьютеров Macintosh или UNIX могут использовать рекомендованное расширение имени файла .html. Это также стало проблемой для программистов, экспериментирующих с языком программирования Java, поскольку он требует, чтобы файлы исходного кода имели четырехбуквенный суффикс .javaи компилирует выходные файлы с объектным кодом с пятибуквенным суффиксом .class.
В конце концов, Windows 95 представила поддержку длинных имена файлов и удалили разделение имени / расширения 8.3 в именах файлов из Windows, отличной от NT, в расширенной версии широко используемой файловой системы FAT под названием VFAT. VFAT впервые появился в Windows NT 3.5 и Windows 95. Внутренняя реализация длинных имен файлов в VFAT в основном рассматривается как kludge, но она сняла важное ограничение длины и разрешила файлам иметь сочетание верхнего регистра и строчные буквы на машинах, которые плохо работают с Windows NT. Однако использование трехсимвольных расширений в Microsoft Windows продолжалось, первоначально для обратной совместимости со старыми версиями Windows, а теперь по привычке вместе с проблемами, которые это создает.
Использование расширения имени файла в имени команды появляется иногда, обычно как побочный эффект команды, реализованной в виде сценария, например, для Оболочка Bourne или для Python, а имя интерпретатора добавляется к имени команды, практика, распространенная в системах, которые полагаются на связи между расширением имени файла и интерпретатором, но резко устарела в UNIX производные системы, такие как Linux и Apple macOS, где интерпретатор обычно указывается как заголовок в сценарии («shebang »).
В системах, основанных на ассоциациях, расширение имени файла обычно сопоставляется с одним общесистемным выбором интерпретатора для этого расширения (например, «.py» означает использование Python), а сама команда запускается из командной строки, даже если расширение не указано (при условии, что выполнена соответствующая настройка). Если язык реализации изменяется, расширение имени команды также изменяется, и ОС обеспечивает согласованный API, позволяя использовать одну и ту же версию команды без расширения в обоих случаях. Этот метод в некоторой степени страдает от по существу глобального характера сопоставления ассоциаций, а также от того, что разработчики не полностью избегают расширений при вызове программ, и что разработчики не могут принудительно этого избежать. Windows - единственный оставшийся широко распространенный работодатель этого механизма.
В системах с директивами интерпретатора, включая практически все версии Unix, расширения имен команд не имеют особого значения и по стандартной практике не используются, поскольку основной метод установки интерпретаторов для сценариев состоит в том, чтобы начинать их с единственной строки, определяющей используемый интерпретатор (который можно рассматривать как вырожденную ветвь ресурсов ). В этих средах включение расширения в имя команды излишне раскрывает детали реализации, которые подвергают все ссылки на команды из других программ будущему риску, если реализация изменится. Например, было бы совершенно нормально, если бы сценарий оболочки был переопределен на 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 для сжатого файла Scalable Vector Graphics, но веб-сервер, который не распознает это расширение, может не отправить правильный тип контента application / svg + xml и его требуемые заголовок сжатия, в результате чего веб-браузеры не могут правильно интерпретировать и отображать изображение.
BeOS, чья файловая система BFS поддерживает расширенные атрибуты, пометит файл с его типом носителя как расширенный атрибут. KDE и GNOME окружения рабочего стола связывают тип носителя с файлом, исследуя суффикс имени файла и его содержимое в виде файл как эвристика . Они выбирают приложение для запуска при открытии файла на основе этого типа носителя, уменьшая зависимость от расширений файлов. macOS использует как расширения файлов, так и типы носителей, а также коды типов файлов, чтобы выбрать унифицированный идентификатор типа, с помощью которого можно определить тип файла внутри.
Носители, связанные с расширениями имен файлов на Викискладе