Skip to content
Back to Blog
informational

Wie Computer Dateitypen erkennen: Magic Bytes erklärt

2026-05-17 9 min read

Warum Dateiendungen nur die halbe Miete sind

Die meisten Leute nehmen an, ein Computer wisse, dass eine Datei ein JPEG ist, weil sie auf .jpg endet. Das ist eine vernünftige Annahme, aber sie ist in etwa der Hälfte der Fälle falsch. Dateiendungen sind nur eine Namenskonvention. Sie sind ein Hinweis für das Betriebssystem, aber keine Garantie für den Inhalt. Benenne eine PNG-Datei in .txt um, und Windows wird fröhlich versuchen, sie im Editor zu öffnen und dir einen Bildschirm voller Kauderwelsch anzeigen. Versuchst du, ein Word-Dokument, das du in .pdf umbenannt hast, zu öffnen, wird Adobe Acrobat dies rundweg ablehnen. Für die Dateikonvertierung ist das enorm wichtig. Wenn du eine Datei bei einem Dienst wie CocoConvert hochlädst, kann das System nicht einfach der Dateiendung vertrauen. Jemand könnte eine schädliche ausführbare Datei (.exe) in .jpg umbenennen, um sie an einem naiven Dateihandler vorbeizuschleusen. Oder, was häufiger vorkommt, ein Benutzer speichert eine Datei versehentlich mit der falschen Endung. Wir alle haben schon beschädigte Downloads gesehen, bei denen die Metadaten der Endung komplett verloren gegangen sind. Die Lösung, auf die man sich vor Jahrzehnten geeinigt hat, besteht darin, den Dateinamen zu ignorieren und den tatsächlichen binären Inhalt der Datei zu lesen. Genauer gesagt liest ein Programm die ersten paar Bytes und vergleicht sie mit einer bekannten Datenbank von Signaturen. Diese Signaturen werden Magic Bytes oder, formeller, Dateisignaturen genannt. Sie sind die absolute Wahrheit über den Inhalt einer Datei, unabhängig von ihrem Namen.

Was Magic Bytes eigentlich sind

Jedes standardisierte Dateiformat reserviert seine ersten paar Bytes für eine eindeutige Kennung. Diese Bytes, in hexadezimaler Schreibweise, sind in der Spezifikation des Formats selbst verankert – sie werden nicht später vom Betriebssystem hinzugefügt. Du kannst sie dir mit einem Hex-Editor selbst ansehen. Schau dir ein paar gängige Dateitypen an: - **JPEG-Bilder** beginnen immer mit FF D8 FF. Die ersten beiden Bytes (FF D8) markieren den Anfang des Datenstroms, und das dritte (FF) leitet das erste Marker-Segment ein. - **PNG-Bilder** beginnen mit einer 8-Byte-Signatur: 89 50 4E 47 0D 0A 1A 0A. Beachte, dass der Teil 50 4E 47 ASCII für 'PNG' ist. - **PDF-Dateien** beginnen mit 25 50 44 46, was ASCII für '%PDF' ist. Du kannst jedes PDF in einem einfachen Texteditor öffnen und dies ganz oben sehen. - **ZIP-Archive** beginnen mit 50 4B 03 04. Das ist 'PK' in ASCII, für Phil Katz, den Erfinder des Formats. Da DOCX-, XLSX-, PPTX- und JAR-Dateien alle auf ZIP basieren, teilen sie sich diese Signatur. - **MP3-Audiodateien** beginnen oft mit FF FB oder FF F3, dem MPEG-Synchronisationswort. - **EXE-Dateien** unter Windows beginnen mit 4D 5A – 'MZ' in ASCII, für Mark Zbikowski, einen der ursprünglichen Architekten von MS-DOS. Der Name 'Magic Bytes' stammt vom Unix-Tool `file`, das seit den 1970er Jahren eine Datenbank namens `/etc/magic` (oder `/usr/share/misc/magic` auf modernen Systemen) verwendet. Wenn du `file photo.jpg` in einem Terminal ausführst, liest das Tool die ersten Bytes, konsultiert seine Datenbank und teilt dir den echten Dateityp mit, wobei es die .jpg-Endung komplett ignoriert.

