Confused about Content-Transfer-Encoding при отправке XML-файла в виде вложения

Question

У меня есть XML-файл с кодировкой UTF-8, который отправляется по электронной почте в виде вложения. Когда получатель электронной почты открывает письмо и сохраняет вложение, XML-файл больше не является UTF-8 (вместо этого он сообщает кодировку ANSI). В этом случае получатель использовал Microsoft Outlook, если это имеет значение.

Я программирую это в среде, где я не могу полагаться на доступность подходящих библиотек MIME, поэтому мне нужно понять, в чем я ошибаюсь.

Перед отправкой по электронной почте XML-файла, после его создания на сервере, я могу увидеть, используя команду файла Linux, что это файл UTF-8. Отдельно этому, XML также имеет заголовок версии <?xml version="1.0" encoding="UTF-8"?> (что не имеет отношения к моей проблеме, но я включаю его для полноты). Я почти уверен, что мой код, который отправляет по электронной почте файл, является проблемой здесь, но я не уверен, что это «правильный» способ сделать это.

Заголовки Я посылающие являются:

"Mime-Version" "1.0" 
"Content-Type" "multipart/mixed; boundary="__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___"\n\n" 

Тело письма является:

--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___\n 
Content-Type: text/plain; charset="utf-8"; format=flowed\n 
Content-Transfer-Encoding: 7bit\n\n 
Please find attached the data file generated 
--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___\n 
Content-Type: text/plain; charset="utf-8"\n 
Content-Disposition: attachment; filename="My_File_Name"\n\n 
XML FILE CONTENTS GO HERE 
--__==NAHDHDH2.28ABSDJxjhkjhsdkjhd___--\n 

Вопросы:

• я должен использовать quoted-printable, 8bit или других тип Content-Transfer-Encoding здесь? Я пробовал их все, но он не изменил результат.
• Действительно ли Content-Type: text/plain подходит для прикрепления XML?
• Любые другие предложения?

Answer 1

Указывая text/plain, вы в основном передаете управление способностям обработки текста удаленного клиента, которые, по-видимому, ограничены в данном конкретном случае. XML - это Unicode по спецификации, поэтому, выбрав лучший тип контента, вы, скорее всего, добьетесь успеха. Попробуйте text/xml или application/xml вместо этого, или даже полностью непрозрачный application/octet-stream, который должен только позволяет получателю сохранять его на диске в байт-байт-идентичной форме.

Кодирование передачи содержимого не должно влиять на это поведение вообще, но, поскольку вы, по-видимому, неясны в его значении, вот краткое обсуждение.

Кодирование передачи содержимого полностью прозрачно; это не повлияет на то, что поставлено или что удаленный клиент может с этим сделать. Какая кодировка передачи контента на выбор зависит от характера ваших данных и возможностей системы электронной почты, которую она должна транспортировать. Если он не является 8-битным, вам нужно 7-битное CTE для его инкапсуляции. Если у содержимого есть строки, которые слишком длинны, чтобы вписаться в SMTP, его необходимо инкапсулировать в нечто более короткое. Но удаленный клиент будет извлекать все, что находится внутри инкапсуляции на другом конце. Используйте любые обстоятельства, которые диктуют.

Существует иерархия контента кодировок передачи при различных обстоятельствах:

• 7bit подходит, если ваши данные полностью 7-битный ASCII и имеет никакие линии больше, чем примерно 990 символов. Затем он может пережить даже грубый старый SMTP-перенос без изменений.В отсутствие какого-либо явного заголовка Content-Transfer-Encoding: это стандартное значение по стандарту (хотя вы часто видите материал с 8-битными данными в нем без явного CTE или даже с явным объявлением 7bit).

• 8bit ослабляет требование, чтобы данные были 7-битными. Если все системы, которые переносят это сообщение, поддерживают расширение ESMTP 8BITMIME, это должно быть хорошо для данных с ограниченной длиной строки.

• binary дополнительно допускает неограниченную длину линии. Теоретически вы должны использовать это, чтобы проходить через неограниченный контент, но на практике это, похоже, вызывает сбои, когда системы не строго придерживаются спецификаций. Типичным симптомом является то, что перекрывающиеся линии усекаются или складываются в пути, нарушая целостность полезной нагрузки. Чтобы избежать подобных проблем (и чтобы лучше придерживаться буквы и духа стандартов совместимости), вам лучше с одним из следующих.

• base64 принимает неограниченный контент, но кодирует его в формате, который отвечает строгим требованиям для ограниченной длины строки и строго ограниченного 7-битного репертуара символов. Он расширяет полезную нагрузку до чуть более 4/3 от исходного размера. Пример:

ugqcA7R5cPq667vNaSifRUH9HsW00NqZ1gwICk0pNrUkXFpNIFOpbf3o 
    5ml8cqqSygkp8KBgPbHrqnDXvZTEBOkNo7ThE+BAvexa75Tm0Ebo/Yjl 
    y697pMp1+dnSlk3YTqxkPI9vqpple13dXLHlvnFDmSi0gqIMSwo7kUFD 
    SivAWhyCBR6tFO3lY1Pk6lz78+zgL28VthI72kVRkrWWtzoFef/4u5Ip 
    GR00CtsNNEJo01GAQGpkTNFT9U9Q/UI9CMGgaI9E9RkMaTDTQICBEyaE 
    woSCQOrNGA== 

• quoted-printable аналогично принимает произвольное содержимое, но кодирует выбранный байт 3x оригинал. Когда большая часть ввода ASCII, это допустимое количество накладных расходов. Другими словами, это подходит для грубого текстового формата со случайным не-ASCII-контентом, таким как текст во многих западных языках с использованием 8-битной кодировки или форматов, таких как HTML, где разметка ASCII доминирует над фактическим контентом, в значительной степени любой язык. Пример:

<?xml version=3D"1.0" encoding=3D"UTF-8"?>h=C3=ABll=C3=B6 = 
    w=C3=B6rld 

Цитируется печати не сложно реализовать на всех, и казалось бы подходящим для вашего сценария.

Все это кодифицировано в MIME RFC 2045 - 2048. Википедия имеет хорошие читаемые статьи, например. base64 и quoted-printable.

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