Filnavn udvidelse - Filename extension

En filnavn , filtype eller filtype er en identifikator, der er angivet som et suffiks til navnet på en computerfil . Udvidelsen angiver en egenskab ved filindholdet eller den tilsigtede anvendelse. En filnavnudvidelse er typisk afgrænset fra filnavnet med et punktum (punktum), men i nogle systemer er det adskilt med mellemrum.

Nogle filsystemer implementerer filnavnudvidelser som en funktion i selve filsystemet og kan begrænse længden og formatet på udvidelsen, mens andre behandler filnavnudvidelser som en del af filnavnet uden særlig forskel.

Anvendelse

Filnavnudvidelser kan betragtes som en type metadata . De bruges ofte til at antyde oplysninger om den måde, data kan gemmes i filen. Den nøjagtige definition, der giver kriterierne for at beslutte, hvilken del af filnavnet, der er dens udvidelse, tilhører reglerne for det specifikke filsystem, der bruges; normalt er udvidelsen delstrengen, der følger den sidste forekomst, hvis nogen, af punkttegnet ( eksempel: txt er filnavnets udvidelse readme.txtog htmludvidelsen af mysite.index.html). På filsystemer i nogle mainframe-systemer, f.eks. CMS i VM , VMS og pc-systemer som CP/M og afledte systemer som MS-DOS , er udvidelsen et separat navneområde fra filnavnet. Under Microsofts DOS og Windows , udvidelser som f.eks EXE. COMEller BATangiver, at en fil er et program, der kan eksekveres . I OS/360 og efterfølgere behandles den del af datasættets navn, der følger efter den sidste periode, som en udvidelse af noget software, f.eks. TSO EDIT, men det har ingen særlig betydning for selve operativsystemet; det samme gælder Unix -filer i MVS.

Filsystemer til UNIX-lignende operativsystemer adskiller ikke udvidelsesmetadata fra resten af ​​filnavnet. Punkttegnet er bare endnu et tegn i hovedfilnavnet. Et filnavn må ikke have udvidelser, en enkelt udvidelse eller mere end én udvidelse. Mere end én udvidelse repræsenterer normalt indlejrede transformationer, f.eks. files.tar.gz( .tarAngiver, at filen er et tar -arkiv med en eller flere filer, og .gzangiver, at tar -arkivfilen er komprimeret med gzip ). Programmer, der transformerer eller opretter filer, kan tilføje den relevante udvidelse til navne, der udledes af inputfilnavne (medmindre det udtrykkeligt gives et outputfilnavn), men programmer, der læser filer, ignorerer normalt oplysningerne; det er for det meste beregnet til den menneskelige bruger. Det er mere almindeligt, især i binære filer, at selve filen indeholder interne metadata, der beskriver dens indhold. Denne model kræver generelt, at hele filnavnet findes i kommandoer, hvorimod metadata -metoden ofte tillader, at udvidelsen udelades.

De VFAT , NTFS , og Refs filsystemer til Windows heller ikke adskille forlængelsen metadata fra resten af filnavnet, og tillade flere udvidelser.

Med fremkomsten af grafiske brugergrænseflader opstod spørgsmålet om filhåndtering og grænsefladeadfærd. Microsoft Windows tillod, at flere applikationer blev knyttet til en given udvidelse, og forskellige handlinger var tilgængelige for at vælge det nødvendige program, f.eks. En kontekstmenu, der giver mulighed for at vælge mellem visning, redigering eller udskrivning af filen. Antagelsen var stadig, at enhver udvidelse repræsenterede en enkelt filtype; der var en entydig kortlægning mellem udvidelse og ikon.

Det klassiske Mac OS bortskaffede filnavnbaserede udvidelsesmetadata helt; den brugte i stedet en tydelig filtypekode til at identificere filformatet. Derudover blev der angivet en skaberkode for at afgøre, hvilket program der ville blive lanceret, når filens ikon blev dobbeltklikket . macOS bruger imidlertid filnavnsuffikser samt type- og skaberkoder som en konsekvens af at være afledt af det UNIX-lignende NeXTSTEP- operativsystem.

Forbedringer

Filnavnens udvidelse blev oprindeligt brugt til at bestemme filens generiske type. Behovet for at kondensere en filtype til tre tegn førte ofte til forkortede udvidelser. Eksempler omfatter brug .GFXtil grafikfiler, .TXTtil almindelig tekst og .MUStil musik. Men fordi der er blevet lavet mange forskellige softwareprogrammer, der alle håndterer disse datatyper (og andre) på forskellige måder, begyndte filnavnudvidelser at blive tæt forbundet med visse produkter - endda specifikke produktversioner. For eksempel bruges tidlige WordStar -filer .WSeller , hvor n var programmets versionsnummer. Også modstridende anvendelser af nogle filnavnudvidelser udviklet. Et eksempel er brugt til både RPM Package Manager -pakker og RealPlayer -mediefiler ;. Andre deles af DESQview -skrifttyper, Quicken -finansbøger og QuickTime -billeder ; , delt af GrabIt -scripts og Game Boy Advance ROM -billeder; , bruges til SmallBasic og Scratch ; og bruges til Dynamix Three Space og DTS . .WSn.rpm.qif.gba.sb.dts

