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?
Odpowiedzi:
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:
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.
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.
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.
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.
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:
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.
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.