4

我有一个发送电子邮件的应用程序，几个月来，它运行良好。我最近遇到了utf-8发送到 iPhone 的编码电子邮件问题Exchange account（即不是IMAP）。
接收者只需要看到一大堆无意义的字符，例如LS0tLS0tPV9QYXJ0XzE0N18[....].

将我的电子邮件标题与 Gmail 进行比较，我注意到我有一个额外Content-Transfer-Encoding的与Content-Type: multipart/alternative;.
我的电子邮件看起来像

Delivered-To: ...
Received: ...
...
MIME-Version: ...
Content-Type: multipart/alternative; 
    boundary="----=_boundary" 
Content-Transfer-Encoding: Base64  # <= the extra setting

----=_boundary
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: Base64

YmVu0Cg==

----=_boundary
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: Base64

PGh0bWwgeG1sbnM6bz0iIj48aGVhZD48dGl0bGU+PC90aXRsZT48L2hlYWQ+PGJvZHk+YmVub2l0
PC9ib2R5PjwvaHRtbD4NCjx9IjAiIC8+Cg==

----=_boundary

如果我删除额外的设置，我的电子邮件会被接收并正确显示。

我的问题：

  1. 即使对于特定情况，Encoding基本上也需要设置？Content-Type: multipart/alternative;
  2. 删除它并像以前一样继续使用我的应用程序是否安全？

编辑 我发现IETF：

编码注意事项：多部分内容类型不能有编码。

但我也发现Wikipedia：

多部分类型的内容传输编码必须始终为“7 位”、“8 位”或“二进制”，以避免多级解码带来的复杂性。

是不是很矛盾？

4

2 回答 2

8

IETF 和维基百科的陈述并不矛盾。7bit, 8bit, 或者binary不是真正的内容编码，因为它们没有指定内容的任何转换。他们只是声明内容尚未编码。在这种情况下，7bit它还指定不需要对内容进行编码，即使消息需要通过非 8 位干净的传输方式发送也是如此。

只有最底层的消息应该有一个实际的Content-Transfer-Encoding，例如base64or quoted-printable。在您从外部引用的消息中肯定不是 base64 编码的，因此声明它不仅违反标准而且不正确。这肯定会导致显示该消息的问题。

于 2012-11-28T07:59:57.070 回答
5

实际上，multipart 的每个部分都有自己的编码，为 multipart 容器声明一个是没有意义的。无论如何，我无法理解维基百科的引用；无论如何，它几乎没有权威性。

于 2012-11-28T07:44:54.890 回答