Dlaczego rozmiar mojej wiadomości e-mail jest około jednej trzeciej większy niż rozmiar załączonych plików?


111

Dołączając dane do moich wiadomości e-mail, zauważyłem, że Thunderbird oblicza całkowity rozmiar powstałej wiadomości e-mail jako znacznie większy niż pliki, które załączyłem.

Oto ostatni przykład: dwa obrazy, jeden o wielkości 13 MB i jeden o wielkości 3,6 MB, powinny w sumie mieć około 17 MB. Były cztery linie tekstu. Następnie Thunderbird zapytał mnie, czy naprawdę chcę wysłać wiadomość e-mail o łącznej wielkości 22 MB.

Skąd ta różnica? 5 MB tekstu brzmi trochę dużo.


2
Pamiętaj, że często wpływa to na takie rzeczy, jak maksymalny rozmiar. Jeśli się nie mylę, poczta Google zazwyczaj zezwala na wysyłanie wiadomości e-mail o maksymalnej wielkości 25 MB, ale 25 MB jest obliczane po zakodowaniu, więc nie można wysłać obrazu 25 MB za pomocą wiadomości e-mail, ponieważ po zakodowaniu byłby zbyt duży.
Bakuriu

4
Komentarz @ Bakuriu dotyczy również serwera Outlook + Exchange. Sugeruję, że zasadniczym pytaniem jest właściwie: dlaczego klienci poczty (często - Tbird wydaje się lepszy niż perspektywy) zgłaszają tylko rozmiar pliku lokalnego, gdy liczy się rozmiar w formacie base64?
Chris H

@MarcksThomas Nie chcę kłócić się z apelem o posiadanie jednego, wszechstronnego, łatwo przeszukiwalnego źródła wiedzy, a nie o to, że całą wiedzę można łatwo przeszukiwać. Ale czy to konieczne? Nie wydaje mi się - Nie sądzę, że pytanie w ogóle nie jest przydatne, po prostu uważam, że nie spełnia ono podstawowych wymagań, aby strona była wolna od niepotrzebnych pytań i utrudnia znalezienie naprawdę ważnych rzeczy, co nie jest odpowiedział gdziekolwiek indziej. To właśnie powinniśmy robić! - arc_lupus, ponieważ czaję się tylko na tej stronie, zazwyczaj mój downvote jeszcze nie chce. Ale tak to jest.
Alexander Kosubek

Odpowiedzi:


214

Twoje dane wyniosły 17 MiB. W MiB jest 1024 KiB. KiB ma 1024 B. Bajt zawiera 8 bitów. Więc to 142 606 336 bitów.

Kodowanie Base 64 koduje co sześć bitów jako osobny bajt. Potrzebujemy więc około 23 767 722 bajtów. Dwukrotne podzielenie przez 1024 daje nam 22,67 MiB. Stąd pochodzi 22 MiB.

E-mail jest dość starą technologią i nie zakłada 8-bitowej czystej rury.


79
Aby trochę zdekodować ten ostatni wiersz: base-64 jest sposobem kodowania załączników jako tekstu przy użyciu ograniczonego zestawu „gwarantowanych bezpiecznych znaków”, które nie zostałyby zniekształcone przez niektóre urządzenia pośredniczące, takie jak az, AZ, 0-9
Yorik

64
A kiedy zrozumiesz matematykę w doskonałej odpowiedzi Dawida, możesz po prostu pomnożyć rozmiar załączników przez 4/3, aby uzyskać rozmiar wiadomości e-mail, która zostanie wysłana (plus rzeczywisty tekst).
Kent

12
Nawet jeśli wiadomość e-mail wiedziała, że ​​ma pełny 8-bitowy potok, musiałby być kodowany, ponieważ zasadniczo jest to strumień tekstowy - niektóre znaki pełnią funkcje kontrolne, a zatem nie mogą występować w danych. Mimo to istnieją lepsze techniki kodowania, ale nie zostały one przyjęte.
Loren Pechtel

3
@LorenPechtel możesz szczęśliwie mieć część aplikacji / strumienia oktetów w wiadomości MIME. Wszystko, co musisz zrobić, to wybrać granicę, która nie występuje w danych.
OrangeDog

8
to, co faktycznie robi base64 , to używanie 4 bajtów na każde 3 oryginalne bajty. Chociaż brzmi to podobnie, jest to ważne, ponieważ długość jest zawsze wielokrotnością 4, a także dlatego, że nie ma powodu do poziomu bitów.
njzk2

50

Dlaczego e-mail jest większy?

Ponieważ dane są zakodowane, w base64którym kodują grupy do trzech bajtów jako grupy czterech drukowalnych znaków ASCII. Zazwyczaj te grupy znaków do wydruku są następnie dzielone na linie.

W rezultacie zakodowane dane są nieco ponad 1,5 razy większe niż oryginalne dane.

Dlaczego używany jest base64?

Wiadomość e-mail ma długą historię i pierwotnie została zaprojektowana do przenoszenia tekstu. Tylko wartości bajtów reprezentujące znaki drukowalne ASCII mogą niezawodnie przejść przez wiele różnych systemów poczty elektronicznej na świecie.

Tak więc MIME podzielił dwa schematy kodowania innych danych jako tekst ASCII - „cytowany do wydruku” przeznaczony głównie dla tekstu ASCII z kilkoma innymi bitami oraz „BASE64” dla dowolnych danych binarnych.

Istnieją rozszerzenia protokołu SMTP, aby spróbować usunąć te ograniczenia. Po pierwsze, 8BITMIME w 1994 r., Który pozwalał na wyższe wartości oktetów, ale niestety nie usunął limitów związanych z długością linii i zakończeniami linii, więc nie był odpowiedni dla dowolnych danych binarnych; a następnie BINARYMIME w 1995 r., co pozwoliło na przesyłanie wiadomości zawierających dowolne dane binarne.

Jednak standardy te nie spotkały się z powszechnym przyjęciem. Jednym problemem jest to, co się stanie, jeśli jeden skok w łańcuchu poczty obsługuje je, ale następny skok nie? Serwer pocztowy nie może wtedy wysyłać wiadomości w stanie, w jakim się znajduje, musi albo odrzucić ją jako niemożliwą do dostarczenia i odesłać (co raczej nie będzie akceptowalne dla użytkowników), albo przekonwertować (co wymaga znacznego dodatkowego kodu na serwerze pocztowym) . Konwersja jest szczególnie bolesna z powodu reguł MIME dotyczących niestosowania kodowań przesyłania treści w typach wieloczęściowych.


1
Zastanawiam się, dlaczego z kolei YEnc odnosi sukcesy w Usenecie w wypieraniu UUE. Być może dlatego, że binarne grupy dyskusyjne wywierają znacznie większą presję na dostawców usług internetowych niż okazjonalne binarne wiadomości e-mail?
igorsk

2
@igorsk: plus Usenet / NN został przedstawiony i uznany za stratny, w którym można opublikować artykuł, a nie wszyscy subskrybenci na wszystkich serwerach koniecznie go otrzymają. Istniały (i w dużej mierze pozostają) zwyczaje dotyczące cytowania w następnej „wystarczającej” liczbie poprzednich artykułów, aby twoje dalsze zrozumienie mogło być zrozumiane przez osobę, która nie otrzymała poprzednich artykułów . W przeciwieństwie do tego, większość (nie spamujących) nadawców wiadomości e-mail spodziewała się, że „system” dostanie wiadomość do wskazanych adresatów, choć czasem po godzinach lub dniach; dziś ludzie narzekają nawet na krótkie opóźnienia.
dave_thompson_085
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.