Podręcznik typów MIME

Czym właściwie jest typ MIME

Typ MIME, zwany również typem mediów, to krótka etykieta informująca oprogramowanie o rodzaju danych zawartych w pliku lub treści wiadomości. Powstał w poczcie elektronicznej (skrót oznacza Multipurpose Internet Mail Extensions, czyli wielofunkcyjne rozszerzenia poczty internetowej), lecz dziś pojawia się wszędzie w sieci. Format jest zawsze następujący: typ/podtyp — szeroka kategoria, ukośnik i konkretny format. Tak więc text/html oznacza „tekst w formacie HTML", image/png — „obraz w formacie PNG", a application/json — „dane aplikacji zakodowane jako JSON".

Nadrzędny typ pochodzi ze stałego zestawu utrzymywanego przez IANA, oficjalny rejestr: text, image, audio, video, application, font, model, multipart oraz kilka nowszych, jak haptics. Podtyp określa konkretny format. Dostawcy mogą dodawać własne typy z prefiksem vnd. (np. application/vnd.ms-excel), a eksperymentalne typy historycznie stosowały prefiks x-, choć ta konwencja jest już odradzana.

Gdzie typy MIME mają znaczenie

Najważniejszym miejscem, w którym pojawia się typ MIME, jest nagłówek HTTP Content-Type w odpowiedzi serwera. Gdy serwer przesyła stronę, obraz lub ładunek API, nagłówek ten informuje przeglądarkę, jak interpretować bajty. Jeśli nagłówek mówi text/html, przeglądarka renderuje znaczniki; jeśli application/json, wywołanie fetch() może je sparsować; jeśli application/pdf, otwiera się wbudowana przeglądarka dokumentów. Ten sam nagłówek pojawia się także po stronie żądania: gdy wysyłasz formularz lub treść zapytania API metodą POST, Content-Type informuje serwer, jak odczytać to, co przesłałeś.

Poza HTTP typy MIME obsługują kilka innych systemów. Klienty poczty używają ich, by zdecydować, czy załącznik jest obrazem do podglądu, czy plikiem binarnym do zapisania. Procedury obsługi przesyłania plików sprawdzają zadeklarowany typ, aby akceptować lub odrzucać pliki. System operacyjny lub przeglądarka używa typu — nie tylko rozszerzenia pliku — do wyboru domyślnej aplikacji. Ta sama idea leży u podstaw tego, jak serwery raportują wyniki i błędy obok kodów statusu HTTP — odpowiedź 200 z nieprawidłowym typem może być równie problematyczna jak 404.

Typy, z których korzystasz na co dzień

Kilka typów obsługuje zdecydowaną większość ruchu sieciowego:

• text/html — strony internetowe (rozszerzenie .html)
• text/css — arkusze stylów (.css)
• text/javascript — zalecany typ dla JavaScript (.js, .mjs)
• application/json — jedyny oficjalny typ JSON, zdefiniowany w RFC 8259 (.json)
• image/png, image/jpeg, image/webp, image/svg+xml — popularne formaty obrazów
• application/pdf — dokumenty PDF (.pdf)
• application/octet-stream — typ ogólny dla nieznanych lub dowolnych danych binarnych
• text/plain — domyślny typ zwykłego tekstu bez bogatszego formatu

JSON zasługuje na osobną uwagę, bo często bywa źródłem pomyłek. Jedynym poprawnym typem jest application/json. Starszy kod stosował niekiedy text/json, text/plain lub application/x-javascript, lecz te warianty są przestarzałe i niektóre klienty odmówią ich parsowania. Dla JSON nie ma też parametru charset — specyfikacja nakazuje UTF-8, więc pisanie application/json; charset=utf-8 jest zbędne, choć nieszkodliwe. Pełniejszą tabelę formatów i rozszerzeń znajdziesz w naszych tabelach referencyjnych.

Dlaczego nieprawidłowy Content-Type psuje działanie

Przeglądarki i klienty ufają zadeklarowanemu typowi, więc błędne jego ustawienie ma konkretne skutki. Jeśli odpowiedź API zwracająca JSON zostanie oznaczona jako text/html, przeglądarka może próbować ją wyrenderować, albo rygorystyczny klient wyrzuci błąd parsowania, zanim Twój kod w ogóle zadziała. Plik CSS lub JavaScript wysłany z nieprawidłowym typem zostanie zablokowany przez funkcję bezpieczeństwa X-Content-Type-Options: nosniff — przeglądarka odmówi jego zastosowania, po cichu psując style lub skrypty strony.

Pobieranie plików to kolejny klasyczny przypadek problemów. Jeśli chcesz, aby plik się pobierał zamiast wyświetlać, typ jest istotny obok nagłówka Content-Disposition. PDF wysłany jako application/octet-stream pobierze się jako ogólny plik zamiast otworzyć w przeglądarce dokumentów; obraz wysłany jako text/plain pojawi się jako niezrozumiałe znaki. Po stronie przesyłania źle oznaczony plik może ominąć naiwną kontrolę rozszerzenia — dlatego solidne walidatory sprawdzają rzeczywiste bajty (tzw. magiczną liczbę), zamiast ufać typowi podanemu przez klienta.

Historycznie przeglądarki próbowały zgadywać lub „węszyć" rzeczywisty typ, gdy nagłówek wyglądał podejrzanie. To zachowanie powodowało luki bezpieczeństwa, dlatego współczesna praktyka nakazuje zawsze wysyłać dokładny Content-Type i wyłączać węszenie za pomocą nosniff. Krótko: ustawiaj typ celowo przy każdej odpowiedzi, a większość błędów renderowania, pobierania i parsowania zniknie.

Najczęściej zadawane pytania