Kodowanie Content Transfer 7-bitowe lub 8-bitowe

88

Podczas wysyłania treści e-mail wymagane jest ustawienie nagłówka „Content Transfer Encoding”. Zauważyłem wiele nagłówków otrzymanych e-maili. Niektóre e-maile używają „7-bitowego”, a inne „8-bitowego”.

Jaka jest różnica między tymi dwoma? Co jest zalecane? Czy jest wymagane jakieś specjalne kodowanie treści wiadomości e-mail, aby ustawić te nagłówki?

mahi
źródło
Nie sądzę, aby było wymagane ustawienie tego nagłówka, prawda? Zaczynam pracować z pocztą e-mail i widziałem e-maile bez niej - bardzo proste, nie wieloczęściowe wiadomości zawierające tylko tekst ASCII.
osullic

Odpowiedzi:

280

Może być trochę gęsty do czytania, ale sekcja „Content-Transfer-Encoding” w dokumencie RFC 1341 zawiera wszystkie szczegóły:

http://www.w3.org/Protocols/rfc1341/5_Content-Transfer-Encoding.html

Sytuacja trochę się pogarsza. Oto moje podsumowanie:

tło

SMTP z definicji (RFC 821) ogranicza pocztę do wierszy po 1000 znaków po 7 bitów. Oznacza to, że żaden z bajtów wysyłanych potokiem nie może mieć najbardziej znaczącego („najwyższego rzędu”) bitu ustawionego na „1”.

Treści, które chcemy wysłać, często z natury nie podlegają temu ograniczeniu. Pomyśl o pliku obrazu lub pliku tekstowym, który zawiera znaki Unicode: bajty tych plików często mają swój 8-ty bit ustawiony na „1”. SMTP na to nie pozwala, więc musisz użyć „kodowania transferu”, aby opisać, jak obejść tę niezgodność.

Wartości Content-Transfer-Encodingnagłówka opisują regułę wybraną do rozwiązania tego problemu.

Kodowanie 7-bitowe

7bitoznacza po prostu „Moje dane składają się tylko ze znaków US-ASCII, które używają tylko dolnych 7 bitów dla każdego znaku”. Zasadniczo gwarantujesz, że wszystkie bajty w Twojej treści są już zgodne z ograniczeniami SMTP, więc nie wymaga specjalnego traktowania. Możesz po prostu przeczytać to tak, jak jest.

Pamiętaj, że dokonując wyboru 7bit, zgadzasz się, że wszystkie wiersze w Twojej treści mają mniej niż 1000 znaków.

Tak długo, jak treść jest zgodna z tą zasadą, 7bitjest najlepszym kodowaniem transferu, ponieważ nie jest wymagana żadna dodatkowa praca; po prostu odczytujesz / zapisujesz bajty wychodzące z potoku. Łatwo też przejrzeć 7bitzawartość i nadać jej sens. Pomysł jest taki, że jeśli piszesz po prostu „zwykłym angielskim tekstem”, wszystko będzie dobrze. Ale to nie była prawda w 2005 roku i nie jest tak dzisiaj.

Kodowanie 8-bitowe

8bitoznacza „Moje dane mogą zawierać rozszerzone znaki ASCII; mogą używać ósmego (najwyższego) bitu do oznaczenia znaków specjalnych poza standardowymi 7-bitowymi znakami US-ASCII”. Podobnie jak w przypadku 7bit, nadal obowiązuje limit 1000 znaków.

8bit, tak jak 7bit, właściwie nie dokonuje żadnej transformacji bajtów, gdy są one zapisywane lub odczytywane z drutu. Oznacza to po prostu, że nie gwarantujesz, że żaden z bajtów nie będzie miał najwyższego bitu ustawionego na „1”.

Wydaje się, że jest to krok naprzód 7bit, ponieważ zapewnia większą swobodę w zakresie treści. Jednak RFC 1341 zawiera tę ciekawostkę:

W chwili publikacji tego dokumentu nie ma ustandaryzowanych transportów internetowych, w przypadku których uzasadnione jest umieszczanie niezakodowanych 8-bitowych lub binarnych danych w treści wiadomości. Dlatego nie ma okoliczności, w których „8-bitowe” lub „binarne” kodowanie transferu treści jest rzeczywiście legalne w Internecie.

RFC 1341 ukazał się ponad 20 lat temu. Od tego czasu w RFC 6152 otrzymaliśmy 8-bitowe rozszerzenia MIME . Ale nawet wtedy mogą obowiązywać limity linii:

