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

Эта статья требует дополнительных ссылок для проверки . Пожалуйста, помогите улучшить эту статью , добавив цитаты из надежных источников . Материал, не полученный от источника, может быть оспорен и удален. Поиск источников:  «Расширение имени файла»  -  новости  · газеты  · книги  · ученый  · JSTOR ( ноябрь 2015 г. ) ( Узнайте, как и когда удалить это сообщение-шаблон )

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

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

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

Расширения имени файла можно рассматривать как тип метаданных . ^[2] Они обычно используются для обозначения информации о том, как данные могут храниться в файле. Точное определение, дающее критерии для решения, какая часть имени файла является его расширением, принадлежит правилам конкретной используемой файловой системы ; обычно расширением является подстрока, которая следует за последним вхождением символа точки ( если таковой имеется) ( пример: 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.WSnбыл номером версии программы. Кроме того, возникли конфликты использования некоторых расширений файлов. Один из примеров - .rpmиспользуется как для пакетов диспетчера пакетов RPM, так и для файлов RealPlayer Media. ^[3] Другие .qifиспользуются шрифтами DESQview , финансовыми книгами Quicken и изображениями QuickTime ; ^[4] .gba , предоставленный скриптами GrabIt и образами ROM Game Boy Advance ; ^[5] .sb , используется для SmallBasic и Scratch ; и .dtsиспользуется для Dynamix Three Space и 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а выходные файлы объектного кода компилируются с пятибуквенным суффиксом. ^[6].class

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

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

Этот раздел может потребовать очистки для соответствия стандартам качества Википедии . Конкретная проблема: непреодолимая конструкция. Помогите улучшить этот раздел, если можете. ( Ноябрь 2015 г. ) ( Узнайте, как и когда удалить этот шаблон сообщения )

Использование расширения имени файла в имени команды появляется иногда, обычно как побочный эффект того, что команда была реализована в виде сценария, например, для оболочки Bourne или для Python , а имя интерпретатора добавляется к имени команды как суффикс. практика распространена в системах, которые полагаются на ассоциации между расширением имени файла и интерпретатором, но резко устарела ^[7] в системах, производных от UNIX, таких как Linux и MacOS от Apple , где интерпретатор обычно указывается как заголовок в сценарии (« shebang »).

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

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

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

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

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

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

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

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

• файл (команда)
• Список форматов файлов
• Список расширений файлов
• Метаданные
• .характеристики

Ссылки [ править ]

Внешние ссылки [ править ]

• СМИ, связанные с расширениями имен файлов на Викискладе?
• Форматы данных расширение имени файла в Curlie