我们正在发送一封包含HTML格式邮件正文的自动电子邮件，我们正在接收两次电子邮件内容。有了这个标题
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_NextPart_000_00F5_01D2C509.C9598370"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdLE260N6ZrXujJMTE6odOelzNRIhw==
Content-Language: en-us
This is a multipart message in MIME format.
------=_NextPart_000_00F5_01D2C509.C9598370
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit
然后使用此标题
------=_NextPart_000_00F5_01D2C509.C9598370
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
还尝试让html中的Content-Transfer-Encoding标头具有其中一个值"BASE64" / "QUOTED-PRINTABLE" / "8BIT" / "7BIT" / "BINARY" / "x-token"。
但是在收到的邮件中仍然有相同的MIME标题
首先，Content-Transfer-Encoding是一个HTML标题？如果是，将此标头的值更改为正确的值将解决此问题吗？
答案 0 :(得分：2)
内容传输 - 编码HTML标头吗？
不，它与HTML无关，或者与“仅HTML”无关。 “Content-Transfer-Encoding”是 MIME的特定内容的标题（也可能是HTML内容），表示添加到MIME时对此内容的编码转移此内容。我知道这听起来有点奇怪，内容，内容和内容，但可能这个资源可以帮助您更好地理解：Content-Transfer-Encoding Header Field。 Content-Transfer-Encoding旨在指定一种数据类型的“本机”表示与可以使用7位邮件传输协议轻松交换的表示之间的可逆映射。但是足够的理论，让我们做一些现实世界的例子......
使用HTML格式的Outlook撰写邮件。当邮件将离开Exchange环境（发送出去）时，它将转换为MIME以通过Internet传输。此时，您的HTML将使用适当的编码，对于此HTML的内容，类型和Content-Transfer-Encoding标头将添加到此内容中，因此此消息的收件人能够通过解码将此内容转换回原始HTML内容。我现在希望这个清楚。
我们正在发送一封自动电子邮件，其中包含HTML格式的邮件正文，我们正在接收邮件内容两次
根据rfc2046对于多用途Internet邮件扩展（MIME），在将邮件转换为MIME时创建了同一正文的替代子类型（您的HTML内容），并添加了appropreate标头以指示“{{ 1}}”。每个身体部位是相同信息的“替代”版本。这意味着您拥有“Content-Type: multipart/alternative;”内容，这些内容不代表您将HTML版本剥离为裸文本。此内容是HTML的替代内容，并且具有基于内容的自己的text/plain标头。此内容可能由无法呈现HTML的收件人使用。