Wie Erkennungssoftware die Signatur liest

Im Prinzip ist das Lesen von Magic Bytes einfach. In der Praxis machen einem aber die Sonderfälle einen Strich durch die Rechnung. Der grundlegende Prozess besteht darin, die Datei als rohen Binärstrom zu öffnen, einen kleinen Puffer zu lesen – oft die ersten 512 Bytes – und diesen Puffer mit einer Liste bekannter Signaturen zu vergleichen. Einige Formate erfordern jedoch, dass man viel weiter liest. Der Vergleich ist nicht immer ein einfacher Präfix-Abgleich. Einige Formate platzieren ihre Signatur an einem festen Offset. Das ISO-Disk-Image-Format hat beispielsweise seine 'CD001'-Signatur ab Byte 32.769. Bei ZIP-Dateien kann sich das zentrale Verzeichnis am Ende der Datei befinden, was einige Detektoren zwingt, vom Ende statt vom Anfang der Datei aus zu scannen. Moderne Bibliotheken wie Apache Tika (Java), python-magic (Python) und libmagic (C) bewältigen diese Komplexität. Allein Apache Tika kennt über 1.300 Dateitypen und erkennt MIME-Typen, Zeichenkodierungen und sogar eingebettete Metadaten. Bei CocoConvert verwenden wir die serverseitige Signaturerkennung als unsere erste Verteidigungslinie. Wenn der von deinem Browser deklarierte MIME-Typ nicht mit dem übereinstimmt, was die binäre Signatur aussagt, wird die Datei für eine genauere Prüfung markiert, bevor eine Konvertierung beginnt. Containerformate machen die Sache noch kniffliger. Eine DOCX-Datei und eine JAR-Datei beginnen beide mit 50 4B 03 04, weil sie beide ZIP-Archive sind. Um sie zu unterscheiden, muss die Software tiefer im Archiv nach bestimmten Dateien suchen, wie [Content_Types].xml für DOCX oder META-INF/MANIFEST.MF für eine JAR-Datei. Diese zweistufige Erkennung ist Standard für jede ernstzunehmende Pipeline zur Dateiverarbeitung.

Wann Magic Bytes versagen (und das tun sie)

Magic Bytes sind zuverlässig, aber nicht unfehlbar. Mehrere reale Szenarien können die signaturbasierte Erkennung austricksen und dir falsche oder mehrdeutige Antworten geben. **Unvollständige Dateien** sind ein ständiges Ärgernis. Wenn ein Download unterbrochen wird, hast du möglicherweise eine Datei mit einem gültigen JPEG-Header, aber ohne tatsächliche Bilddaten. Die Signaturprüfung ist erfolgreich, aber die Konvertierung schlägt später fehl, wenn der Decoder ein vollständiges Bild erwartet und nur ein Fragment findet. **Absichtlich manipulierte Dateien** können die Tatsache ausnutzen, dass Magic Bytes nur den Header abdecken. Eine Datei kann einen gültigen PNG-Header haben, gefolgt von einer schädlichen Nutzlast. Dies ist ein bekannter Angriffsvektor, der als Polyglot-Datei bezeichnet wird – eine einzelne Binärdatei, die gleichzeitig als zwei verschiedene Dateitypen gültig ist. Forscher haben JPEG/JavaScript-Polyglots erstellt, die ein Browser als Skript ausführt, während ein Bildbetrachter sie als Foto anzeigt. Die reine Signaturerkennung wird diese nicht fangen. **Konflikte zwischen Formatversionen** schaffen eine weitere Ebene der Mehrdeutigkeit. Vor 2007 verwendeten Microsoft Office-Dateien (DOC, XLS, PPT) das Compound Document Binary Format, das mit D0 CF 11 E0 A1 B1 1A E1 beginnt. Alle drei Formate haben exakt dieselbe Signatur. Du kannst ein .doc nicht von einem .xls oder .ppt anhand der Magic Bytes unterscheiden; du musst die interne Struktur analysieren. **Reine Textformate** wie CSV, JSON, XML, HTML und Markdown haben überhaupt keine Magic Bytes. Sie sind nur Zeichensequenzen. Die Erkennung beruht hier auf heuristischer Analyse: der Suche nach Mustern wie spitzen Klammern (HTML/XML) oder geschweiften Klammern (JSON). Diese Heuristiken können falsch sein. Jeder, der sich schon einmal mit einer 'CSV'-Datei herumgeschlagen hat, die Semikolons statt Kommas verwendet, kennt diesen Schmerz nur zu gut. Wenn CocoConvert einen Dateityp nicht sicher identifizieren kann, teilen wir dir das mit. Wir sind der Meinung, dass eine klare Fehlermeldung weitaus nützlicher ist, als zu raten und eine beschädigte Datei zu erzeugen.

