Файл атауының қосымшасы

Кіріспе

Файл атауының жұрнағы файлдың типін көрсететін қосымша болып табылады.

Файл атауының кеңейтімі, файлдың кеңейтімі немесе файл жұрнағы – компьютерлік файл атауының соңына қосылатын жұрнақ (мысалы, txt, docx, md). Бұл кеңейтім файлдың мазмұнының сипаттамасын немесе оның қызметтік мақсатын көрсетеді. Файл атауының кеңейтімі әдетте файл атауының қалған бөлігінен нүкте арқылы бөлінеді, бірақ кейбір жүйелерде кеңейтім бос орынмен бөлінуі мүмкін. Кейбір файлдық жүйелер файл атауының кеңейтімін жүйенің өзіне тән мүмкіндік ретінде іске асырады және кеңейтімнің ұзындығы мен форматын шектеуі мүмкін, ал басқалары файл атауының кеңейтімін файл атауының бір бөлігі ретінде қарастырады, ерекше айырма жасамайды.

Операциялық жүйе мен файл жүйесін қолдау

Multics файлдық жүйесі файл атауын бір жол ретінде сақтайды, негізгі атау мен кеңейтімге бөлінбейді, соның арқасында "." символы файл атауларында рұқсат етілген тағы бір символ болады. Ол өзгермелі ұзындықтағы файл атауларын қолдайды, бірнеше нүктені, демек, бірнеше жұрнақты, сондай-ақ нүктенің болмауын, демек, жұрнақтың болмауын қамтиды. Multics жүйесінің кейбір бөлімдері мен оның үстінде жұмыс істейтін бағдарламалар файл түрлерін көрсету үшін жұрнақтарды пайдаланады, бірақ барлық файлдарда жұрнақ болуы міндетті емес. Мысалы, атқарылатын файлдар мен қарапайым мәтіндік файлдардың атауларында көбінесе жұрнақтар болмайды. UNIX сияқты операциялық жүйелердегі файлдық жүйелер де файл атауын бір жол ретінде сақтайды, "." символы файл атауындағы тағы бір символ ретінде қолданылады. Бірнеше жұрнағы бар файлдың бірнеше кеңейтімі бар деп айтылады, бірақ терминология осы мәселеде әртүрлі, ал көптеген авторлар кеңейтімді бір файл атауында біреуден көп болуына рұқсат етілмейтіндей етіп анықтайды. Бірнеше кеңейтім көбінесе файлдар сияқты ұялы түрлендірулерді білдіреді, мысалы, tar.gz (tar файл бір немесе бірнеше файлдан тұратын tar архиві екенін көрсетеді, ал gz tar архив файлының gzip көмегімен сығылғанын көрсетеді). Файлдарды түрлендіретін немесе жасайтын бағдарламалар кіріс файл атауларынан алынған атауларға тиісті кеңейтімді қосуы мүмкін (егер шығыс файл атауы нақты көрсетілмесе), бірақ файлдарды оқитын бағдарламалар әдетте осы ақпаратты елемейді; ол көбінесе пайдаланушыға арналған. Көбінесе, әсіресе екілік файлдарда, файлдың мазмұнын сипаттайтын ішкі немесе сыртқы метадеректерді қамтуы жиі кездеседі. Бұл модель әдетте командаларда толық файл атауын беруді талап етеді, ал метадеректер әдісі көбінесе кеңейтімді алып тастауға мүмкіндік береді. DOS және 16 биттік Windows жүйелерінде файл атауларында ең көп дегенде 8 символ, нүкте және 3 символдан тұратын кеңейтім болуы мүмкін. DOS және Windows жүйелері үшін FAT файлдық жүйесі файл атауларын 8 символдан тұратын атау және 3 символдан тұратын кеңейтім ретінде сақтайды. Нүкте символы сақталмайды. Microsoft және IBM-нің OS/2 жүйесінде қолданылатын жоғары өнімділік файлдық жүйесі (HPFS) файл атауын "." символы файл атауындағы тағы бір символ ретінде бір жол ретінде сақтайды. Жұрнақтарды пайдалану салты жалғасты, тіпті HPFS файлдар үшін кеңейтілген атрибуттарды қолдайды, бұл файлдың түрін файлда кеңейтілген атрибут ретінде сақтауға мүмкіндік береді. Microsoft-тың Windows NT жүйесінің түпкілікті файлдық жүйесі, NTFS және кейінірек ReFS де файл атауын бір жол ретінде сақтайды; тағы да, кеңейтімдерді имитациялау үшін жұрнақтарды пайдалану салты қолданыстағы Windows нұсқаларымен үйлесімділік үшін жалғасты. Windows NT 3.5 жүйесінде VFAT деп аталатын FAT файлдық жүйесінің нұсқасы пайда болды; ол ұзақ файл атауларын қолдайды, файл атауы бір жол ретінде қарастырылады. Windows 95 VFAT жүйесімен бірге ұзақ файл атауларын қолдауға кірісті және NT емес Windows жүйелерінен файл атауларындағы 8.3 атау/кеңейтім бөлінісін жойды. Классикалық Mac OS файл атауына негіделген кеңейтім метадеректерін толығымен жойды; оның орнына файл пішімін анықтау үшін файл түрінің ерекше кодын қолданды. Сонымен қатар, файлдың белгішесін екі рет шерту арқылы қандай бағдарлама іске қосылатынын анықтау үшін жасаушы коді келтірілді. macOS, алайда, UNIX сияқты NeXTSTEP операциялық жүйесінен алынғандықтан файл атауының жұрнақтарын қолданады, сондай-ақ типтік және жасаушы кодтарын пайдаланады. Commodore жүйелерінде файлдарда тек төрт кеңейтім болуы мүмкін: PRG, SEQ, USR, REL. Алайда, олар бағдарлама қолданатын дерек түрлерін бөліп алу үшін қолданылады және олардың мазмұнын анықтау үшін маңызды емес. Графикалық пайдаланушы интерфейстерінің пайда болуымен файлдарды басқару және интерфейс мінез-құлқы мәселесі туындады. Microsoft Windows бірнеше бағдарламаларды белгілі бір кеңейтіммен байланыстыруға мүмкіндік берді және қажетті бағдарламаны таңдау үшін әртүрлі әрекеттер қол жетімді болды, мысалы, файлды қарау, өңдеу немесе басып шығару арасында таңдауды ұсынатын контексттік мәзір. Кез келген кеңейтім бір файл түрін білдіреді деген болжам әлі де болды; кеңейтім мен белгіше арасында біркелкі сәйкестік болды. Интернет дәуірі алғаш келген кезде Windows жүйелерін қолданатындар әлі де 8.3 файл атаулары пішімімен шектелген веб-беттерді HTM кеңейтімімен құруға мәжбүр болды, ал Macintosh немесе UNIX компьютерлерін қолданатындар ұсынылатын html файл атауы кеңейтімін қолдана алды. Бұл Java бағдарламалау тілін тәжірибеден өткізетін бағдарламашылар үшін де проблемаға айналды, өйткені ол бастапқы код файлдары үшін төрт әріпті java жұрнағын және Java компиляторының объектілік кодты шығару үшін бес әріпті class жұрнағын талап етеді.

