Dateinamenerweiterung - Filename extension

Eine Dateinamenerweiterung , Dateierweiterung oder ein Dateityp ist eine Kennung, die als Suffix an den Namen einer Computerdatei angegeben wird . Die Erweiterung weist auf ein Merkmal des Dateiinhalts oder seinen Verwendungszweck hin. Eine Dateinamenerweiterung ist in der Regel aus dem Dateinamen mit einem begrenzten Punkt (Punkt), aber in einigen Systemen ist es durch Leerzeichen getrennt ist .

Einige Dateisysteme implementieren Dateinamenerweiterungen als ein Merkmal des Dateisystems selbst und können die Länge und das Format der Erweiterung einschränken, während andere Dateinamenerweiterungen ohne besondere Unterscheidung als Teil des Dateinamens behandeln.

Verwendungszweck

Dateinamenerweiterungen können als eine Art von Metadaten betrachtet werden . Sie werden häufig verwendet, um Informationen darüber zu implizieren, wie Daten in der Datei gespeichert werden könnten. Die genaue Definition, die die Kriterien für die Entscheidung darüber angibt, welcher Teil des Dateinamens seine Erweiterung ist, gehört zu den Regeln des spezifischen verwendeten Dateisystems ; normalerweise ist die Erweiterung die Teilzeichenfolge, die auf das letzte Vorkommen des Punktzeichens folgt ( Beispiel: txt ist die Erweiterung des Dateinamens readme.txtund htmldie Erweiterung von mysite.index.html). Auf Dateisystemen einiger Mainframe-Systeme wie CMS in VM , VMS und von PC-Systemen wie CP/M und abgeleiteten Systemen wie MS-DOS ist die Erweiterung ein separater Namensraum vom Dateinamen. Unter DOS und Windows von Microsoft weisen Erweiterungen wie EXE, COModer BATdarauf hin, dass eine Datei ein ausführbares Programm ist . In OS/360 und Nachfolgern wird der Teil des Datensatznamens nach dem letzten Punkt von einer Software, zB TSO EDIT, als Erweiterung behandelt , hat aber keine besondere Bedeutung für das Betriebssystem selbst; das gleiche gilt für Unix-Dateien in MVS.

Dateisysteme für UNIX-ähnliche Betriebssysteme trennen die Erweiterungsmetadaten nicht vom Rest des Dateinamens. Das Punktzeichen ist nur ein weiteres Zeichen im Hauptdateinamen. Ein Dateiname kann keine Erweiterungen, eine einzelne Erweiterung oder mehr als eine Erweiterung haben. Mehr als eine Erweiterung stellt in der Regel verschachtelte Transformationen, wie files.tar.gz(die .taranzeigt , dass die Datei ist ein tar - Archiv von einer oder mehreren Dateien, und das .gzzeigt , dass die tar - Archiv - Datei mit komprimiert gzip ). Programme, die Dateien umwandeln oder erstellen, können Namen, die aus Eingabedateinamen abgeleitet werden, die entsprechende Erweiterung hinzufügen (sofern nicht explizit ein Ausgabedateiname angegeben), aber Programme, die Dateien lesen, ignorieren die Informationen normalerweise; es ist hauptsächlich für den menschlichen Benutzer bestimmt. Insbesondere bei Binärdateien ist es üblicher, dass die Datei selbst interne Metadaten enthält , die ihren Inhalt beschreiben. Dieses Modell erfordert im Allgemeinen die Angabe des vollständigen Dateinamens in Befehlen, während der Metadatenansatz oft das Weglassen der Erweiterung ermöglicht.

Die Dateisysteme VFAT , NTFS und ReFS für Windows trennen auch die Erweiterungsmetadaten nicht vom Rest des Dateinamens und lassen mehrere Erweiterungen zu.

Mit dem Aufkommen von grafischen Benutzeroberflächen kam das Thema Dateiverwaltung und Oberflächenverhalten auf. Microsoft Windows ermöglichte es, mehrere Anwendungen mit einer bestimmten Erweiterung zu verknüpfen, und es standen verschiedene Aktionen zur Auswahl der erforderlichen Anwendung zur Verfügung, beispielsweise ein Kontextmenü, das die Wahl zwischen Anzeigen, Bearbeiten oder Drucken der Datei bot. Es wurde immer noch davon ausgegangen, dass jede Erweiterung einen einzelnen Dateityp darstellt; es gab eine eindeutige Zuordnung zwischen Erweiterung und Symbol.