Praktische Auswirkungen auf die Dateikonvertierung

Wie hilft dir das also? Es verändert die Art und Weise, wie du Fehler bei fehlgeschlagenen Konvertierungen behebst, komplett. Wenn ein Dienst ein 'nicht unterstütztes oder unbekanntes Dateiformat' meldet, ist das Problem fast nie die Dateiendung. Es ist der Inhalt. Hier sind die häufigsten Übeltäter und was du dagegen tun kannst: **Die Datei hat ein anderes Format, als du denkst.** Das passiert oft bei Exporten aus Design-Tools. Figma könnte zum Beispiel eine Datei mit der Endung .jpg exportieren, die eigentlich ein PNG ist. Am besten öffnest du die Datei in einem Hex-Editor (wie HxD unter Windows oder Hex Fiend unter macOS) und überprüfst die ersten Bytes. Wenn du 89 50 4E 47 siehst, ist es ein PNG, unabhängig vom Namen. Benenne es um und versuche es erneut. **Die Datei ist passwortgeschützt oder DRM-gesperrt.** Verschlüsselte Office-Dokumente beginnen immer noch mit D0 CF 11 E0, also ist die Signaturprüfung erfolgreich. Aber der Inhalt ist Chiffretext. CocoConvert kann passwortgeschützte Dateien nicht entschlüsseln. Halte das nicht für eine Einschränkung des Dienstes; es ist ein grundlegendes Sicherheitsmerkmal der Verschlüsselung selbst. **Die Datei ist ein Container mit dem falschen Inhalt.** Eine Datei, die durch Umbenennen einer generischen .zip in .docx erstellt wurde, hat die richtige Signatur (50 4B), wird aber bei der Konvertierung fehlschlagen, da ihr die erforderliche Word-Verarbeitungs-XML-Struktur fehlt. Der Konverter öffnet das Archiv, findet nichts, womit er arbeiten kann, und gibt auf. **Codec-Inkompatibilitäten in Videodateien.** Ein MKV-Container (beginnt mit 1A 45 DF A3) kann Video enthalten, das in H.264, H.265, AV1, VP9 oder Dutzenden anderen Codecs kodiert ist. Magic Bytes bestätigen den MKV-Container, nicht den Codec des Videostroms. Wenn CocoConvert MKV unterstützt, deine Datei aber einen obskuren Codec wie RealVideo 4 verwendet, wird die anfängliche Erkennung erfolgreich sein, aber der Transkodierungsschritt wird fehlschlagen.

So überprüfst du den wahren Dateityp ohne Spezialsoftware

