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:
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-Encoding
nagłówka opisują regułę wybraną do rozwiązania tego problemu.Kodowanie 7-bitowe
7bit
oznacza 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ą,
7bit
jest najlepszym kodowaniem transferu, ponieważ nie jest wymagana żadna dodatkowa praca; po prostu odczytujesz / zapisujesz bajty wychodzące z potoku. Łatwo też przejrzeć7bit
zawartość 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
8bit
oznacza „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 przypadku7bit
, nadal obowiązuje limit 1000 znaków.8bit
, tak jak7bit
, 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ę: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:
Kodowanie binarne
binary
jest taki sam jak8bit
, ale nie ma ograniczenia długości linii. Nadal możesz dołączyć dowolne znaki i nie ma dodatkowego kodowania. Podobnie8bit
, RFC 1341 stwierdza, że tak naprawdę nie jest to uzasadnione kodowanie kodowania transferu. RFC 3030 rozszerzył to oBINARYMIME
.Cytowane do druku
Przed
8BITMIME
rozszerzeniem musiał istnieć sposób na wysyłanie treści, których nie można było7bit
przesył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-printable
Kodowanie (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ż
7bit
lub8bit
, 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.
7bit
jest poza stołem.8bit
ibinary
nie były obsługiwane przed specyfikacjami RFC dotyczącymi rozszerzenia MIME.quoted-printable
działałoby, ale jest naprawdę nieefektywne (każdy bajt będzie reprezentowany przez 3 znaki).base64
jest 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ść liniibase64
zakodowanych 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
base64
dane zakodowane są prawie całkowicie nieczytelne dla ludzi, nawet jeśli są to tylko „zwykły” tekst pod spodem.źródło