The Multics file system stores the file name as a single string, not split into base name and extension components, allowing the "." to be just another character allowed in file names. It allows for variable length filenames, permitting more than one dot, and hence multiple suffixes, as well as no dot, and hence no suffix. Some components of Multics, and applications running on it, use suffixes to indicate file types, but not all files are required to have a suffix — for example, executables and ordinary text files usually have no suffixes in their names. File systems for UNIX like operating systems also store the file name as a single string, with "." as just another character in the file name. A file with more than one suffix is sometimes said to have more than one extension, although terminology varies in this regard, and most authors define extension in a way that does not allow more than one in the same file name. More than one extension usually represents nested transformations, such as files. tar. gz (the tar indicates that the file is a tar archive of one or more files, and the gz indicates that the tar archive file is compressed with gzip). Programs transforming or creating files may add the appropriate extension to names inferred from input file names (unless explicitly given an output file name), but programs reading files usually ignore the information; it is mostly intended for the human user. It is more common, especially in binary files, for the file to contain internal or external metadata describing its contents. This model generally requires the full filename to be provided in commands, whereas the metadata approach often allows the extension to be omitted. In DOS and 16 bit Windows, file names have a maximum of 8 characters, a period, and an extension of up to three letters. The FAT file system for DOS and Windows stores file names as an 8 character name and a three character extension. The period character is not stored. The High Performance File System (HPFS), used in Microsoft and IBM's OS/2 stores the file name as a single string, with the "." character as just another character in the file name. The convention of using suffixes continued, even though HPFS supports extended attributes for files, allowing a file's type to be stored in the file as an extended attribute. Microsoft's Windows NT's native file system, NTFS, and the later ReFS, also store the file name as a single string; again, the convention of using suffixes to simulate extensions continued, for compatibility with existing versions of Windows. In Windows NT 3.5, a variant of the FAT file system, called VFAT appeared; it supports longer file names, with the file name being treated as a single string. Windows 95, with VFAT, introduced support for long file names, and removed the 8.3 name/extension split in file names from non NT Windows. The classic Mac OS disposed of filename based extension metadata entirely; it used, instead, a distinct file type code to identify the file format. Additionally, a creator code was specified to determine which application would be launched when the file's icon was double clicked. macOS, however, uses filename suffixes as a consequence of being derived from the UNIX like NeXTSTEP operating system, in addition to using type and creator codes. In Commodore systems, files can only have four extensions: PRG, SEQ, USR, REL. However, these are used to separate data types used by a program and are irrelevant for identifying their contents. With the advent of graphical user interfaces, the issue of file management and interface behavior arose. Microsoft Windows allowed multiple applications to be associated with a given extension, and different actions were available for selecting the required application, such as a context menu offering a choice between viewing, editing or printing the file. The assumption was still that any extension represented a single file type; there was an unambiguous mapping between extension and icon. When the Internet age first arrived, those using Windows systems that were still restricted to 8.3 filename formats had to create web pages with names ending in HTM, while those using Macintosh or UNIX computers could use the recommended html filename extension. This also became a problem for programmers experimenting with the Java programming language, since it requires the four letter suffix java for source code files and the five letter suffix class for Java compiler object code output files.