Das klassische Mac OS verzichtete vollständig auf dateinamenbasierte Erweiterungsmetadaten; Stattdessen wurde ein eindeutiger Dateitypcode verwendet , um das Dateiformat zu identifizieren. Zusätzlich wird ein Creator - Code angegeben wurde , um zu bestimmen , welche Anwendung gestartet werden würde , wenn das Dateisymbol wurde doppelgeklickt . macOS verwendet jedoch Dateinamensuffixe sowie Typ- und Erstellercodes, da es vom UNIX-ähnlichen NeXTSTEP- Betriebssystem abgeleitet ist.

Verbesserungen

Die Dateinamenerweiterung wurde ursprünglich verwendet, um den generischen Typ der Datei zu bestimmen. Die Notwendigkeit, den Dateityp in drei Zeichen zu komprimieren, führte häufig zu abgekürzten Erweiterungen. Beispiele sind die Verwendung .GFXfür Grafikdateien, .TXTfür Nur-Text und .MUSfür Musik. Da jedoch viele verschiedene Softwareprogramme entwickelt wurden, die alle diese Datentypen (und andere) auf unterschiedliche Weise verarbeiten, wurden Dateinamenerweiterungen eng mit bestimmten Produkten verbunden – sogar mit bestimmten Produktversionen. Zum Beispiel verwendete frühe WordStar- Dateien .WSoder , wobei n die Versionsnummer des Programms war. Außerdem entwickelten sich widersprüchliche Verwendungen einiger Dateinamenerweiterungen. Ein Beispiel ist , das sowohl für RPM Package Manager- Pakete als auch für RealPlayer- Mediendateien verwendet wird;. Andere sind , geteilt von DESQview- Schriften, Quicken- Finanzbüchern und QuickTime- Bildern; , geteilt von GrabIt- Skripten und Game Boy Advance- ROM-Images; , verwendet für SmallBasic und Scratch ; und wird für Dynamix Three Space und DTS verwendet . .WSn.rpm.qif.gba.sb.dts

Einige andere Betriebssysteme, die Dateinamenerweiterungen verwendeten, hatten im Allgemeinen weniger Einschränkungen für Dateinamen. Viele erlaubten vollständige Dateinamenlängen von 14 oder mehr Zeichen, und maximale Namenslängen von bis zu 255 waren keine Seltenheit. Die Dateisysteme in Betriebssystemen wie Multics und UNIX speicherten den Dateinamen als einzelne Zeichenfolge, nicht aufgeteilt in Basisnamen- und Erweiterungskomponenten, wodurch das "." nur ein anderes Zeichen sein, das in Dateinamen erlaubt ist. Solche Systeme ermöglichen im Allgemeinen Dateinamen mit variabler Länge, die mehr als einen Punkt und somit mehrere Suffixe zulassen. Einige Komponenten von Multics und UNIX und darauf laufende Anwendungen verwendeten in einigen Fällen Suffixe, um Dateitypen anzugeben, aber sie verwendeten sie nicht so häufig – zum Beispiel hatten ausführbare Dateien und normale Textdateien keine Suffixe in ihren Namen.

Das High Performance File System (HPFS), verwendet in Microsoft und IBM ‚s OS / 2 auch lange Dateinamen unterstützt und hat den Dateinamen in einen Namen und eine Erweiterung nicht teilen. Die Konvention der Verwendung von Suffixen wurde fortgesetzt, obwohl HPFS erweiterte Attribute für Dateien unterstützte, wodurch der Dateityp als erweitertes Attribut in der Datei gespeichert werden konnte.

Das native Dateisystem von Microsoft Windows NT , NTFS , unterstützte lange Dateinamen und teilte den Dateinamen nicht in einen Namen und eine Erweiterung auf, aber auch hier wurde die Konvention der Verwendung von Suffixen zum Simulieren von Erweiterungen aus Gründen der Kompatibilität mit bestehenden Windows-Versionen fortgesetzt.

