Dateinamenserweiterung
Die Dateinamenserweiterung (englisch filename extension), auch als Dateinamenerweiterung, Dateierweiterung, Dateiendung oder Dateisuffix bezeichnet, ist der letzte Teil eines Dateinamens und wird gewöhnlich mit einem Punkt abgetrennt (wobei der Punkt selbst nicht als Teil der Erweiterung angesehen wird). Die Dateiendung wird oft eingesetzt, um das Format einer Datei erkennbar zu machen, um sie so beispielsweise gleich mit einem passenden Anwendungsprogramm öffnen zu können. Sie wird teils in gleicher Weise auf Verzeichnisse angewandt.
Beispiel: name.txt
kennzeichnet eine einfache Textdatei.
Da Dateiendungen nicht normiert sind, kann es passieren, dass eine Dateinamenserweiterung für verschiedene Dateitypen verwendet wird.
Durch einfaches Umbenennen einer Datei kann man die Dateiendung ändern. So kann eine Textdatei datei.txt
in datei.zip
umbenannt werden. Versucht man nun datei.zip
zu öffnen, gehen manche Betriebssysteme davon aus, dass es sich hierbei um ein ZIP-Archiv handelt, scheitern aber beim Versuch dieses zu öffnen, da das Dateiformat an sich nicht verändert wurde. Um den Benutzer am versehentlichen Ändern der Dateiendung zu hindern, blenden einige Betriebssysteme gängige Dateiendungen per Voreinstellung aus.
Verwendung
Einige Betriebssysteme und auch einige Einzelprogramme sind nicht in der Lage, den Typ einer Datei ohne Suffix zu erkennen. Unter einigen gängigen Betriebssystemen, speziell Windows und VMS, werden Dateiendungen bestimmten Anwendungen zugeordnet (Dateizuordnungen). Aktiviert man eine Datei in einem Dateimanager, so wird diese mit dem zugeordneten Programm geöffnet.
Andere Betriebssysteme, wie AmigaOS, macOS, klassisches Mac OS oder Unix, haben zusätzliche Mechanismen zur Bestimmung des Dateiformats bzw. Verwendungszwecks einer Datei und verwenden die Dateiendung zum Teil für eine genauere Bestimmung des Formats oder andere Zwecke (zum Beispiel für die Versions- oder Plattformangabe bei Bibliotheken). Manchmal wird auch eine Kombination aus beiden Ansätzen verwendet; beispielsweise verlässt sich die KDE-Desktop-Umgebung, z. B. unter Linux, zunächst auf die Dateiendung; fehlt diese jedoch oder ist sie im System unbekannt, wird anhand des Inhalts der Datei versucht, den Typ zu erkennen. Auch macOS nutzt eine Mischung aus Dateiendung und Inhalt zur Bestimmung des Dateityps.
Die eigentlich vorteilhaftere Kennzeichnung des Dateityps in separat gespeicherten Datei-Metadaten, einer Form von Out-of-band-Signalisierung, wurde beispielsweise beim klassischen Mac OS in Form eines speziellen Dateibereiches, der Resource Fork, genutzt. Darin wurde neben dem Dateityp auch das Programm zum Öffnen gespeichert. Auch auf OS/2 wird Dateityp und verknüpftes Programm in den Metadaten einer jeden Datei im Dateisystem HPFS gespeichert.
Auf DOS für IBM-PC-kompatible PCs, die in den 1980er und 1990er Jahren größte Verbreitung fanden, wird keine Art der Kennzeichnung genutzt, außer die durch den Benutzer oder teilweise durch das jeweilige Anwendungsprogramm automatisch vergebene Erweiterung. Betriebssystemseitig gibt es jedoch keinerlei Prüfung oder Warnung bei inkorrekter Wahl oder Veränderung der Dateinamenserweiterung, die außerdem gemäß 8.3 auf drei Zeichen beschränkt und ohnehin optional ist.
Auf allen Betriebssystemen lässt sich rein über die Dateiendung nicht sicher bestimmen, ob eine Datei tatsächlich in dem angegebenen Dateiformat vorliegt. Das geht nur, wenn die Datei geöffnet und der Inhalt, beispielsweise die Informationen im Datei-Header (Magische Zahl) oder charakteristische Zeichenfolgen (Datensignatur) ausgewertet werden. Allerdings besitzt nicht jede Datei einen Header, beispielsweise haben einfache Textdateien, meist (aber nicht immer) mit der Erweiterung .txt
, keine verpflichtende besondere Kennzeichnung, denn bei 8-Bit-ASCII-Dateien beginnt der Inhalt direkt mit dem ersten Textzeichen (Textdateien mit Multibyte-Zeichensatz besitzen allerdings häufig eine Byte Order Mark). Auf einer Unix-Kommandozeile kann mittels file
der Typ einer Datei ermittelt werden.
Besonderheiten
Auf IBM-Großrechnern dient die Dateiendung (hier auch Low Level Qualifier genannt) lediglich dazu, bei der Allokation die richtigen SMS-Konstrukte zuzuordnen (Data Class, Management Class, Storage Class). Ferner speichert der ISPF-Editor seine Profile pro Dateiendung. Das Datenformat selbst ist im VTOC beziehungsweise im VSAM-Katalog oder im Tape Header gespeichert.
Unter Unix und unixartigen Betriebssystemen werden versteckte Dateien mit einem beginnenden Punkt gekennzeichnet, die daher auch als „Punkt-Dateien“ bezeichnet werden. Dieser einleitende Punkt zeigt in keinem Fall eine Dateinamenserweiterung an. So wäre beispielsweise .txt
keine Textdatei, sondern der versteckte Dateiname der Datei txt
, ohne eine Erweiterung.
Im WWW, wo Dateien über das Hypertext Transfer Protocol übertragen werden, ist nicht die Dateiendung, sondern der mitgesendete MIME-Typ von Belang, der aber wiederum in der Regel aus der Endung ermittelt wird. Bei eingebundenen Bildern bestimmen die meisten Browser den Typ auf Basis der Magischen Zahl.
Da moderne Dateisysteme lange Dateinamen unterstützen, kann mehr als ein Punkt im Dateinamen vorkommen. Die Dateinamenserweiterung selbst enthält jedoch normalerweise keinen weiteren Punkt, obwohl Zusätze wie .bak
(für englisch Backup, Datensicherung) die davor stehende ursprüngliche Erweiterung nicht ungültig machen. So kennzeichnen etwa manche Texteditoren eine Sicherungskopie von Textdatei.txt
beispielsweise als Textdatei.txt.bak
. Es gibt jedoch keine Norm, üblich ist u. a. auch Textdatei.bak
(womit der ursprüngliche Dateityp als Erweiterung nicht mehr ersichtlich ist) oder Textdatei.txt~
. Auch bei Packprogrammen ist es üblich, die ursprüngliche Dateinamenserweiterung zu erhalten, wenn diese nur einzelne Dateien komprimieren (können). Beispiele dafür finden sich traditionell vor allem im Unix-Umfeld, etwa bei der Komprimierung mit gzip oder xz. Diese speichern den ursprünglichen Dateinamen nicht im Archiv selbst, sodass der Dateiname diese Information weiterhin beinhalten muss. Beispielsweise bedeutet Textdatei.txt.xz
, dass es sich um die mit xz komprimierte Datei Textdatei.txt
handelt. In Kombination mir Tar-Archiven können einerseits mehr als eine Datei komprimiert werden, andererseits sind die ursprünglichen Dateinamen im Tar-Archiv gespeichert. Die unter Unix genutzten zusammengesetzten Dateiendungen, z. B. .tar.gz
für ein mit gzip komprimiertes Tar-Archiv, wurden in der Vergangenheit dennoch oft zu .tgz
abgekürzt, um zu DOS und Windows kompatible Dateinamen zu erhalten (8.3-Beschränkung). Auf Systemen mit langen Dateinamen sind zudem Punkte im Dateinamen selbst erlaubt, die nicht zur Erweiterung zählen, etwa Eine.Archivdatei.mit.vielen.Punkten.im.Namen.tar.xz
.
Unter macOS (bzw. seit NeXTStep, von dem macOS abstammt) dienen Verzeichnisse (unter macOS „Ordner“) mit der Endung .app
(auch .bundle
, .framework
, .plugin
und .kext
[1]) als Container für Anwendungsprogramme. Diese Application Bundles werden im Finder als „Applikation“ angezeigt, nicht als Verzeichnis, und beinhalten neben dem eigentlichen Programm alle notwendigen Ressourcen, wie etwa Icons u.d.gl. Über den Kontextmenü-Eintrag „Paketinhalt anzeigen“ kann im Finder dennoch in das Unterverzeichnis navigiert werden.
Gefahren
Auf Windows-Systemen ist voreingestellt, dass der Windows-Explorer alle dem System bekannten Dateiendungen ausblendet. Dieser Umstand wird von diversen Schadprogrammen ausgenutzt: Vor die Endung einer ausführbaren Datei wird eine harmlose Endung eingefügt. So wird z. B. aus dem trojanischen Pferd namens Bild01.exe
ein Bild01.jpeg.exe
. Der Benutzer sieht nur Bild01.jpeg
, also eine vermeintlich harmlose Bilddatei. Ein Doppelklick startet jedoch die schädliche Software. Durch Deaktivierung des standardmäßigen Ausblendens der bekannten Endungen fällt eine solche versuchte Verschleierung auf. Das mit dem standardmäßigen Ausblenden der Dateiendungen verursachte Sicherheitsrisiko wird von Microsoft bewusst in Kauf genommen. Das Aus- bzw. Einblenden der Endungen kann auch das Verhalten von VBA-Scripts beeinträchtigen.[2]
Weblinks
Einzelnachweise
- Bundle Programming Guide – About Bundles. In: Documentation Archive. Apple, Inc., abgerufen am 19. Oktober 2019 (englisch).
- Pearson Software Consulting: File Extensions And Their Implications In VBA Coding. (englisch)