Мазмұн түрі

Файл атауының кеңейтімі метадеректердің бір түрі болып саналады. Олар көбінесе файлдағы деректердің қалай сақталатыны туралы ақпаратты білдіреді. Файл атауының қай бөлігі оның кеңейтімі екенін анықтау критерийлері нақты файл жүйесінің ережелеріне жатады; әдетте кеңейтім нүкте белгісінің соңғы кездесуінен кейін келетін тармақша болып табылады (мысалы: txt – readme.txt файлының кеңейтімі, ал html – index.html файлының кеңейтімі). Кейбір мейнфрейм жүйелерінің (мысалы, VM-дегі CMS, VMS) және PC жүйелерінің (мысалы, CP/M, MS DOS және олардан туындаған жүйелер) файлдық жүйелерінде кеңейтім файл атауынан бөлек кеңістік болып табылады. Microsoft DOS және Windows жүйелерінде EXE, COM немесе BAT сияқты кеңейтімдер файлдың орындалатын бағдарлама екенін көрсетеді. OS/360 және одан кейінгі жүйелерде деректер жинағы атауының соңғы нүктеден кейінгі бөлігі, «төменгі деңгейдегі анықтама» деп аталады, кейбір бағдарламалық құралдар (мысалы, TSO EDIT) оны кеңейтім ретінде қарастырады, бірақ операциялық жүйе үшін ерекше маңызы жоқ; бұл MVS-тегі Unix файлдарына да қатысты. Файл атауының кеңейтімі бастапқыда файлдың жалпы түрін анықтау үшін қолданылған. Файл түрін үш таңбаға дейін қысқарту қажеттілігі көбінесе қысқартылған кеңейтімдерге әкелді. Мысалдар: графикалық файлдар үшін GFX, қарапайым мәтін үшін TXT және музыка үшін MUS. Алайда, көптеген әртүрлі бағдарламалар осы дерек түрлерін (және басқаларын) әртүрлі жолдармен өңдейтін болғандықтан, файл атауының кеңейтімдері белгілі бір өнімдермен, тіпті олардың нақты нұсқаларымен байланысты бола бастады. Мысалы, WordStar-дың алғашқы файлдары WS немесе WSn кеңейтімдерін пайдаланды, мұнда n – бағдарлама нұсқасының нөмірі. Сондай-ақ, кейбір файл атауының кеңейтімдерін пайдалануда қайшылықтар туындады. Бір мысал – rpm, ол RPM Package Manager пакеттері мен RealPlayer Media файлдары үшін қолданылады. Басқалары: qif (DESQview қаріптері, Quicken қаржылық тізімдері және QuickTime суреттері үшін ортақ), gba (GrabIt скрипттері мен Game Boy Advance ROM кескіндері үшін ортақ), sb (SmallBasic және Scratch үшін қолданылады) және dts (Dynamix Three Space және DTS үшін қолданылады).