Als das Internetzeitalter anbrach, mussten Benutzer von Windows-Systemen, die noch auf 8.3- Dateinamenformate beschränkt waren, Webseiten mit der Endung .HTM, erstellen , während Benutzer von Macintosh- oder UNIX-Computern die empfohlene .htmlDateinamenerweiterung verwenden konnten. Dies wurde auch zu einem Problem für Programmierer, die mit der Programmiersprache Java experimentieren , da sie das vierbuchstabige Suffix für Quellcodedateien und das fünfbuchstabige Suffix für Java- Compiler- Objektcode- Ausgabedateien erfordert . .java.class

Schließlich führte Windows 95 in einer erweiterten Version des häufig verwendeten FAT- Dateisystems namens VFAT die Unterstützung für lange Dateinamen ein und entfernte die 8.3-Namens-/Erweiterungsaufteilung in Dateinamen von Nicht-NT-Windows . VFAT erschien zuerst in Windows NT 3.5 und Windows 95 . Die interne Implementierung von langen Dateinamen in VFAT ist weitgehend auf sein ein als Flickschusterei , aber es entfernt die wichtige Längenbeschränkung und Dateien erlaubt eine Mischung aus haben Großbuchstaben und Kleinbuchstaben Buchstaben, auf Maschinen , die nicht laufen würde Windows NT gut.

Probleme mit dem Befehlsnamen

Die Verwendung einer Dateinamenerweiterung in einem Befehlsnamen tritt gelegentlich auf, normalerweise als Nebeneffekt, dass der Befehl als Skript implementiert wurde, z. B. für die Bourne-Shell oder für Python , und der Interpretername an den Befehlsnamen angehängt wird, a gängige Praxis auf Systemen, die auf Verknüpfungen zwischen Dateinamenerweiterung und Interpreter angewiesen sind, aber in Unix-ähnlichen Systemen wie Linux , Oracle Solaris , BSD- basierten Systemen und Apples macOS stark veraltet , wo der Interpreter normalerweise als Header in der Datei angegeben wird Skript (" Shebang ").