Nogle andre operativsystemer, der brugte filnavnudvidelser, havde generelt færre begrænsninger for filnavne. Mange tilladte fulde filnavnlængder på 14 eller flere tegn, og maksimale navnelængder op til 255 var ikke ualmindelige. Filsystemerne i operativsystemer som Multics og UNIX lagrede filnavnet som en enkelt streng, ikke opdelt i basenavn og udvidelseskomponenter, hvilket tillod "." at være bare endnu et tegn tilladt i filnavne. Sådanne systemer tillader generelt filnavne med variabel længde, hvilket tillader mere end en prik og dermed flere endelser. Nogle komponenter i Multics og UNIX og applikationer, der kører på dem, brugte i nogle tilfælde suffikser til at angive filtyper, men de brugte dem ikke så meget - f.eks. Havde eksekverbare filer og almindelige tekstfiler ingen suffikser i deres navne.

Den High Performance File System (HPFS), der anvendes i Microsoft og IBM 's OS / 2 understøttes også længe filnavne og ikke opdele filnavnet i et navn og en udvidelse. Konventionen om at bruge suffikser fortsatte, selvom HPFS understøttede udvidede attributter til filer, hvilket tillod en filtype at blive gemt i filen som en udvidet attribut.

Microsofts Windows NT 's native filsystem, NTFS , understøttede lange filnavne og opdelte ikke filnavnet i et navn og en udvidelse, men igen fortsatte konventionen om at bruge suffikser til at simulere udvidelser, for kompatibilitet med eksisterende versioner af Windows.

Da internetalderen først ankom, skulle dem, der brugte Windows -systemer, der stadig var begrænset til 8,3 filnavnformater, oprette websider med navne, der slutter med .HTM, mens dem, der bruger Macintosh- eller UNIX -computere, kunne bruge den anbefalede .htmlfilnavnudvidelse. Dette blev også et problem for programmører, der eksperimenterede med Java-programmeringssproget , da det kræver suffixet på fire bogstaver .javatil kildekodefiler og suffikset på fem bogstaver .classtil Java- compiler- objektkodeoutputfiler .

Til sidst introducerede Windows 95 understøttelse af lange filnavne og fjernede 8.3 navn/udvidelsesopdelingen i filnavne fra ikke-NT Windows i en udvidet version af det almindeligt anvendte FAT- filsystem kaldet VFAT . VFAT dukkede først op i Windows NT 3.5 og Windows 95 . Den interne implementering af lange filnavne i VFAT betragtes stort set som et kludge , men det fjernede den vigtige længdebegrænsning og tillod filer at have en blanding af store og små bogstaver på maskiner, der ikke ville køre Windows NT godt.

Problemer med kommandoenavne

Brugen af ​​en filtypenavn i et kommandonavn vises lejlighedsvis, normalt som en bivirkning af kommandoen, der er blevet implementeret som et script, f.eks. For Bourne -skallen eller for Python , og fortolkernavnet føjes til kommandoenavnet, et almindelig praksis på systemer, der er afhængige af associationer mellem filnavnudvidelse og tolk, men kraftigt forældet i Unix -lignende systemer, såsom Linux , Oracle Solaris , BSD -baserede systemer og Apples macOS , hvor tolken normalt er angivet som en overskrift i script (" shebang ").

På foreningsbaserede systemer tilknyttes filtypenavnet generelt til et enkelt, systemomfattende udvalg af tolk til denne udvidelse (f.eks. ".Py", der betyder at bruge Python), og selve kommandoen kan køres fra kommandolinjen, selvom udvidelsen udelades (forudsat at passende opsætning er udført). Hvis implementeringssproget ændres, ændres udvidelsen af ​​kommandonavn også, og operativsystemet giver en konsekvent API ved at tillade, at den samme udvidelsesløse version af kommandoen bruges i begge tilfælde. Denne metode lider noget under sammenslutningskortlægningens i det væsentlige globale karakter såvel som udvikleres ufuldstændige undgåelse af udvidelser, når de kalder programmer, og at udviklere ikke kan tvinge denne undgåelse. Windows er den eneste tilbageværende udbredte arbejdsgiver for denne mekanisme.

