Экстеншен

Материал из wikixw
Перейти к навигации Перейти к поиску

Расширение имени файла, расширение имени файла или расширение файла - это суффикс к имени компьютерного файла (например, .txt, .docx, .md). Расширение указывает на характеристику содержимого файла или его предполагаемое использование. Расширение имени файла обычно отделяется от остальной части имени файла точкой, но в некоторых системах оно разделяется пробелами. Другие форматы расширений включают тире и / или подчеркивания в ранних версиях GNU Linux и некоторых версиях IBM AIX.

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

Использование[править]

Расширения имени файла могут рассматриваться как тип метаданных.[2] Они обычно используются для обозначения информации о том, как данные могут храниться в файле. Точное определение, дающее критерии для определения того, какая часть имени файла является его расширением, относится к правилам конкретной используемой файловой системы; обычно расширение - это подстрока, которая следует за последним вхождением, если таковое имеется, символа точки (пример: txt является расширением имени readme.txtфайла, а htmlрасширениерасширение mysite.index.html). В файловых системах некоторых систем мэйнфреймов, таких как CMS в VM, VMS, и систем ПК, таких как CP / M и производных систем, таких как MS-DOS, расширение является отдельным пространством имен от имени файла. В DOS и Windows Microsoft такие расширения, как 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 использовали .WSor .WSn, где n - номер версии программы. Кроме того, противоречивое использование некоторых расширений имени файла. Один пример .rpmиспользуется как для пакетов RPM Package Manager, так и для медиафайлов RealPlayer;[3] Другие .qifиспользуются шрифтами DESQview, Quicken financial ledgers и QuickTime pictures; .gba совместно используются скриптами GrabIt и изображениями Game Boy Advance ROM; .sb используются для SmallBASIC и Scratchи .dtsиспользуется для Dynamix Three Space и DTS.

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

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

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

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

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

Проблемы с именем команды[править]

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

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

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

Расширение имени файла - это просто маркер, и содержимое файла не должно ему соответствовать.[8] Это может быть использовано для маскировки вредоносного контента. Поэтому при попытке идентифицировать файл по соображениям безопасности полагаться только на расширение считается опасным, и предпочтительным является надлежащий анализ содержимого файла. Например, в системах, производных от UNIX, нередко можно найти файлы вообще без расширений, поскольку вместо этого используются такие команды, как file (command), которые считывают заголовок файла для определения его содержимого.

Альтернативы[править]

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

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

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

См. Также[править]

Пруф[править]

curlie.org/Computers/Data_Formats/