Content-Transfer-Encoding

Content-Transfer-Encoding to nagłówek MIME określający sposób kodowania danej części wiadomości podczas jej transportu.

Rola nagłówka Content-Transfer-Encoding w wiadomości MIME

Content-Transfer-Encoding jest nagłówkiem MIME opisującym sposób przedstawienia danych należących do konkretnej części wiadomości podczas transportu. Nie określa języka tekstu ani zestawu znaków. Za interpretację znaków odpowiada przede wszystkim nagłówek Content-Type, na przykład parametr charset=utf-8. Content-Transfer-Encoding wskazuje natomiast, czy zawartość została przesłana bez dodatkowej konwersji, czy zamieniona na reprezentację bezpieczniejszą dla starszych mechanizmów pocztowych.

Nagłówek może wystąpić przy zwykłej treści tekstowej, załączniku, obrazie albo innej części struktury multipart. W wiadomości wieloczęściowej każda część ma własne nagłówki i własny sposób kodowania. Przykładowo tekst może używać quoted-printable, a plik graficzny base64. Serwer pocztowy i program odbiorcy odczytują wartość nagłówka, dekodują dane, a następnie przekazują aplikacji właściwą treść.

Dozwolone wartości i ich właściwości

Standard MIME opisany w RFC 2045 definiuje między innymi wartości 7bit, 8bit, binary, quoted-printable oraz base64. Wartość 7bit oznacza dane zapisane w oktetach z zakresu ASCII, bez bajtów o ustawionym najwyższym bicie. Taka treść może być przesyłana bez kodowania, ale musi spełniać ograniczenia właściwe dla transportu pocztowego, między innymi dotyczące długości linii i używanych znaków. Wartość 8bit dopuszcza bajty spoza podstawowego zakresu ASCII, lecz nadal zakłada strukturę danych odpowiednią dla transportu tekstowego.

Wartość binary oznacza dane binarne bez ograniczeń charakterystycznych dla reprezentacji 7bit lub 8bit. Nie każdy kanał pocztowy potrafi jednak przenieść taki materiał bez zmian, dlatego binary jest mniej praktyczne w klasycznych ścieżkach SMTP. Quoted-printable zapisuje większość znaków drukowalnych bezpośrednio, a wybrane oktety przedstawia jako znak równości i dwie cyfry szesnastkowe, na przykład =C5. Dzięki temu tekst pozostaje częściowo czytelny, a znaki spoza ASCII mogą zostać bezpiecznie odtworzone.

Base64 zamienia dane na ciąg znaków należących do ograniczonego alfabetu ASCII. Kodowanie to jest używane przede wszystkim dla załączników i innych danych binarnych. Zwiększa objętość danych mniej więcej o jedną trzecią, ponieważ trzy oktety wejściowe są reprezentowane przez cztery znaki. Base64 nie szyfruje zawartości i nie zapewnia poufności; jest wyłącznie sposobem reprezentacji danych w wiadomości.

Różnica między kodowaniem transportowym a zestawem znaków

Content-Transfer-Encoding bywa mylony z kodowaniem znaków, ponieważ oba nagłówki mogą pojawić się przy wiadomościach zawierających polskie litery. Są to jednak dwa niezależne mechanizmy. Content-Type: text/plain; charset=UTF-8 informuje, jak interpretować sekwencje bajtów jako znaki. Content-Transfer-Encoding: quoted-printable albo Content-Transfer-Encoding: base64 informuje, jak odzyskać pierwotne bajty z ich transportowej reprezentacji. Możliwe jest więc połączenie UTF-8 z quoted-printable, UTF-8 z base64 albo innym odpowiednim wariantem.

Błędna wartość nagłówka lub jej brak może spowodować wyświetlanie fragmentów takich jak =C5=82 zamiast polskiej litery, widoczne ciągi base64 zamiast załącznika albo komunikat o uszkodzonym pliku. Problem może powstać również wtedy, gdy po drodze zmieniono treść, usunięto znaki końca linii albo zastosowano dekoder niezgodny z rzeczywistym formatem. Sam fakt, że wiadomość zawiera znaki narodowe, nie oznacza jeszcze konieczności użycia base64. Dla krótkiego tekstu często wystarcza quoted-printable, natomiast dane binarne wymagają reprezentacji przystosowanej do ich pełnego zakresu bajtów.

Podczas analizy wiadomości warto sprawdzić nagłówki każdej części MIME, a nie tylko nagłówki całej wiadomości. Następnie należy porównać deklarowaną wartość z faktyczną postacią danych. Jeżeli część oznaczona jako base64 zawiera zwykły tekst, może to wskazywać na błąd generowania wiadomości. Jeżeli część oznaczona jako 7bit zawiera bajty spoza ASCII lub nieprawidłowe znaki sterujące, problem dotyczy zgodności zawartości z deklaracją transportową.

Sprawdzanie wiadomości MIME na komputerze

Diagnostyka problemu z Content-Transfer-Encoding rozpoczyna się od wyświetlenia źródła wiadomości, a nie od samego widoku w programie pocztowym. W źródle należy odszukać nagłówki Content-Type, Content-Transfer-Encoding oraz granice multipart wyznaczane przez parametr boundary. Każdą część trzeba analizować osobno. Dla quoted-printable sprawdza się poprawność sekwencji =XX i znaków miękkiego końca linii, a dla base64 — długość oraz poprawność alfabetu kodowania i uzupełnienia znakiem =.

W przypadku załącznika warto porównać nazwę i typ deklarowany w Content-Disposition oraz Content-Type z wynikiem dekodowania. Nieprawidłowe rozszerzenie pliku nie musi oznaczać problemu z samym Content-Transfer-Encoding, ponieważ nazwa i typ są przekazywane w innych nagłówkach. Jeżeli po poprawnym dekodowaniu suma kontrolna albo rozmiar pliku nie zgadza się z oryginałem, możliwe jest uszkodzenie danych w trakcie tworzenia, zapisu lub transportu wiadomości.

Warszawskie Pogotowie Komputerowe zajmuje się profesjonalną naprawą laptopów, komputerów PC i podzespołów, dlatego przy problemach z wyświetlaniem wiadomości lub otwieraniem załączników można rozpocząć od sprawdzenia programu pocztowego, konfiguracji systemu i stanu komputera.