Zauważ, że to rozszerzenie NIE eliminuje możliwości ograniczenia przez serwer SMTP długości linii; serwery mogą zaimplementować to rozszerzenie, ale mimo to ustawiają limit długości linii nie mniejszy niż 1000 oktetów.

Kodowanie binarne

binaryjest taki sam jak 8bit, ale nie ma ograniczenia długości linii. Nadal możesz dołączyć dowolne znaki i nie ma dodatkowego kodowania. Podobnie 8bit, RFC 1341 stwierdza, że ​​tak naprawdę nie jest to uzasadnione kodowanie kodowania transferu. RFC 3030 rozszerzył to o BINARYMIME.

Cytowane do druku

Przed 8BITMIMErozszerzeniem musiał istnieć sposób na wysyłanie treści, których nie można było 7bitprzesyłać przez SMTP. Pliki HTML (które mogą mieć więcej niż 1000-znakowe linie) i pliki ze znakami międzynarodowymi są tego dobrymi przykładami. quoted-printableKodowanie (zdefiniowanych w sekcji 5.1 RFC 1341) jest przeznaczony do obsługi tego. Robi dwie rzeczy:

  • Definiuje sposób zmiany znaczenia znaków spoza zestawu US-ASCII, aby można je było przedstawić za pomocą tylko 7-bitowych znaków. (Wersja krótka: są wyświetlane jako znak równości plus dwa znaki 7-bitowe).
  • Definiuje, że wiersze będą miały nie więcej niż 76 znaków, a podziały wierszy będą reprezentowane za pomocą znaków specjalnych (które są następnie znakowane).

Cytat do druku, ze względu na ucieczkę i krótkie wiersze, jest znacznie trudniejszy do odczytania przez człowieka niż 7bitlub 8bit, ale obsługuje znacznie szerszy zakres możliwych treści.

Kodowanie Base64

Jeśli Twoje dane są w większości nietekstowe (np. Plik obrazu), nie masz wielu opcji. 7bitjest poza stołem. 8biti binarynie były obsługiwane przed specyfikacjami RFC dotyczącymi rozszerzenia MIME. quoted-printabledziałałoby, ale jest naprawdę nieefektywne (każdy bajt będzie reprezentowany przez 3 znaki).

base64jest dobrym rozwiązaniem dla tego typu danych. Koduje 3 surowe bajty jako 4 znaki US-ASCII, co jest stosunkowo wydajne. RFC 1341 dodatkowo ogranicza długość linii base64zakodowanych danych do 76 znaków, aby zmieścić się w wiadomości SMTP, ale jest to stosunkowo łatwe do zarządzania, gdy po prostu dzielisz lub łączysz dowolne znaki o ustalonej długości.

Dużym minusem jest to, że base64dane zakodowane są prawie całkowicie nieczytelne dla ludzi, nawet jeśli są to tylko „zwykły” tekst pod spodem.

Craig Walker
źródło
10
To niesamowita odpowiedź. Chciałbym móc zagłosować 100 razy za! Jedno pytanie: czy te zasady dotyczą załączników? Przykładem, jaki mam, jest plik XML dołączony do wiadomości e-mail, w którym zawartość pliku XML zawiera dane UTF-8. Jakie jest właściwe podejście tutaj?
TrojanName
1
@TrojanName: Tak, dotyczą one całej treści wiadomości e-mail, w tym załączników. (Wszystko to tylko „części” MIME pod okładkami, ale to już inna historia). Nadal będziesz musiał jakoś zakodować zawartość, aby umieścić ją w e-mailu.
Craig Walker
1
@TrojanName: Każdy plik jest plikiem „binarnym”, niezależnie od tego, czy można go również uznać za tekst, więc BINARYMIME i BINARY są dostępne (o ile są dostępne dla wszystkiego). 7Bit nie jest dobry, ponieważ zawartość UTF-8 potrzebuje 8 bitów do reprezentowania treści. 8Bit nie jest dobry, ponieważ wymaga ograniczeń długości linii, które nie są częścią treści.
Craig Walker
2
To pozostawia Quoted Printable lub Base64, z których oba mogą z powodzeniem zakodować twój dokument XML w twojej wiadomości e-mail. Zauważ, że oba te elementy utrudnią człowiekowi czytanie w formacie surowym (Base64 jest nieczytelny, QP jest trudny). Ale czytelność człowieka jest kwestią drugorzędną; tak długo, jak zawsze zakładasz, że musisz go odkodować, a także zakodować, wszystko jest w porządku.
Craig Walker
2
Ograniczenia dotyczące dodawania: 8-bitowe nie powinny zawierać wartości null lub nie-końca linii CR lub LF.
Max