Перевод строки (0x0A) преобразуется в возврат каретки (0x0D) во время передачи файла электронной почты

Question

Я отправляю файл по электронной почте с Mac (Snow Leopard) на другой Mac (Lion).

Оказывается, что все переводы строки (0x0A) в файле преобразуются в возврат каретки (0x0D), фактически превращая исходный файл в совершенно другой файл.

Есть идеи, почему что-то подобное произошло?

Этого не происходит, когда отправитель загружает файл в Интернет, а получатель затем загружает файл с помощью своего веб-браузера. Это также не происходит, если отправитель сначала архивирует файл и отправляет его по электронной почте; Получатель получает исходный файл без изменений после распаковки ZIP-файла. Есть ли что-то особенное в передаче электронной почты, о которой я должен знать?

Answer 1

В передачах по электронной почте нет ничего особенного, о чем вы должны знать.

Обычной функцией почтового клиента при передаче файла является передача как есть. Кодировка файла с использованием base64 или чего-либо еще не должна подразумевать каких-либо изменений в содержимом файла.

Очевидно, ваш почтовый клиент перевыполняет свою работу. Он не только проанализировал файл и решил, что он содержит текст, но и взял на себя задачу нормализовать конец строк. К сожалению, это мешает работе.

Согласно Википедии, возврат каретки - это символ Newline для Mac OS до версии 9. Это, конечно, не должно быть в случае снежного барса.

Не будучи на Mac, я ничего не могу проверить. И так как я не знаю, какой почтовый клиент используется, я не могу найти проблему в Google. Поэтому я предлагаю вам взглянуть на настройки этого неизвестного почтового клиента и попытаться найти какой-нибудь вариант совместимости с OS-9, который был включен по ошибке, или какой-то другой параметр для передачи файлов как есть.

Answer 2

SMTP RFC2821, раздел 2.3.7 (находится здесь) гласит следующее:

SMTP-команды и, если не изменено расширением службы, данные сообщения передаются "линиями". Строки состоят из нуля или более символов данных, оканчивающихся символом ASCII последовательности "CR" (шестнадцатеричное значение 0D), за которым сразу следует символ ASCII "LF" (шестнадцатеричное значение 0A).

Таким образом, ваш MUA ДОЛЖЕН конвертировать их перед отправкой через SMTP-сервер. Помните, что SMTP был разработан для текстовых данных и поэтому не является двоично-совместимым (см. Кодировку base64 для получения дополнительной информации об отправке двоичных данных)

Answer 3

Либо zip, tar, gzip, bzip или какая-то их комбинация перед отправкой файла, либо найдите другой почтовый клиент. Очевидно, тот, который вы используете, выполняет слишком много работы.