Dlaczego base64 jest potrzebny (aka dlaczego nie mogę po prostu wysłać pliku binarnego przez e-mail)?

30

Czytałem o kodowaniu Base64 i znalazłem to na Wikipedii:

Schematy kodowania Base64 są powszechnie stosowane, gdy zachodzi potrzeba kodowania danych binarnych, które muszą być przechowywane i przesyłane za pośrednictwem mediów zaprojektowanych do obsługi danych tekstowych.

... a podany przykład to wysyłanie plików binarnych pocztą elektroniczną.

Próbuję zrozumieć, dlaczego base64 jest potrzebne. Ponieważ dane binarne to kilka bajtów, czy nie można ich bezpośrednio przetłumaczyć na ASCII, czyli danych tekstowych? Dlaczego w ogóle potrzebny jest base64? Czy e-mail ma problem ze znakami kontrolnymi w ASCII?

Ciasteczkowy potwór
źródło
Co rozumiesz przez „bezpośrednio do przetłumaczenia”? W jakim sensie base64 nie jest „bezpośredni”?
David Schwartz
Jak myślisz, dlaczego to jest bezpośrednie?
Cookie Monster
4
Nie chodzi o to, że myślę, że jest bezpośredni, ale o to, że myślę, że „bezpośrednio do przetłumaczenia” jest oksymoronem. Jeśli „bezpośredni” może obejmować proces tłumaczenia, to co powoduje, że base64 nie jest bezpośredni? To tylko proces tłumaczenia.
David Schwartz

Odpowiedzi:

37

Jest na ten temat dobry artykuł w Wikipedii .


Najwcześniejsze iteracje NCP używane przez ARPAnet były bardziej jak strumienie bitowe niż strumienie bajtów lub próby wynegocjowania dogodnego rozmiaru bajtu; 8-bitowy bajt został znormalizowany dopiero znacznie później. Było również kilka prób stworzenia protokołów przesyłania plików, które działałyby na różnych komputerach (poczta początkowo była funkcją protokołu FTP, głównie jako polecenia MAILiMLFL , a następnie podzielona na MTP , a później SMTP ). Te maszyny często miały różne kodowanie znaków - ASCII vs EBCDIC - lub nawet różne rozmiary bajtów , 8-bitowe bajty vs 6-bitowe vs ...

Dlatego początkowo zdefiniowano funkcje przesyłania poczty do przesyłania stosunkowo krótkich wiadomości w postaci zwykłego tekstu; w szczególności „NVT-ASCII”. Na przykład RFC 772 mówi:

OŚWIADCZENIE I PRZECHOWYWANIE POCZTY

Poczta jest przesyłana z urządzenia pamięci masowej na hoście wysyłającym do urządzenia pamięci masowej na hoście odbierającym. Może być konieczne wykonanie pewnych przekształceń w poczcie, ponieważ reprezentacje przechowywania danych w dwóch systemach są różne. Na przykład NVT-ASCII ma różne reprezentacje przechowywania danych w różnych systemach. PDP-10 zazwyczaj przechowują NVT-ASCII jako pięć 7-bitowych znaków ASCII, wyrównanych do lewej w 36-bitowym słowie. 360 przechowuje NVT-ASCII jako cztery 8-bitowe kody EBCDIC w 32-bitowym słowie. Multics przechowuje NVT-ASCII jako cztery 9-bitowe znaki w 36-bitowym słowie.

Dla uproszczenia wszystkie dane muszą być reprezentowane w MTP jako NVT-ASCII. Oznacza to, że znaki muszą zostać przekonwertowane na standardową reprezentację NVT-ASCII podczas przesyłania tekstu, niezależnie od tego, czy hosty wysyłające i odbierające są różne. Nadawca konwertuje dane z wewnętrznej reprezentacji znaków na standardową 8-bitową reprezentację NVT-ASCII (patrz specyfikacja TELNET). Odbiornik konwertuje dane ze standardowego formularza na własny formularz wewnętrzny. Zgodnie z tym standardem, sekwencja powinna być użyta do oznaczenia końca linii tekstu.