På systemer med tolkedirektiver , herunder stort set alle versioner af Unix, har kommandoenavneudvidelser ingen særlig betydning og bruges ved standardpraksis ikke, da den primære metode til at indstille tolke til scripts er at starte dem med en enkelt linje, der angiver tolken til brug (som kunne ses som en degenereret ressourcegaffel ). I disse miljøer, herunder udvidelse i et kommandonavn, udsætter unødvendigt en implementeringsdetalje, der udsætter alle referencer til kommandoer fra andre programmer i fremtiden, hvis implementeringen ændres. For eksempel ville det være helt normalt, at et shell -script blev genimplementeret i Python eller Ruby, og senere i C eller C ++, som alle ville ændre kommandoens navn, hvis udvidelser blev brugt. Uden udvidelser har et program altid det samme navn uden filtypenavn, idet kun tolketdirektivet og/eller det magiske nummer ændres, og referencer til programmet fra andre programmer forbliver gyldige.

Sikkerhedsspørgsmål

Standardadfærden for File Explorer , filbrowseren, der leveres med Microsoft Windows , er, at filnavnudvidelser ikke skal vises. Ondsindede brugere har forsøgt at sprede computervirus og computorme ved hjælp af filnavne, der er formet som LOVE-LETTER-FOR-YOU.TXT.vbs. Håbet er, at dette vil fremstå som LOVE-LETTER-FOR-YOU.TXTen harmløs tekstfil uden at advare brugeren om, at det er et skadeligt computerprogram, i dette tilfælde, skrevet i VBScript . Standardadfærd for ReactOS er at vise filnavnudvidelser i ReactOS Explorer .

Senere Windows-versioner (startende med Windows XP Service Pack 2 og Windows Server 2003 ) inkluderede tilpassede lister over filnavnudvidelser, der skulle betragtes som "farlige" i visse "zoner", f.eks. Når de downloades fra internettet eller modtages som en e- vedhæftet fil. Moderne antivirus -softwaresystemer hjælper også med at forsvare brugere mod sådanne forsøg på angreb, hvor det er muligt.

Nogle vira drager fordel af ligheden mellem " .com " -domænet på topniveau og filtypenavnet ".COM" ved at e-maile ondsindede, eksekverbare kommandofilvedhæftede filer under navne, der overfladisk ligner webadresser ( f.eks . "Myparty.yahoo.com" ), med den virkning, at uvidende brugere klikker på e-mail-integrerede links, som de mener fører til websteder, men faktisk downloader og udfører de ondsindede vedhæftede filer.

Der har været tilfælde af malware, der er designet til at udnytte sårbarheder i nogle Windows-applikationer, hvilket kan forårsage et stakbaseret bufferoverløb, når en fil åbnes med en alt for lang filhåndteringsforlængelse, der er alt for lang.

Filnavnens udvidelse er kun en markør, og filens indhold behøver ikke at matche den. Dette kan bruges til at skjule ondsindet indhold. Når man forsøger at identificere en fil af sikkerhedsmæssige årsager, betragtes det derfor som farligt at stole på udvidelsen alene, og en korrekt analyse af filens indhold foretrækkes. For eksempel på UNIX -afledte systemer er det ikke ualmindeligt at finde filer uden nogen udvidelser, da kommandoer som fil (kommando) er beregnet til at blive brugt i stedet, og vil læse filens overskrift for at bestemme dens indhold.

Alternativer

I mange internetprotokoller , f.eks. HTTP- og MIME -e -mail, angives typen af ​​en bitstrøm som medietypen eller MIME -typen af ​​strømmen i stedet for en filnavnudvidelse. Dette er angivet i en tekstlinje forud for strømmen, f.eks. Indholdstype: tekst/almindelig .

Der er ingen standardmapping mellem filnavnudvidelser og medietyper, hvilket resulterer i mulige uoverensstemmelser i fortolkningen mellem forfattere, webservere og klientsoftware, når filer overføres over internettet. For eksempel kan en indholdsforfatter angive udvidelsen svgz for en komprimeret skalerbar vektorgrafikfil , men en webserver, der ikke genkender denne udvidelse, sender muligvis ikke den korrekte indholdstypeapplikation /svg+xml og dens nødvendige komprimeringsoverskrift, så webbrowsere forlades ikke i stand til korrekt at fortolke og vise billedet.

BeOS , hvis BFS -filsystem understøtter udvidede attributter, ville mærke en fil med dens medietype som en udvidet attribut. De KDE og GNOME desktop-miljøer knytte en medietype med en fil ved at undersøge både filnavnet endelse og indholdet af filen, i mode af filen kommando, som en heuristisk . De vælger det program, der skal startes, når en fil åbnes baseret på denne medietype, hvilket reducerer afhængigheden af ​​filnavnudvidelser. macOS bruger både filnavnudvidelser og medietyper samt filtypekoder til at vælge en Uniform Type Identifier, hvormed filtypen kan identificeres internt.

Se også

Referencer

eksterne links