Filename extensions may be considered a type of metadata. They are commonly used to imply information about the way data might be stored in the file. The exact definition, giving the criteria for deciding what part of the file name is its extension, belongs to the rules of the specific file system used; usually the extension is the substring which follows the last occurrence, if any, of the dot character (example: txt is the extension of the filename readme. txt, and html the extension of index. html). On file systems of some mainframe systems such as CMS in VM, VMS, and of PC systems such as CP/M and derivative systems such as MS DOS, the extension is a separate namespace from the filename. Under Microsoft's DOS and Windows, extensions such as EXE, COM or BAT indicate that a file is a program executable. In OS/360 and successors, the part of the dataset name following the last period, called the low level qualifier, is treated as an extension by some software, e. g., TSO EDIT, but it has no special significance to the operating system itself; the same applies to Unix files in MVS. The filename extension was originally used to determine the file's generic type. The need to condense a file's type into three characters frequently led to abbreviated extensions. Examples include using GFX for graphics files, TXT for plain text, and MUS for music. However, because many different software programs have been made that all handle these data types (and others) in a variety of ways, filename extensions started to become closely associated with certain products—even specific product versions. For example, early WordStar files used WS or WSn, where n was the program's version number. Also, conflicting uses of some filename extensions developed. One example is rpm, used for both RPM Package Manager packages and RealPlayer Media files;. Others are qif, shared by DESQview fonts, Quicken financial ledgers, and QuickTime pictures; gba, shared by GrabIt scripts and Game Boy Advance ROM images; sb, used for SmallBasic and Scratch; and dts, being used for Dynamix Three Space and DTS.

MIME түрімен салыстырғанда

