29. Oktober 2003, Letzte Änderung: 24. August 2009

Binär- oder Textformat

Die meisten W3C-Spezifikationen definieren eine formale Sprache zur Beschreibung einer Art von Ressource: HTML beschreibt einfache Text-Dokumente, SVG beschreibt Vektorgrafiken, PNG beschreibt Rastergrafiken, HTTP beschreibt den Dialog zwischen einem Client und einem Server und URLs beschreiben den Pfad zu einer bestimmten Ressource. Es gibt Ausnahmen wie die verschiedenen WAI-Richtlinien, die Meta-Regeln beschreiben, wie Programme und Spezifikationen entworfen werden sollten (ein wenig wie dieser Essay, allerdings präziser...). Aber die meisten Menschen, die an W3C-Spezifikationen arbeiten, stehen am Anfang vor der Frage: Sollen wir ein Binär- oder ein Textformat entwerfen?

In den meisten Fällen wird die Antwort »Textformat« lauten, denn Textformate sind einfacher zu laden, und Fehler lassen sich leichter finden und beseitigen: man kann Dateien mit einem Texteditor erzeugen, sodass der Entwurf eines geeigneten Editors oder Konverters auf einen späteren Zeitpunkt verschoben werden kann; man kann eine Datei überprüfen, um zu sehen, was passiert ist, wenn ein Programm nicht das macht, was man erwartet hat; und nicht zuletzt: wenn die Spezifikation in etwa 50 Jahren versehentlich verloren gegangen ist, gibt es eine Chance, allein durch das Analysieren einiger Dateien ausreichend viel von der Spezifikation zu rekonstruieren, um die essentiellen Informationen zurückzugewinnen. (Das wird manchmal, wohl eher optimistisch, »selbstbeschreibend« genannt. Das Format würde nur dann wirklich selbstbeschreibend sein, wenn jede Datei den Text der Spezifikation mit einbände...)

Textformate erlauben oftmals, unvorhergesehene Erweiterungen vorzunehmen, denn sie haben typischerweise ziemlich hohe Redundanz. Viele Programmiersprachen haben daher Konventionen erlangt, um Dinge in strukturierte Kommentare zu packen oder haben in späteren Versionen neue Schlagwörter erhalten. Ebenso haben Binärformate normalerweise einige eingebaute Erweiterungsmechanismen, aber sie sind beschränkter (zum Beispiel die Extension Chunks bei GIF und PNG).

Aber vielleicht entscheidet man sich für Textformate, einfach weil das IETF sie befürwortet, oder weil jemand aus dem Management HTML verlangt...

Eigentlich sind Binärformate nicht böse. Sie sind oftmals wesentlich effizienter zu verarbeiten und zu transportieren. Sie sind für gewöhnlich kleiner: Das Ziel von ZIP, MPEG und JPEG – um nur ein paar zu nennen – ist, so wenig Bits zu umfassen wie möglich. Sie sind normalerweise schneller zu verarbeiten, weil sie einfachere Parser erfordern.

Parser für eine wohlgestaltete, textbasierte Sprache müssen nicht uneffizient sein, wenngleich Konverter von Text- zu Binärformat sie typischerweise um einen bestimmten Faktor langsamer machen. Ein wichtigerer Punkt ist, dass ihre größere Komplexität oftmals zu weiteren Fehlern führt.

Und ist der Mangel an Erweiterung von Binärformaten so schlecht? Möglicherweise nicht. Selbst wenn ein Textformat theoretisch erweiterbar ist, muss das in der Praxis nicht der Fall sein. Wenn die Erweiterung nicht auf eine sinnvolle Art und Weise rückwärtskompatibel ist, ist es besser, ein komplett neues Format zu entwickeln. HTML wurde durch drei Versionen erweitert: 2.0, 3.2 und 4.0, aber es kann nicht weiterentwickelt werden, ohne dass es zu ernsthaften Problemen für Implementierer führt. XHTML ist der Nachfolger von HTML, aber es ist ein neues Format, keine Erweiterung.

Zusammenfassend gesagt: Die meisten W3C-Formate sind Textformate, und das wird wahrscheinlich so bleiben, aber gehen Sie nicht davon aus, dass Binärformate verboten wären. Beide Formate bringen Nachteile mit sich, die gegeneinander abgewogen werden müssen.