MIME-Typen Referenz

MIME-Typen (Multipurpose Internet Mail Extensions) sind ein Standard zur Kennzeichnung der Art und Format von Dokumenten, Dateien oder Byte-Streams. Browser und Server verwenden MIME-Typen um zu bestimmen, wie Inhalte behandelt werden. Beispiel: image/jpeg signalisiert dem Browser ein Bild anzuzeigen, application/pdf könnte eine PDF-Vorschau öffnen. MIME-Typen beschreiben, welche Art von Inhalt eine Datei oder HTTP-Antwort enthält, etwa text/html, application/json, image/png oder application/pdf. Sie beeinflussen Browserdarstellung, Downloads, API-Verarbeitung, Upload-Validierung, Caching und Sicherheitsregeln. Dateiendung und MIME-Typ stimmen nicht immer überein, deshalb ist die Prüfung bei unbekannten Dateien oder Serverkonfigurationen wichtig. Für Sicherheit sollte man MIME-Typen nicht blind vertrauen, sondern Inhalt, Erweiterung und erlaubte Typen gemeinsam validieren.

MIME-Typen (Multipurpose Internet Mail Extensions) sind standardisierte Bezeichner für Datenformate, die ursprünglich in RFC 2045/RFC 2046 für E-Mail-Anhänge definiert wurden und später von HTTP (RFC 7231 §3.1.1.5) für die Inhaltsaushandlung im Web übernommen wurden. Ein MIME-Typ ist als Typ/Untertyp aufgebaut – der Typ gibt die grobe Kategorie an (text, image, audio, video, application, multipart, font, model), der Untertyp das genaue Format (z. B. text/html, image/png, application/json). Optionale Parameter folgen nach einem Semikolon (text/html; charset=utf-8). Die Internet Assigned Numbers Authority (IANA) pflegt das offizielle MIME-Typ-Register unter iana.org/assignments/media-types. Die Registrierung folgt RFC 6838, der ein Prüfverfahren definiert, das eine Spezifikation, Sicherheitsüberlegungen und Interoperabilitätshinweise erfordert. Nicht registrierte Typen können das x- Präfix verwenden (z. B. application/x-tar) als Konvention für experimentelle oder herstellerspezifische Formate, wobei RFC 6648 empfiehlt, das x- Präfix zugunsten einer ordentlichen Registrierung zu vermeiden. In HTTP teilt der Content-Type-Header dem Client mit, wie der Antwortkörper zu interpretieren ist. Ein Server, der Content-Type: image/svg+xml zurückgibt, löst den SVG-Renderer des Browsers aus; Content-Type: application/octet-stream löst eine Download-Aufforderung aus, da der Browser das Format nicht bestimmen kann. Der Browser nutzt MIME-Typ-Informationen auch für das MIME Sniffing – wenn ein Server den Content-Type weglassen oder einen generischen Typ sendet, kann der Browser die ersten Bytes der Antwort (Magic Bytes) prüfen, um das tatsächliche Format zu erraten. Dieses Verhalten wird durch den Header X-Content-Type-Options: nosniff gesteuert, der das Sniffing deaktiviert und vom Server die korrekte Typ-Angabe verlangt. Bei Datei-Uploads teilt der Accept-Header dem Server mit, welche MIME-Typen der Client als Antwort erwartet, während das accept-Attribut des input-Elements die Dateiauswahl auf bestimmte Typen beschränkt (z. B. accept="image/png, image/jpeg"). Auf Serverseite sollten hochgeladene Dateien sowohl anhand ihres angegebenen MIME-Typs als auch anhand ihrer Dateisignatur (Magic Bytes) validiert werden, da keines allein vertrauenswürdig ist – eine als image/png benannte Datei mit Content-Type: image/png kann ausführbaren Code enthalten. Das Tool dient als Referenz zum Nachschlagen des kanonischen MIME-Typs für eine gegebene Dateierweiterung und deckt über 100 gängige Formate in acht Kategorien ab.

• RFC-2046-Struktur: Typ/Untertyp – der Typ gibt die grobe Inhaltskategorie an, der Untertyp das genaue Format; optionale Parameter folgen nach einem Semikolon (text/html; charset=utf-8) und sind laut Spezifikation schreibungsunabhängig, wobei Kleinschreibung die Konvention ist.
• IANA-Registrierung (RFC 6838): Neue Medientypen erfordern eine Spezifikation, einen Abschnitt zu Sicherheitsüberlegungen und Interoperabilitätshinweise – das Prüfverfahren stellt sicher, dass die Typen gut dokumentiert sind und Konflikte vermieden werden, bevor sie ins Register aufgenommen werden.
• HTTP Content-Type-Header: Der Server erklärt den MIME-Typ des Antwortkörpers; Browser verwenden ihn, um den passenden Renderer auszuwählen (HTML-Parser, Bilddecoder, PDF-Viewer) oder einen Download auszulösen – ein falscher Content-Type ist die häufigste Ursache dafür, dass Dateien heruntergeladen statt angezeigt werden.
• MIME Sniffing und X-Content-Type-Options: Wenn der Content-Type fehlt oder generisch ist, können Browser Magic Bytes prüfen, um das Format zu erraten – X-Content-Type-Options: nosniff deaktiviert dieses Verhalten und verlangt eine exakte Content-Type-Übereinstimmung, was eine bewährte Sicherheitspraxis ist.
• application/octet-stream: Der generische Binär-Fallback-Typ – Browser behandeln ihn als undurchsichtigen Datenstrom und lösen einen Download aus, was ihn zur sichersten Vorgabe macht, wenn der Server das Format nicht bestimmen kann, aber eine Anzeige im Browser ansonsten darstellbarer Inhalte verhindert.
• Validierung bei Datei-Uploads: Das accept-Attribut des input-Elements filtert die Dateiauswahl clientseitig, aber die serverseitige Validierung muss sowohl den angegebenen Content-Type als auch die Magic Bytes der Datei prüfen – eine Abweichung zwischen Erweiterung, MIME-Typ und Dateisignatur ist ein Warnzeichen für bösartige Uploads.
• Hersteller- und experimentelle Typen: Die x-Präfix-Konvention (application/x-tar, video/x-matroska) ist älter als das formale Registrierungsverfahren – RFC 6648 empfiehlt, diese nach Möglichkeit in ordentlich bei der IANA registrierte Typen zu überführen, aber viele sind nach wie vor weit verbreitet.