Көптеген интернет-протоколдарында, мысалы HTTP және MIME электрондық поштасында, бит ағынының түрі файл атауының кеңейтімі емес, ағынның медиа түрі немесе MIME түрі ретінде көрсетіледі. Бұл ағын алдындағы мәтін жолында беріледі, мысалы, "Мазмұн түрі: text/plain". Файл атауының кеңейтулері мен медиа түрлері арасында стандартты сәйкестік жоқ, нәтижесінде файлдарды интернет арқылы беру кезінде авторлар, веб-серверлер және клиенттік бағдарламалық жасақтама арасында түсіндіруде қарама-қайшылықтар туындауы мүмкін. Мысалы, мазмұн авторы сығылған Scalable Vector Graphics файлы үшін "svgz" кеңейтімін көрсетуі мүмкін, бірақ бұл кеңейтімді танымайтын веб-сервер дұрыс медиа түрін "application/svg+xml" және қажетті қысу басқасын жібермеуі мүмкін, нәтижесінде веб-браузерлер кескінді дұрыс түсіндіріп, көрсетуге шамасы келмейді. BeOS жүйесінің BFS файлдық жүйесі кеңейтілген атрибуттарды қолдайды, сондықтан файлды оның медиа түрімен кеңейтілген атрибут ретінде белгілейді. KDE және GNOME сияқты кейбір десктоп орталары файл атауының соңғы бөлігін және файлдың мазмұнын "file" командасы сияқты эвристикалық әдіспен қарастырып, файлқа медиа түрін байланыстырады. Олар файл ашылған кезде іске қосылатын бағдарламаны осы медиа түріне сүйене отырып таңдайды, бұл файл атауының кеңейтімдеріне тәуелділікті азайтады. macOS файл түрін ішкі түрде анықтау үшін Бірыңғай түрін анықтаушыны таңдау үшін файл атауының кеңейтімдерін, медиа түрлерін және файл түрінің кодтарын пайдаланады.

Орындалатын бағдарламалар

Команда атауында файл кеңейтімінің қолданылуы кейде кездеседі, әдетте команданың скрипт ретінде жүзеге асырылуының қосымша салдары ретінде, мысалы, Bourne shell немесе Python үшін, ал интерпретатор атауы команда атауына қосымша жазылады. Бұл файл кеңейтімі мен интерпретатор арасындағы байланыстарға сүйенетін жүйелерде кең таралған практика, бірақ Unix сияқты жүйелерде, мысалы Linux, Oracle Solaris, BSD негізделген жүйелер және Apple-дің macOS, мұнда интерпретатор әдетте скриптте ("shebang") бас жазба ретінде көрсетіледі. Қауымдастыққа негізделген жүйелерде файл кеңейтімі әдетте сол кеңейтім үшін жүйелік деңгейдегі жалғыз интерпретаторға сәйкес келеді (мысалы, ".py" Python-ды пайдалануды білдіреді), ал команданың өзі кеңейтімсіз де командалық жолдан орындалуы мүмкін (тиісті параметрлер орнатылған жағдайда). Егер орындалу тілі өзгерсе, команда атауының кеңейтімі де өзгереді, ал операциялық жүйе екі жағдайда да кеңейтімсіз команданың нұсқасын пайдалануға мүмкіндік беретін біркелкі API ұсынады. Бұл әдіс қауымдастық картасының жаһандық сипатынан, сондай-ақ бағдарламаларды шақыру кезінде әзірлеушілердің кеңейтімдерді толыққанды болдырмауынан және олардың мұндай болдырмауды міндеттеуге мүмкіндігі болмауынан зардап шегеді. Windows осы механизмді қолданатын жалғыз кең таралған жүйе болып табылады. Интерпретатор директивалары бар жүйелерде, Unix-тің барлық нұсқаларын қоса алғанда, команда атауының кеңейтімдері ерекше мағынаға ие емес және стандартты тәжірибе бойынша қолданылмайды, өйткені скрипттер үшін интерпретаторларды орнатудың негізгі әдісі – оларды интерпретаторды анықтайтын бір жолмен бастау (мұны дегенеративті ресурс вилкасы ретінде қарастыруға болады). Мұндай ортада команда атауына кеңейтімді қосу қажетсіздей, басқа бағдарламалардан командаларға жасалған барлық сілтемелерді болашақтағы өзгерістерге қауіпті ететін орындалу егжей-тегжейін ашады. Мысалы, қабықша скрипті Python немесе Ruby-де, кейін C немесе C++-та қайта іске асырылуы мүмкін, бұл жағдайда кеңейтімдер қолданылса, команданың аты өзгеретін болар еді. Кеңейтімдерсіз бағдарлама әрқашан бірдей кеңейтімсіз атауға ие болады, тек интерпретатор директивасы және/немесе магиялық сан өзгереді, ал басқа бағдарламалардан бағдарламаға жасалған сілтемелер жарамды болып қалады.

