Расширение имени файла , расширение имени файла или расширение файла — это суффикс к имени компьютерного файла ( например, .txt
, .docx
, .md
). Расширение указывает на характеристику содержимого файла или его предполагаемое использование. Расширение имени файла обычно отделяется от остальной части имени файла точкой , но в некоторых системах [1] оно отделяется пробелами.
Некоторые файловые системы реализуют расширения имен файлов как функцию самой файловой системы и могут ограничивать длину и формат расширения, в то время как другие рассматривают расширения имен файлов как часть имени файла без особого различия.
Файловая система Multics хранит имя файла как одну строку, не разделенную на базовое имя и компоненты расширения, что позволяет использовать "." просто как еще один символ, разрешенный в именах файлов. Она допускает имена файлов переменной длины, допуская более одной точки и, следовательно, несколько суффиксов, а также отсутствие точки и, следовательно, отсутствие суффикса. Некоторые компоненты Multics и приложения, работающие на ней, используют суффиксы для обозначения типов файлов, но не все файлы обязаны иметь суффикс — например, исполняемые файлы и обычные текстовые файлы обычно не имеют суффиксов в своих именах.
Файловые системы для операционных систем типа UNIX также хранят имя файла в виде одной строки, с "." в качестве просто еще одного символа в имени файла. Иногда говорят, что файл с более чем одним суффиксом имеет более одного расширения, хотя терминология в этом отношении различается, и большинство авторов определяют расширение таким образом, что не допускается более одного расширения в одном и том же имени файла. [ необходима цитата ] Обычно более одного расширения представляют вложенные преобразования, такие как files.tar.gz
( .tar
указывает, что файл является архивом tar из одного или нескольких файлов, а .gz
указывает, что файл архива tar сжат с помощью gzip ). Программы, преобразующие или создающие файлы, могут добавлять соответствующее расширение к именам, выведенным из имен входных файлов (если явно не указано имя выходного файла), но программы, считывающие файлы, обычно игнорируют эту информацию; она в основном предназначена для пользователя-человека. Чаще всего, особенно в двоичных файлах, файл содержит внутренние или внешние метаданные, описывающие его содержимое. Эта модель обычно требует указания полного имени файла в командах, тогда как подход с метаданными часто позволяет опускать расширение.
В DOS и 16-разрядной Windows имена файлов имеют максимум 8 символов, точку и расширение до трех букв. Файловая система FAT для DOS и Windows хранит имена файлов как 8-символьное имя и трехсимвольное расширение. Символ точки не сохраняется.
Высокопроизводительная файловая система (HPFS), используемая в Microsoft и OS/2 IBM, хранит имя файла как одну строку, с символом "." как просто еще одним символом в имени файла. Соглашение об использовании суффиксов продолжалось, хотя HPFS поддерживает расширенные атрибуты для файлов, позволяя сохранять тип файла в файле как расширенный атрибут.
Собственная файловая система Windows NT от Microsoft , NTFS , и более поздняя ReFS , также хранят имя файла в виде одной строки; опять же, соглашение об использовании суффиксов для имитации расширений продолжалось для совместимости с существующими версиями Windows. В Windows NT 3.5 появился вариант файловой системы FAT, называемый VFAT ; он поддерживает более длинные имена файлов, при этом имя файла рассматривается как одна строка.
В Windows 95 с VFAT появилась поддержка длинных имен файлов и было удалено разделение имени/расширения 8.3 в именах файлов из не-NT Windows.
Классическая Mac OS полностью избавилась от метаданных расширения на основе имени файла; вместо этого она использовала отдельный код типа файла для идентификации формата файла. Кроме того, был указан код создателя для определения того, какое приложение будет запущено при двойном щелчке по значку файла . [2] Однако macOS использует суффиксы имен файлов как следствие того, что она получена из UNIX-подобной операционной системы NeXTSTEP , в дополнение к использованию кодов типа и создателя.
В системах Commodore файлы могут иметь только четыре расширения: PRG, SEQ, USR, REL. Однако они используются для разделения типов данных, используемых программой, и не имеют значения для идентификации их содержимого.
С появлением графических пользовательских интерфейсов возникла проблема управления файлами и поведения интерфейса. Microsoft Windows позволяла связывать несколько приложений с заданным расширением, и для выбора необходимого приложения были доступны различные действия, такие как контекстное меню, предлагающее выбор между просмотром, редактированием или печатью файла. По-прежнему предполагалось, что любое расширение представляет собой один тип файла; существовало однозначное соответствие между расширением и значком.
Когда впервые наступила эра Интернета , те, кто использовал системы Windows, которые все еще были ограничены форматами имен файлов 8.3, должны были создавать веб-страницы с именами, заканчивающимися на .HTM
, в то время как те, кто использовал компьютеры Macintosh или UNIX, могли использовать рекомендуемое .html
расширение имени файла. Это также стало проблемой для программистов, экспериментирующих с языком программирования Java , поскольку он требует четырехбуквенного суффикса .java
для файлов исходного кода и пятибуквенного суффикса .class
для выходных файлов объектного кода компилятора Java . [3]
Расширения имен файлов можно считать типом метаданных . [4] Они обычно используются для указания информации о способе хранения данных в файле. Точное определение, дающее критерии для решения того, какая часть имени файла является его расширением, принадлежит правилам конкретной используемой файловой системы [5] ; обычно расширение представляет собой подстроку, которая следует за последним вхождением символа точки , если таковое имеется ( например: является расширением имени файла , и расширением ). В файловых системах некоторых мэйнфреймовых систем, таких как CMS в VM , VMS , и ПК-систем, таких как CP/M и производных систем, таких как MS-DOS , расширение представляет собой отдельное пространство имен от имени файла. В DOS и Windows от Microsoft такие расширения, как , или указывают, что файл является исполняемым файлом программы . В OS/360 и последующих версиях часть имени набора данных, следующая за последней точкой, называемая квалификатором низкого уровня, рассматривается некоторым программным обеспечением как расширение, например, TSO EDIT, но она не имеет особого значения для самой операционной системы; то же самое относится к файлам Unix в MVS. txt
readme.txt
html
index.html
EXE
COM
BAT
Расширение имени файла изначально использовалось для определения общего типа файла. [ необходима цитата ] Необходимость сжать тип файла до трех символов часто приводила к сокращенным расширениям. Примерами являются использование .GFX
для графических файлов, .TXT
для обычного текста и .MUS
для музыки. Однако, поскольку было создано много различных программ, которые все обрабатывают эти типы данных (и другие) различными способами, расширения имен файлов начали тесно ассоциироваться с определенными продуктами — даже с определенными версиями продуктов. Например, ранние файлы WordStar.WS
использовали или , где n — номер версии программы. Кроме того, возникли конфликтующие варианты использования некоторых расширений имен файлов. Одним из примеров является , используемый как для пакетов RPM Package Manager , так и для файлов RealPlayer Media;. [6] Другие — , используемый шрифтами DESQview , финансовыми регистрами Quicken и изображениями QuickTime ; [7] , используемый скриптами GrabIt и образами ROM Game Boy Advance ; [8] , используемый для SmallBasic и Scratch ; и , используемый для Dynamix Three Space и DTS ..WSn
.rpm
.qif
.gba
.sb
.dts
Во многих интернет- протоколах, таких как HTTP и MIME email , тип потока битов указывается как media type или MIME-тип потока, а не расширение имени файла. Это указывается в строке текста, предшествующей потоку, например Content-type: text/plain .
Не существует стандартного сопоставления между расширениями имен файлов и типами носителей, что приводит к возможным несоответствиям в интерпретации между авторами, веб-серверами и клиентским программным обеспечением при передаче файлов через Интернет. Например, автор контента может указать расширение svgz для сжатого файла масштабируемой векторной графики , но веб-сервер, который не распознает это расширение, может не отправить правильный тип контента application/svg+xml и его требуемый заголовок сжатия, в результате чего веб-браузеры не смогут правильно интерпретировать и отображать изображение.
BeOS , чья файловая система BFS поддерживает расширенные атрибуты, помечает файл с его типом носителя как расширенный атрибут. Некоторые среды рабочего стола , такие как KDE и GNOME , связывают тип носителя с файлом, проверяя как суффикс имени файла, так и содержимое файла, подобно команде file , как эвристика . Они выбирают приложение для запуска при открытии файла на основе этого типа носителя, уменьшая зависимость от расширений имен файлов. macOS использует как расширения имен файлов, так и типы носителей, а также коды типов файлов для выбора унифицированного идентификатора типа , с помощью которого можно внутренне идентифицировать тип файла.
Использование расширения имени файла в имени команды встречается время от времени, обычно как побочный эффект реализации команды в виде скрипта, например, для оболочки Bourne или для Python , и добавления имени интерпретатора к имени команды, практика, распространенная в системах, которые полагаются на ассоциации между расширением имени файла и интерпретатором, но резко осуждаемая [9] в Unix-подобных системах, таких как Linux , Oracle Solaris , системы на базе BSD и macOS от Apple , где интерпретатор обычно указывается в качестве заголовка в скрипте (« shebang »).
В системах на основе ассоциаций расширение имени файла обычно сопоставляется с единым общесистемным выбором интерпретатора для этого расширения (например, ".py" означает использование Python), а сама команда может быть запущена из командной строки, даже если расширение опущено (при условии, что выполнена соответствующая настройка). Если язык реализации изменен, расширение имени команды также изменяется, и ОС предоставляет согласованный API , позволяя использовать одну и ту же версию команды без расширения в обоих случаях. Этот метод несколько страдает от по сути глобальной природы сопоставления ассоциаций, а также от неполного избегания разработчиками расширений при вызове программ, и того, что разработчики не могут заставить это избегать. Windows является единственным оставшимся широко распространенным пользователем этого механизма.
В системах с директивами интерпретатора , включая практически все версии Unix, расширения имен команд не имеют особого значения и по стандартной практике не используются, поскольку основной метод установки интерпретаторов для скриптов — это запуск их с одной строки, указывающей используемый интерпретатор. В этих средах включение расширения в имя команды без необходимости раскрывает детали реализации, что подвергает все ссылки на команды из других программ риску в будущем, если реализация изменится. Например, было бы совершенно нормально, если бы скрипт оболочки был переопределен на Python или Ruby, а затем на C или C++, и все это изменило бы имя команды, если бы использовались расширения. Без расширений программа всегда имеет одно и то же имя без расширения, меняется только директива интерпретатора и/или магическое число , а ссылки на программу из других программ остаются действительными.
Поведение по умолчанию 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, что могло привести к переполнению буфера стека при открытии файла со слишком длинным, необрабатываемым расширением имени файла.
Расширение имени файла — это всего лишь маркер, и содержимое файла не обязательно должно совпадать с ним. [10] Это может использоваться для маскировки вредоносного содержимого. Поэтому при попытке идентифицировать файл по соображениям безопасности считается опасным полагаться только на расширение, и предпочтительнее провести надлежащий анализ содержимого файла. Например, в системах типа UNIX нередко можно найти файлы вообще без расширений, поскольку file
вместо этого должны использоваться такие команды, как , которые будут читать заголовок файла, чтобы определить его содержимое.
Одна вещь, которую вам нужно знать о создании файлов с помощью z/VM, заключается в том, что каждому файлу нужен свой собственный трехчастный идентификатор. Первая часть идентификатора — это имя файла. Вторая часть — это тип файла. А третья часть — это режим файла. Эти три идентификатора файлов часто сокращаются до fn ft fm.
файлов исходного кода должны иметь суффиксы .java, имена файлов классов должны иметь суффиксы .class, а исходные файлы и файлы классов должны иметь корневые имена, идентифицирующие класс.