Du musst keine spezielle Software installieren, um die wahre Identität einer Datei zu überprüfen. Diese Methoden funktionieren auf jedem gängigen Betriebssystem mit Tools, die du bereits hast. **Unter Windows:** Öffne PowerShell und führe `Format-Hex -Path 'C:\path\to\yourfile.ext' | Select-Object -First 3` aus. Dieser Befehl gibt die ersten 48 Bytes in hexadezimaler Form aus. Vergleiche die erste Zeile der Bytes mit den Signaturen, die weiter oben in diesem Artikel aufgeführt sind. **Unter macOS und Linux:** Öffne das Terminal und führe `xxd yourfile | head -3` aus. Dies zeigt den Byte-Offset, die Hex-Werte und die ASCII-Darstellung. Noch besser: Führe einfach `file yourfile` aus. Das `file`-Tool ist integriert und gibt dir sofort eine saubere, menschenlesbare Antwort. **Im Browser, ganz ohne Tools:** Wenn du an einem gesperrten Rechner sitzt, auf dem du keine Befehle ausführen kannst, gehe zur Erkennungsseite von CocoConvert unter cocoConvert.com/detect. Lade die Datei hoch, und unser Dienst meldet den erkannten MIME-Typ, die übereinstimmenden Signatur-Bytes und sein Konfidenzniveau. **In Python (für Entwickler):** Nach `pip install python-magic` kannst du `import magic; print(magic.from_file('yourfile', mime=True))` ausführen. Dies gibt einen Standard-MIME-Typ wie `image/jpeg` zurück. Mein Rat für produktiven Python-Code ist jedoch, stattdessen die `filetype`-Bibliothek zu verwenden. Sie hat keine Systemabhängigkeiten, was die Bereitstellung unter Windows erheblich erleichtert, ohne sich mit libmagic-DLLs herumschlagen zu müssen. Den wahren MIME-Typ vor dem Hochladen zu kennen, spart eine Menge Zeit. Wenn der erkannte Typ einer Datei nicht auf der Liste der unterstützten Eingabeformate eines Dienstes steht, weißt du sofort, dass die Konvertierung fehlschlagen wird.

Was Konvertierungsdienste versprechen können – und was nicht

Die Erkennung von Magic Bytes ist ein gelöstes Problem für die rund 200 Dateiformate, die 99 % des täglichen Bedarfs abdecken. Aber für den Long Tail der spezialisierten, proprietären oder veralteten Formate kann kein Dienst – auch CocoConvert nicht – eine vollständige Abdeckung versprechen. Formate wie Autodesk DWG für CAD-Zeichnungen, proprietäre medizinische Bildgebungsvarianten von bestimmten Scannermarken oder Nischen-Audioformate von alten Synthesizern haben oft keine oder nur eine schlechte offene Dokumentation. Selbst wenn die Magic Bytes bekannt sind, kann die interne Struktur eine Blackbox sein. Ein Konverter könnte eine Ausgabe mit fehlenden Daten, falschen Farben oder verlorenen Metadatenebenen erzeugen. Zum Zeitpunkt der Erstellung dieses Textes unterstützt CocoConvert etwa 300 Eingabeformate. Obwohl das nach viel klingt, dokumentiert das PRONOM-Register der Library of Congress über 2.000 verschiedene Dateiformate. Diese Lücke repräsentiert Formate, die zu obskur sind, um den Entwicklungsaufwand zu rechtfertigen, die rechtlich durch Patente belastet sind oder so schlecht dokumentiert sind, dass jeder Konvertierungsversuch ein Glücksspiel wäre. Meine Empfehlung lautet: Wenn du in Branchen wie medizinischer Bildgebung, Geodaten oder professionellem Video arbeitest, musst du die Formatunterstützung überprüfen, bevor du dich auf einen Konvertierungs-Workflow festlegst. Überprüfe die Seite zur Formatunterstützung von CocoConvert. Dort sind alle unterstützten Ein- und Ausgabeformate aufgelistet, zusammen mit Hinweisen zu bekannten Einschränkungen. Es ist besser, zuerst nachzusehen, als eine 4 GB große Broadcast-Masterdatei hochzuladen, nur um festzustellen, dass ihre spezifische MXF-Variante nicht unterstützt wird. Magic Bytes sagen einem Computer, was eine Datei *ist*. Sie sagen ihm aber nicht, ob die Konvertierung dieser Datei etwas *Nützliches* hervorbringt. Diese zweite, wichtigere Frage hängt von guter Dokumentation, klarer Lizenzierung und engagierter Entwicklungsarbeit ab, die durch noch so cleveres Byte-Sniffing nicht ersetzt werden kann.