Зачем нужна base64 (иначе я не могу просто отправить бинарный файл по электронной почте)?


27

Я читал о кодировке Base64 и нашел это в Википедии:

Схемы кодирования Base64 обычно используются, когда необходимо кодировать двоичные данные, которые необходимо хранить и передавать по носителям, предназначенным для обработки текстовых данных.

... и приведенный пример отправляет двоичные файлы по электронной почте.

Я пытаюсь понять, зачем base64. Поскольку двоичные данные представляют собой набор байтов, не будет ли он напрямую переведен в ASCII, который представляет собой текстовые данные? Зачем вообще нужна base64? Или электронная почта имеет проблемы с управляющими символами в ASCII?


Что вы имеете в виду под "прямо переводимыми"? В каком смысле base64 не является "прямым"?
David Schwartz

Почему вы думаете, что это прямо?
Cookie Monster

3
Дело не в том, что я думаю, что это прямо, а в том, что я думаю, что «прямо переводимый» - это оксюморон. Если «прямой» может включать процесс перевода, то что делает base64 не прямым? Это просто процесс перевода.
David Schwartz

Ответы:


34

Есть хороший Статья в википедии на этом.


Самые ранние итерации NCP, используемые ARPAnet, были больше похожи на битовые потоки, чем на байтовые потоки, или на попытки согласовать удобный размер байта; 8-битный байт был стандартизирован только намного позже. Было также несколько попыток создания протоколов передачи файлов, которые работали бы на разных машинах (изначально почта была функцией протокола FTP, прежде всего как MAIL а также MLFL команды, а затем разделить на MTP , потом SMTP .). Эти машины часто имели разные кодировки символов - ASCII и EBCDIC - или даже разные размеры в байтах 8-битные байты против 6-битных против ...

Поэтому функции передачи почты изначально были определены для передачи относительно коротких сообщений в виде простого текста; в частности, "NVT-ASCII". Например, RFC 772 говорит:

ПРЕДСТАВИТЕЛЬСТВО И ХРАНЕНИЕ ПОЧТЫ

Почта передается с запоминающего устройства отправляющего хоста на         устройство хранения в принимающем хосте. Это может быть необходимо         выполнять определенные преобразования на почте, потому что хранение данных         представления в двух системах различны. Например,         NVT-ASCII имеет разные представления хранения данных в разных         системы. PDP-10 обычно хранят NVT-ASCII как пять 7-битных ASCII         символы, выровненные по левому краю в 36-битном слове. Магазин 360         NVT-ASCII как четыре 8-битных кода EBCDIC в 32-битном слове. Multics         сохраняет NVT-ASCII в виде четырех 9-битных символов в 36-битном слове.

Для простоты все данные должны быть представлены в MTP как         NVT-ASCII. Это означает, что символы должны быть преобразованы в         стандартное представление NVT-ASCII при передаче текста,         независимо от того, являются ли отправляющие и принимающие хосты         непохожи. Отправитель преобразует данные из своего внутреннего         символьное представление в стандартном 8-битном NVT-ASCII         представление (см. спецификацию TELNET). Получатель         преобразует данные из стандартной формы в свою внутреннюю форму.         В соответствии с этим стандартом последовательность должна быть         используется для обозначения конца строки текста.

Даже если по кабелю передавалось восемь битов, восьмой бит часто отбрасывался или искажался, поскольку не было необходимости сохранять его; на самом деле, некоторые протоколы требуется 8-й бит, который должен быть установлен в ноль, такой как начальный SMTP RFC как указано ниже. Другими словами, программное обеспечение не было 8-битный чистый ,

Обмен данными

Соединение TCP поддерживает передачу 8-битных байтов.            Данные SMTP - это 7-битные символы ASCII. Каждый персонаж            передается как 8-битный байт с битом старшего разряда, очищенным для            нуль.

Это продолжалось долгое время даже после того, как 8-битные кодировки ISO-8859- # стали широко распространенными. Несмотря на то, что некоторые серверы были уже 8-битными, другие - нет, и слепая отправка 8-битных данных привела бы к искаженным сообщениям.

Потом, «Расширенный SMTP» был опубликован, что позволило почтовым серверам объявлять расширения SMTP, которые они поддерживали; один из них был 8BITMIMEуказывает на то, что принимающий сервер может безопасно принимать 8-битные данные. Части сообщения MIME могут иметь " Content-Transfer-Encoding : 8bit ", означая, что они не закодированы каким-либо образом.

Тем не менее, протокол SMTP остался линейным и имеет предел строки в 998 октетов, а также использует . линия (0D 0A 2E 0D 0A) в качестве индикатора «конец сообщения». Это означает, что, хотя большинство двоичных файлов можно было отправить без изменений, все же возможно, что файлы, содержащие эту последовательность октетов, будут интерпретированы как конец переданного сообщения, а остальная часть файла - как команда SMTP, что может привести к повреждению. Аналогичным образом, принимающий сервер может обрезать «строку» длиной более 998 октетов.

В 2000 году SMTP-расширение "BINARY MIME" был опубликован как RFC 3030 , что позволяет передавать необработанные двоичные данные через SMTP. Теперь сообщение передается порциями предварительно указанной длины, причем в качестве терминатора используется фрагмент нулевой длины, а Base64 & amp; подобные кодировки больше не нужны. К сожалению, немногие SMTP-серверы поддерживают это расширение; например, ни Postfix, ни Exim4 не рекламируют CHUNKING в ответ на EHLO. Чтобы воспользоваться преимуществами BINARYMIME, он должен быть поддержан все серверы в пути сообщения, которые могут быть больше, чем один или два.

Смотрите также:


1
Серверы Exchange внутри организации отправляют электронную почту в двоичном виде с помощью команды BDAT, но они не делают этого для SMTP-серверов за пределами организации.
james.garriss

6

Некоторые старые почтовые системы и программное обеспечение не были 8-битный чистый 8-й бит был использован в качестве управляющего символа. Этого было достаточно, чтобы испортить двоичные файлы, таким образом, Base64 (или другие схемы кодирования) были необходимы.


Так что мы тратим 2 бита на каждый байт только потому, что какая-то устаревшая система электронной почты 90-х годов не сможет правильно понять сообщение. Эти устаревшие системы в эпоху gmail могут составлять менее 1%. Я думаю, почему мы тратим так много пропускной способности для горстки людей? и Base64 ограничен только почтой?
vaibhav.g
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.