Инструменты разработчика · Кодер и декодер Base64
Почему вложения электронной почты являются Base64: MIME, 7-битный транспорт и 76-строки столбцов
· Фон
base64 кодирование
Электронная почта была создана для 7-битного ASCII текста, и вложения должны были проходить сквозь него. В этом посте рассказывается, как MIME принял Base64, почему строки переносятся на символы 76 и что это означает для размера и отладки.
Пришедшее вложение повреждено из-за старого реле — проблема 8-бита, для решения которой был изобретен MIME.
Электронная почта была разработана в 1970-х и 1980-х годах только для 7-битного ASCII текста. SMTP, протокол передачи электронной почты, ожидает, что каждая строка будет содержать не более 998 символов 7-бита ASCII (символы 0-127). Отправка двоичного файла, такого как PDF, или изображения напрямую через SMTP не удастся: байты 128-255 будут повреждены или отклонены старыми почтовыми серверами и ретрансляторами. Вложения требуют кодирования. MIME (многоцелевые расширения почты Интернета, RFC 2045) решили эту проблему, определив значения заголовка Content-Transfer-Encoding, включая base64, который представляет любую последовательность байтов как 7-битный ASCII текст.
MIME предлагает несколько вариантов кодирования передачи контента: 7bit (без кодирования, только для безопасного ASCII), 8bit (для серверов, поддерживающих 8-битные байты, не универсальный), Quote-printable (кодирует только небезопасные байты, сохраняя читаемость ASCII), и base64 (кодирует все, обеспечивая максимальную совместимость). Base64 был выбран для двоичных вложений, потому что он прост, стандартизирован и гарантирует безопасность в любой почтовой системе, независимо от ее возраста или строго 7-бит. Компромисс — размер: Base64 примерно на треть больше исходных байтов.
Транспортная проблема, которую решает Base64 — представление произвольных байтов печатными символами
3 KB PDF становится примерно 4 KB текста Base64. Максимальное количество символов в строке 76 происходит от RFC 2045.
SMTP допускает строки длиной до 998 символов, но старые почтовые системы и некоторые спам-фильтры отвергают длинные строки. RFC 2045 указывает, что длина строк MIME Base64 не должна превышать 76 символов (плюс окончание строки CRLF), поэтому почтовый сервер никогда не нарушит транспортировку. Предел не волшебный; это исторический компромисс между читабельностью (символы 76 подходят для большинства терминалов 1980-х годов), совместимостью со старыми системами и предотвращением обнаружения в качестве спама или вирусных шаблонов.
Варианты вывода, видимые в этом инструменте — каноническое заполнение и необязательный перенос символов 76.
Современные почтовые системы обычно поддерживают более длинные строки, но кодирование в строки из 76 символов гарантирует, что вложение дойдет даже до самого старого получателя. После того как RFC 2045 определил MIME Base64, RFC 4288 (типы носителей) и RFC 2183 (Content-Disposition) добавили стандартизированные способы маркировки вложений. Сообщение с вложением PDF включает заголовок Content-Transfer-Encoding: base64, заголовок Content-Type: application/pdf и байты PDF, закодированные как Base64 со строками из 76 символов. Программа чтения почты декодирует строки, удаляя разрывы строк (CRLF символов), а затем декодируя Base64 для восстановления исходных байтов.
Декодирование вложения MIME Base64 требует игнорирования пробелов. RFC говорит: декодеры должны пропускать разрывы строк (символы CR и LF) во время декодирования. Вот почему декодер Base64, допускающий пробелы, практичен; большинство реальных писем MIME будут иметь разрывы строк. Некоторые декодеры являются строгими и отвергают пробелы (подходят для таких контекстов, как JWT, где разрывы строк не должны присутствовать), в то время как другие снисходительны и пропускают пробелы (подходят для MIME).
Параметр 76 на практике — как кодер вставляет, а декодер игнорирует разрывы строк
Инструмент кодирования и декодера Base64 может обрабатывать оба варианта: он принимает вставленное многострочное вложение и игнорирует разрывы строк во время декодирования. Влияние размера предсказуемо. RFC 2045 base64-обертка добавляет один CRLF (2 bytes) на каждые 76 символов вывода. Для файла 10 KB Base64 составляет примерно 13.3 KB плюс CRLF каждые 76 символов: всего около 13.5 KB. Накладные расходы составляют примерно на треть больше байт.
Ограничения на размер электронного письма обычно указываются для закодированного размера, а не для исходного размера файла; почтовый сервер с ограничением 25 MB означает 25 MB закодированного сообщения, а не 25 MB вложений. Для расчета исходного размера файла необходимо разделить его на 1.33 (точнее, на 4, разделенное на 3). Кодирование Quoted-printable — это альтернатива, которая сохраняет печатаемый ASCII неизменным и кодирует только байты 128-255 и несколько специальных символов.
Рабочий пример: чтение необработанного источника сообщения — поиск части Base64 и декодирование небольшого текстового вложения.
Текстовый файл, содержащий в основном ASCII, остается доступным для чтения, если вы откроете источник необработанного сообщения. Base64 запутывает все, даже простой текст ASCII. Quoted-printable редко используется для двоичных файлов (это было бы очень неэффективно для PDF), но иногда используется для текста. Программа чтения почты выбирает кодировку в зависимости от типа вложения; браузер обычно не спрашивает пользователя, какую кодировку применить.
Тело сообщения электронной почты в формате Base64 — это сами байты, а не отдельный файл. Когда вы видите вложение в программе чтения почты, это означает, что программа чтения уже декодировала Base64 и показывает исходный файл.
На практике размер стоит — примерно на треть больше байт, и почему для закодированного размера установлены ограничения на размер почты
Если вы просмотрите исходный источник сообщения (опция в большинстве почтовых клиентов), вы увидите заголовки MIME и тело в кодировке Base64. Инструмент кодирования и декодера Base64 может помочь вам вручную декодировать фрагмент источника сообщения; скопируйте часть Base64, удалите разрывы строк и вставьте ее в инструмент.
Несколько вложений в сообщении MIME используют составную границу. Каждая часть имеет свои собственные заголовки (Content-Type, Content-Transfer-Encoding) и тело. Альтернативная версия сообщения в виде обычного текста отображается как одна часть, а каждое вложение — как другая часть. Граничная строка разделяет части; выбрано, чтобы он не появлялся ни в каком содержимом части. Программа чтения почты реконструирует сообщение, анализируя границы и декодируя каждую часть в соответствии с заголовком Content-Transfer-Encoding.
Что здесь не рассматривается — заголовки кодированных слов, S/MIME и расширение 8BITMIME в деталях.
RFC 2045 Кодировка base64 сегодня не является универсальной. Некоторые почтовые системы поддерживают 8-битный транспорт и больше не требуют base64. Некоторые системы используют разные имена кодировок или добавляют собственные заголовки. Но base64 со строками из 76 остается наиболее совместимым выбором для вложений, которые должны достигать любой почтовой системы в любом месте. Когда вы прикрепляете файл с помощью почтового клиента, клиент обычно автоматически выбирает base64 для двоичных файлов, обрабатывает перенос строк и добавляет заголовки MIME.
Понимание этого механизма поможет вам выполнить отладку, когда вложение кажется поврежденным или когда вы вручную работаете с источником сообщения. Для создания или анализа исходящего сообщения электронной почты требуется понимание структуры MIME. Библиотека должна обрабатывать кодировку, перенос строк и заголовки; обычно вы не создаете MIME вручную. Но если вы анализируете необработанный источник сообщения (отлаживаете проблему доставки или программно извлекаете вложения), знание того, что Content-Transfer-Encoding: base64 означает, что следующее тело представляет собой 76-символовую оболочку base64, позволяет вам применить правильный декодер.
Вывод: Base64 — это уровень совместимости электронной почты: как кодировщик и декодер Base64 позволяет локально читать небольшую часть текста из необработанного сообщения.
Сам base64 является стандартным RFC 4648; заголовки «обертка» и «MIME» предназначены только для электронной почты. Вложения электронной почты имеют формат base64, поскольку электронная почта была создана для обычного текста, а base64 — это самый простой и универсальный уровень совместимости для отправки двоичных данных через текстовый протокол. Ограничение на строку 76 — исторический артефакт терминалов и медленных сетей 1980-х годов, но оно продолжает оставаться стандартом совместимости.
Понимание этой истории объясняет, почему существует MIME, почему существует несколько вариантов кодирования и почему base64 остается стандартным для вложений, хотя современные почтовые системы могут напрямую поддерживать двоичные файлы. Кодер и декодер Base64 позволяет вручную работать с телами MIME для проверки или отладки кодировки.