Auf assoziationsbasierten Systemen wird die Dateinamenerweiterung im Allgemeinen einer einzigen, systemweiten Auswahl von Interpretern für diese Erweiterung zugeordnet (z die Erweiterung wird weggelassen (vorausgesetzt, dass die entsprechende Einrichtung erfolgt ist). Wenn die Implementierungssprache geändert wird, wird auch die Befehlsnamenerweiterung geändert, und das Betriebssystem stellt eine konsistente API bereit, indem in beiden Fällen dieselbe erweiterungslose Version des Befehls verwendet werden kann. Diese Methode leidet etwas unter der im Wesentlichen globalen Natur der Zuordnungszuordnung sowie unter der unvollständigen Vermeidung von Erweiterungen durch Entwickler beim Aufrufen von Programmen, und dass Entwickler diese Vermeidung nicht erzwingen können. Windows ist der einzige verbleibende verbreitete Arbeitgeber dieses Mechanismus.

Auf Systemen mit Interpreter-Direktiven , einschließlich praktisch aller Unix-Versionen, haben Befehlsnamenerweiterungen keine besondere Bedeutung und werden standardmäßig nicht verwendet, da die primäre Methode zum Einstellen von Interpretern für Skripte darin besteht, sie mit einer einzigen Zeile zu starten, die den Interpreter auf use (was als degenerierter Ressourcenzweig angesehen werden könnte ). In diesen Umgebungen legt das Einschließen der Erweiterung in einen Befehlsnamen unnötigerweise ein Implementierungsdetail offen, das alle Verweise auf die Befehle von anderen Programmen einem zukünftigen Risiko aussetzt, wenn sich die Implementierung ändert. Es wäre zum Beispiel völlig normal, dass ein Shell-Skript in Python oder Ruby und später in C oder C++ neu implementiert würde, was alle den Namen des Befehls ändern würde, wenn Erweiterungen verwendet würden. Ohne Erweiterungen hat ein Programm immer denselben Namen ohne Erweiterungen, wobei sich nur die Interpreter-Direktive und/oder die magische Zahl ändern, und Verweise auf das Programm von anderen Programmen bleiben gültig.

Sicherheitsprobleme

Das Standardverhalten des Datei-Explorers , des mit Microsoft Windows bereitgestellten Dateibrowsers , besteht darin, dass Dateinamenerweiterungen nicht angezeigt werden. Böswillige Benutzer haben versucht, Computerviren und Computerwürmer zu verbreiten, indem sie Dateinamen wie LOVE-LETTER-FOR-YOU.TXT.vbs. Die Hoffnung ist, dass dies als LOVE-LETTER-FOR-YOU.TXTharmlose Textdatei erscheint, ohne den Benutzer darauf aufmerksam zu machen, dass es sich um ein schädliches Computerprogramm handelt, in diesem Fall in VBScript geschrieben . Das Standardverhalten von ReactOS besteht darin, Dateinamenerweiterungen im ReactOS Explorer anzuzeigen .

Später Windows - Versionen (ab Windows XP Service Pack 2 und Windows Server 2003 ) enthielten anpassbare Listen von Dateierweiterungen , die „gefährlich“ in bestimmten „Zonen“ des Betriebes in Betracht gezogen werden sollten, wie wenn heruntergeladen aus dem Web oder als E empfing Mailanhang. Moderne Antiviren-Softwaresysteme helfen zudem, die Nutzer nach Möglichkeit vor solchen Angriffsversuchen zu schützen.

Einige Viren machen sich die Ähnlichkeit zwischen der Top-Level-Domain.com “ und der Dateinamenerweiterung „.COM“ zunutze, indem sie bösartige, ausführbare Befehlsdatei-Anhänge per E-Mail unter Namen versenden, die oberflächlich URLs ähneln ( z. B. „myparty.yahoo.com“ ).

Es gab Fälle von Malware, die entwickelt wurde, um Schwachstellen in einigen Windows-Anwendungen auszunutzen, die beim Öffnen einer Datei mit einer zu langen, unbehandelten Dateinamenerweiterung einen Stapel-basierten Pufferüberlauf verursachen konnten .

Die Dateinamenerweiterung ist nur eine Markierung und der Inhalt der Datei muss nicht damit übereinstimmen. Dies kann verwendet werden, um schädliche Inhalte zu verschleiern. Aus Sicherheitsgründen wird es daher als gefährlich angesehen, sich bei dem Versuch, eine Datei zu identifizieren, auf die Erweiterung allein zu verlassen, und eine ordnungsgemäße Analyse des Inhalts der Datei wird bevorzugt. Auf UNIX- abgeleiteten Systemen ist es beispielsweise nicht ungewöhnlich, Dateien ohne Erweiterungen zu finden, da stattdessen Befehle wie file (command) verwendet werden sollen und den Header der Datei lesen, um ihren Inhalt zu bestimmen.

Alternativen

In vielen Internetprotokollen wie HTTP und MIME-E-Mail wird der Typ eines Bitstreams als Medientyp oder MIME-Typ des Streams und nicht als Dateinamenerweiterung angegeben. Dies wird in einer Textzeile vor dem Stream angegeben, z. B. Content-type: text/plain .

Es gibt keine Standardzuordnung zwischen Dateinamenerweiterungen und Medientypen, was zu möglichen Interpretationsunterschieden zwischen Autoren, Webservern und Client-Software bei der Übertragung von Dateien über das Internet führt. Zum Beispiel kann ein Inhaltsautor die Erweiterung svgz für eine komprimierte Scalable Vector Graphics- Datei angeben , aber ein Webserver, der diese Erweiterung nicht erkennt, sendet möglicherweise nicht den richtigen Inhaltstyp application/svg+xml und den erforderlichen Komprimierungsheader, wodurch Webbrowser übrig bleiben kann das Bild nicht richtig interpretieren und anzeigen.

BeOS , dessen BFS- Dateisystem erweiterte Attribute unterstützt, würde eine Datei mit ihrem Medientyp als erweitertes Attribut kennzeichnen. Die KDE- und GNOME- Desktopumgebungen verknüpfen einen Medientyp mit einer Datei, indem sie sowohl das Dateinamensuffix als auch den Inhalt der Datei in der Art des Dateibefehls als heuristische . Sie wählen die Anwendung aus, die beim Öffnen einer Datei basierend auf diesem Medientyp gestartet wird, wodurch die Abhängigkeit von Dateinamenerweiterungen verringert wird. macOS verwendet sowohl Dateinamenerweiterungen und Medientypen als auch Dateitypcodes , um einen Uniform Type Identifier auszuwählen , anhand dessen der Dateityp intern identifiziert wird.

Siehe auch

Verweise

Externe Links