The use of a filename extension in a command name appears occasionally, usually as a side effect of the command having been implemented as a script, e. g., for the Bourne shell or for Python, and the interpreter name being suffixed to the command name, a practice common on systems that rely on associations between filename extension and interpreter, but sharply deprecated in Unix like systems, such as Linux, Oracle Solaris, BSD based systems, and Apple's macOS, where the interpreter is normally specified as a header in the script ("shebang"). On association based systems, the filename extension is generally mapped to a single, system wide selection of interpreter for that extension (such as ". py" meaning to use Python), and the command itself is runnable from the command line even if the extension is omitted (assuming appropriate setup is done). If the implementation language is changed, the command name extension is changed as well, and the OS provides a consistent API by allowing the same extensionless version of the command to be used in both cases. This method suffers somewhat from the essentially global nature of the association mapping, as well as from developers' incomplete avoidance of extensions when calling programs, and that developers can not force that avoidance. Windows is the only remaining widespread employer of this mechanism. On systems with interpreter directives, including virtually all versions of Unix, command name extensions have no special significance, and are by standard practice not used, since the primary method to set interpreters for scripts is to start them with a single line specifying the interpreter to use (which could be viewed as a degenerate resource fork). In these environments, including the extension in a command name unnecessarily exposes an implementation detail which puts all references to the commands from other programs at future risk if the implementation changes. For example, it would be perfectly normal for a shell script to be reimplemented in Python or Ruby, and later in C or C++, all of which would change the name of the command were extensions used. Without extensions, a program always has the same extension less name, with only the interpreter directive and/or magic number changing, and references to the program from other programs remain valid.

Қауіпсіздік мәселелері

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 сияқты жүйелерде кеңейтімі жоқ файлдарды кездестіру жиі кездеседі, себебі файлдың мазмұнын анықтау үшін файл сияқты командаларды пайдалану керек, олар файлдың тақырып бөлігін оқып шығады.

The default behavior of File Explorer, the file browser provided with Microsoft Windows, is for filename extensions to not be displayed. Malicious users have tried to spread computer viruses and computer worms by using file names formed like LOVE LETTER FOR YOU. TXT. vbs. The hope is that this will appear as LOVE LETTER FOR YOU. TXT, a harmless text file, without alerting the user to the fact that it is a harmful computer program, in this case, written in VBScript. Default behavior for ReactOS is to display filename extensions in ReactOS Explorer. Later Windows versions (starting with Windows XP Service Pack 2 and Windows Server 2003) included customizable lists of filename extensions that should be considered "dangerous" in certain "zones" of operation, such as when downloaded from the web or received as an e mail attachment. Modern antivirus software systems also help to defend users against such attempted attacks where possible. Some viruses take advantage of the similarity between the ". com" top level domain and the ". COM" filename extension by emailing malicious, executable command file attachments under names superficially similar to URLs (e. g., "myparty. yahoo. com"), with the effect that unaware users click on email embedded links that they think lead to websites but actually download and execute the malicious attachments. There have been instances of malware crafted to exploit vulnerabilities in some Windows applications which could cause a stack based buffer overflow when opening a file with an overly long, unhandled filename extension. The filename extension is just a marker and the content of the file does not have to match it. This can be used to disguise malicious content. When trying to identify a file for security reasons, it is therefore considered dangerous to rely on the extension alone and a proper analysis of the content of the file is preferred. For example, on UNIX like systems, it is not uncommon to find files with no extensions at all, as commands such as file are meant to be used instead, and will read the file's header to determine its content.