Mimo że osiem bitów było transmitowanych przez drut, ósmy bit często bywał odrzucany lub zniekształcany, ponieważ nie było wymogu jego zachowania; w rzeczywistości niektóre protokoły wymagały, aby ósmy bit był ustawiony na zero, na przykład początkowy RFC SMTP, jak podano poniżej. Innymi słowy, oprogramowanie nie było 8-bitowe .

Transfer danych

Połączenie TCP obsługuje transmisję 8-bitowych bajtów. Dane SMTP to 7-bitowe znaki ASCII. Każdy znak jest przesyłany jako 8-bitowy bajt z bitem wyższego rzędu zerowanym.

Trwało to przez długi czas, nawet po rozpowszechnieniu 8-bitowych kodowań znaków ISO-8859- #. Chociaż niektóre serwery były już czyste 8-bitowo, wiele innych nie, a ślepe wysyłanie 8-bitowych danych spowodowałoby zniekształcenie wiadomości.

Później opublikowano „Extended SMTP” , który pozwala serwerom pocztowym zadeklarować obsługiwane przez nich rozszerzenia SMTP; jednym z nich było 8BITMIMEwskazanie, że serwer odbierający może bezpiecznie zaakceptować dane 8-bitowe. Części wiadomości MIME mogą mieć „ Content-Transfer-Encoding : 8bit”, co oznacza, że ​​nie są w żaden sposób kodowane.

Jednak protokół SMTP pozostał oparty na liniach i ma limit linii oktetu 998, a także wykorzystuje .linię (0D 0A 2E 0D 0A) jako wskaźnik „końca wiadomości”. Oznacza to, że nawet jeśli większość plików binarnych można wysłać w niezmienionej postaci, nadal możliwe jest, że pliki zawierające tę sekwencję oktetów będą interpretowane jako koniec przesłanej wiadomości, a reszta pliku jako polecenie SMTP, prawdopodobnie powodując uszkodzenie. Podobnie „linia” dłuższa niż 998 oktetów może zostać odcięta przez serwer odbierający.

W 2000 r. Rozszerzenie ESMTP „BINARYMIME” zostało opublikowane jako RFC 3030 , umożliwiając przesyłanie surowych danych binarnych przez SMTP. Wiadomość jest teraz przesyłana w odcinkach o wcześniej wskazanej długości, z fragmentem o zerowej długości używanym jako terminator, a kodowanie Base64 i podobne nie są już potrzebne. Niestety niewiele serwerów SMTP obsługuje to rozszerzenie; na przykład ani Postfix, ani Exim4 nie reklamują się CHUNKINGw odpowiedzi na EHLO. Aby skorzystać z BINARYMIME, musi on być obsługiwany przez wszystkie serwery w ścieżce komunikatów, która może być więcej niż jednym lub dwoma.

Zobacz też:

grawitacja
źródło
1
Serwery Exchange w organizacji wysyłają wiadomości e-mail jako pliki binarne za pomocą polecenia BDAT, ale nie robią tego w przypadku serwerów SMTP poza organizacją.
james.garriss
7

Niektóre starsze systemy poczty e-mail i oprogramowanie nie były czyste 8-bitowo , ósmy bit był używany jako znak kontrolny. To wystarczyło, aby zepsuć pliki binarne, dlatego potrzebne było oprogramowanie Base64 (lub inne schematy kodowania).

Renan
źródło
Więc marnujemy 2 bity na każdy bajt tylko dlatego, że niektóre starsze systemy poczty elektronicznej z lat 90. mogą nie być w stanie poprawnie zrozumieć wiadomości. Ten starszy system w erze Gmaila może być mniejszy niż 1%. Zastanawiam się, dlaczego marnujemy tak dużo pasma dla garstki ludzi? i czy Base64 jest ograniczony tylko do maili?
vaibhav.g