nicht angemeldet
Hallo Struppi,
Was mich da mal interssiert, benutzen MacOs Rechner diese Endungen? Ich dachte immer dort gibt es keine Dateiendungen.
Jain. Früher war „keine Dateiendungen“ Standard, inzwischen haben sie sich leider durchgesetzt, aber sie sind immer noch eine doofe Variante, Dateitypen zu identifizieren, deswegen hat Apple eine weitere, neuere Variante der Dateityp-Identifikation in der Hinterhand.
Ich fang mal mit früher an, das ist hier Mac OS ≤ 9. Wie eventuell bekannt haben die dort verwendeten Dateisysteme (HFS, HFS+) die Möglichkeit neben den reinen Inhaltsdaten der Dateien auch Metadaten zu speichern, die über Dateiname und den Zeitpunkten des Erstellens und der letzten Änderung hinaus gehen. Ein Beispiel ist der Resource Fork, wo zusätzliche Informationen zu den Daten gespeichert werden, bei Programmen z.B. Icons. Der Resource Fork (im Gegensatz zum Data Fork) ist eh eine Mini-Wissenschaft für sich, am besten man stellt es sich als eine zusätzliche Datenstruktur vor. Andere Metadaten, die von Dateisystem zu einer Datei gespeichert sind sind Type und Creator Code, und da wird es in Sachen Dateityp spannend.
Type Code und Creator Code sind zwei Datenfelder, die jeweils vier Bytes halten. Apple hatte oder hat noch eine allgemeine Registrierung für diese Vier-Byte-Codes, wo man sich Drittfirmen registrieren kann. Sprich: Ein Vier-Byte-Code identifizierte immer etwas und nur das. Der Type Code ist für den Dateityp gedacht, z.B. TEXT für Textdateien, APPL für Programme, etc. Der Creator Code dagegen zeigt an, welches Programm diese Datei öffnen soll, wird darauf geklickt. Sprich: Es kann Textdateien geben, die mit Programm 1 als Default geöffnet werden und gleichzeitig Textdateien, die mit Programm 2 als Default geöffnet werden. Type Codes erzählen, welcher Typ die Datei ist, ob sich ein Programm dafür interessieren soll, Creator Codes erzählen, welches genaue Programm die Datei öffnen soll; Dateityp und Default-Programm sind also entkoppelt.
Das war damals durchaus ein nettes Konzept. Und ganz in den Anfängen des Mac-Zeitalters hat das auch niemanden weh getan. Aber in Zeiten in der Interoperabilität ist das doof. Weil all die anderen gebräuchlichen Dateisysteme da draussen (CD-ROM, etc) und im Internet (HTTP, FTP, E-Mail) es nicht das Konzept der Datei bestehend aus Daten und vielen Metadaten gibt, wie im Mac OS Dateisystem. Da besteht eine Datei nur aus Dateiname und Inhalt, zugegeben noch bei HTTP und E-Mail aus der zusätzlichen Datei-Typ-Identifizierungs-Variante MIME-Typ. Zip- und sonstige gepackten Archive. Es gibt zwar Ansätze für Metadaten bewahrende Archivformate auch für bestehende Formate wie Zip, aber das läuft immer auf doofe Hacks hinaus. Undsoweiter. Also schlichen sich Dateiendungen doch noch in Mac OS rein.
Mit Mac OS X wurden die dann wichtiger, Type und Creator Code wurden kaum noch beachtet, die Dateiendung ist leider nun mal der entscheidene Part geworden, den Dateityp zu identifizieren. Sprich: Ja, unter Mac OS X gibt es Dateiendungen und sie werden auch benutzt. Wobei das übliche bei benutzerfreundlichen Betriebssystemen gilt, im Default werden die Endungen ausgeblendet, es wird gewarnt, wenn man einfach so die Endung ändert, etc.
Unter Mac OS X machen sich viele Programme auch nicht mehr die Mühe, Type und Creator Code zu setzen:
tim $ /Developer/Tools/GetFileInfo bla.png
file: "/Users/tim/bla.png"
type: ""
creator: ""
attributes: avbstClinmedz
created: 10/27/2006 20:51:37
modified: 10/27/2006 20:58:36
Allerdings winkt ein neues System der Dateityp-Identifizierung am Horizont bzw. ist schon wirksam, der Identifizierung durch UTIs (Universal Type Identifier). UTIs sind erstmal nur ein String, was unterscheidet sie also von Vier-Byte-Codes, Datei-Endungen und MIME-Typen? Zum einen die Länge, was durchaus praktisch ist angesichts der Drei-Buchstaben-Konvention bei DOS-Dateiendungen und dass Dateinamen nicht ewig kang werden. Dann die Nutzbarkeit durch jeden, „im Prinzip“ gibt es keine zentrale Registrierung dafür. Und die Vererbbarkeit, spezielle Typen können von allgemeineren Typen erben. Ein UTI sieht zum Beispiel so aus:
org.tepasse.bla.blubb
Man beachte: Beim privaten Erstellen von UTIs nutzt man Reverse DNS, sprich für die Bezeichnung von Namensräumen hat man ein System, das wirkt, Verwechselungen vermeidet und vermutlich noch lange Zeit bei uns bleiben wird. Finde ich geschickter als die x-Konvention bei MIME-Typen. Mein hypothetisches Programm „bla“, dass ein Dateityp „blubb“ definiert könnte dann auch zusätzlich noch ankündigen, dass dieser Dateityp von den allgemeinen Dateityp public.plain-text erbt, also aus einer speziellen Form von reiner Text erbt. So dass alle Programme, die Plain Text öffnen können, auch erkennen, dass sie Dateien vom Typ org.tepasse.bla.blubb öffnen können, auch wenn ihnen dann die Feinheiten des speziellen Formats entgehen. Ähnlich wie die image/* bei MIME Media Typen. Die Definition von public.* unterliegt der Domäne von Apple.
Die UTIs werden wiederrum als spezielles Attribut einer Datei im HFS+-Dateisystem gespeichert, sind also wiederum nicht portabel. Wie auch, wenn das Standardmodell einer Datei ausserhalb spezieller Dateissysteme nur aus Datenstrom und als einzigen Metadaten Dateinamen (plus Dateiendung besteht)? Aber intern kann man es gut für alle möglichen Zwecke nutzen. Für eindeutige Identifizierung des Dateiformates, Spotlight, der Mac OS X Suchservice speichert das auch noch mal zusätzlich in seinen Indizes:
tim $ mdls bla.png
bla.png -------------
kMDItemAttributeChangeDate = 2006-10-27 20:58:38 +0200
kMDItemBitsPerSample = 40
kMDItemColorSpace = "RGB"
kMDItemContentCreationDate = 2006-10-27 20:51:37 +0200
kMDItemContentModificationDate = 2006-10-27 20:58:36 +0200
kMDItemContentType = "public.png"
kMDItemContentTypeTree = ("public.png", "public.image", "public.data",
"public.item", "public.content")
kMDItemDisplayName = "bla.png"
... abgeschnitten
Man beachte den Content-Type-Tree, der die Vererbung von UTIs schildert.
Was hat man nun davon? Man hat intern eine Möglichkeit, Datenformate eindeutig zu identifizieren und diese durch die UTI-Hierarchie abzuleiten. Im wesentlichen ist das dasselbe wie die Creator Codes früher, nur in etwas technisch ausgereifter. Das Zauberwort lautet „intern“, für die Zwecke der Interoperabilität mit weniger reichen Dateisystemen oder Dateiübertragungsformate verzichtet man immer noch darauf, dort muss man weiter noch mit Dateiendungen und/oder MIME-Typen hantieren. Konsequenterweise wird die UTI auch aus solchen Informationen gewonnnen, im Prinzip existieren unter Mac OS X zum Mittel der Identifikation Dateiendungen in ihren Varianten (*.jpg, *.jpeg), MIME-Typen und als Altlast die Type Codes. Allerdings: UTIs sind die letztendliche interne Authorität. Ich meine mich zu erinnern, dass diverse Linux Desktop Umgebungen ähnliches mit MIME-Typen machen.
Im Prinzip bräuchte man keine Dateiendungen. In der Praxis bleiben die aber trotzdem noch, wegen Interoperabilität und weil auch noch nicht alles wirklich so toll UTI-fiziert ist. Die LaunchServices (Verantwortlich für das Öffnen von Dateien) bevorzugen meiner Erfahrung nach wohl mehr die Dateiendung denn den UTI. Allerdings sind UTIs erst mit Mac OS X 10.3 eingeführt und mit Mac OS X 10.4 richtig popularisiert worden; ich rechne also noch mit Verbesserung in Mac OS X 10.5.
Und weil die Welt sich nie auf einen minimalen Konsens in Sachen Dateien einigen konnte, der über Daten und Name hinausgeht, bleibt es immer nur auf die schöne kleine Mac-Welt begrenzt. Wie immer schon. ;)
Tim
Struppi