Почему размер моего электронного письма примерно на треть превышает размер вложенных файлов?

111

Прикрепляя данные к моим электронным письмам, я заметил, что Thunderbird вычисляет общий размер получаемого электронного письма, который намного больше, чем файлы, которые я прикрепил.

Вот недавний пример: два изображения, одно на 13 МБ и одно на 3,6 МБ, должны быть в общей сложности примерно 17 МБ. Там было четыре строки текста. Затем Thunderbird спросил меня, действительно ли я хочу отправить электронное письмо общим объемом 22 МБ.

Откуда эта разница? 5 МБ текста звучит как много.

email thunderbird base64

— arc_lupus
источник

Обратите внимание, что это часто влияет на такие вещи, как максимальный размер. Если я не ошибаюсь, гугл-почта обычно допускает электронную почту размером не более 25 МБ, но 25 МБ вычисляются после кодирования, поэтому вы не можете отправить изображение размером 25 МБ с электронной почтой, поскольку при кодировании оно будет на самом деле слишком большим.

— Бакуриу

Комментарий @ Bakuriu относится и к серверу Outlook + Exchange. Я полагаю, что основной вопрос на самом деле заключается в том, почему почтовые клиенты (часто - Tbird кажется лучше, чем outlook снова) сообщают только о локальном размере файла, когда важен размер в кодировке base64?

— Крис Х

@MarcksThomas Я не хочу спорить с призывом иметь один универсальный, легко доступный для поиска источник знаний, а не просто иметь все доступные для поиска знания. Но нужно ли это? Я так не думаю. - Я не думаю, что вопрос вообще бесполезен, я просто думаю, что он не отвечает основным требованиям, чтобы освободить сайт от лишних вопросов, и затрудняет поиск действительно важных вещей, которые не являются ответил где-нибудь еще. Это то, что мы должны делать! - arc_lupus, так как я только скрываюсь на этом сайте, обычно мое понижение пока не происходит. Но так оно и есть.

— Александр Косубек

Связано с: superuser.com/questions/568506/…

— glenneroo

Ответы:

214

Ваши данные были 17 МиБ. В МиБ 1024 КиБ. В КиБ 1024 Б В байте 8 бит. Это 142 606 336 бит.

Кодирование Base 64 кодирует каждые шесть битов отдельным байтом. Итак, нам нужно около 23 767 722 байта. Деление на 1024 дважды дает нам 22,67 МиБ. Так вот откуда 22 МиБ.

Электронная почта является довольно старой технологией и не предполагает 8-битную чистоту канала.

— Дэвид Шварц
источник

Немного расшифруем эту последнюю строку: base-64 - это способ кодировать вложения в виде текста, используя ограниченный набор «гарантированных безопасных символов», которые не будут искажены некоторыми промежуточными устройствами, такими как az, AZ, 0-9

— Йорик

И, как только вы поймете математику в отличном ответе Дэвида, вы можете просто умножить размер вложений на 4/3, чтобы получить размер почтового сообщения, которое будет отправлено (плюс фактический текст).

— Кент

Даже если бы электронная почта знала, что у нее есть 8-битный канал, ее нужно будет кодировать, поскольку это в основном текстовый поток - некоторые символы выполняют функции управления и, следовательно, не должны появляться в ваших данных. При этом существуют лучшие методы кодирования, но они не были приняты.

— Лорен Печтел

@LorenPechtel, вы можете с радостью иметь часть application / octet-stream в сообщении MIME. Все, что вам нужно сделать, это выбрать границу, которая не встречается в данных.

— OrangeDog

что на самом деле делает base64 , использует 4 байта на каждые 3 исходных байта. Хотя это звучит похоже, это важно, потому что длина всегда кратна 4, а также потому, что нет причин для уровня битов.

— njzk2

Почему электронная почта больше?

Потому что данные кодируются, в base64котором кодируются группы до трех байтов в виде групп из четырех печатных символов ASCII. Как правило, эти группы печатных символов затем разбиваются на строки.

В результате кодированные данные чуть более чем в 1⅓ раз превышают размер исходных данных.

Почему используется base64?

Электронная почта имеет долгую историю и изначально была предназначена для переноса текста. Только байтовые значения, представляющие печатаемые символы ASCII, могут надежно проходить через множество систем электронной почты на планете.

Таким образом, MIME разделил две схемы для кодирования других данных в виде текста ASCII - «цитируемый для печати», предназначенный в основном для текста ASCII с несколькими другими битами, и «BASE64» для произвольных двоичных данных.

Существуют расширения протокола SMTP, чтобы попытаться снять эти ограничения. Во-первых, 8BITMIME в 1994 году, который допускал более высокие значения октетов, но, к сожалению, не снимал ограничений, связанных с длинами строк и окончаниями строк, поэтому не подходил для произвольных двоичных данных; а затем BINARYMIME в 1995 году, что позволило передавать сообщения, содержащие произвольные двоичные данные.

Однако эти стандарты не получили широкого распространения. Одна проблема в том, что произойдет, если один прыжок в почтовой цепочке их поддерживает, а следующий - нет? Почтовый сервер не может отправлять почту как есть, он должен либо отклонить ее как недоставленную и отклонить ее (что вряд ли будет приемлемо для пользователей), либо преобразовать ее (что требует значительного дополнительного кода на почтовом сервере) , Преобразование становится особенно болезненным по правилам MIME, которые касаются неиспользования кодировок передачи контента в составных типах.

— plugwash
источник

Интересно, почему yEnc, с другой стороны, был достаточно успешен в Usenet при вытеснении UUE. Возможно, потому что бинарные новостные группы оказывают гораздо большее давление на интернет-провайдеров, чем случайные бинарные письма?

— igorsk

@igorsk: плюс Usenet / NN был представлен и понимается как с потерями, где вы можете опубликовать статью, и не все подписчики на всех серверах обязательно получат ее. Существовали (и в значительной степени остаются) обычаи относительно цитирования в последующем «достаточно» предыдущей статьи, чтобы ваше продолжение могло понять тот, кто не получил предыдущую статью (статьи) . В отличие от этого большинство (не спамерских) отправителей электронной почты ожидали, что «система» получит свое сообщение указанному получателю (ям), хотя иногда через несколько часов или дней; сегодня люди жалуются даже на короткие задержки.

— dave_thompson_085