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?
Odpowiedzi:
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:
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 .
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ż:
źródło
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).
źródło