GMail 显示纯文本电子邮件而不是 HTML

Posted 2023-02-24

技术标签:

【中文标题】GMail 显示纯文本电子邮件而不是 HTML【英文标题】：GMail displays plain text email instead HTML 【发布时间】：2011-07-08 11:58:13 【问题描述】：

我的 Rails 3 应用程序以纯文本和 html 格式发送电子邮件。我已经使用 RoundCube 和 Squirrel Mail 客户端在本地对其进行了测试，它们都显示带有图像、链接等的 HTML 版本。另一方面，GMail 选择纯文本格式。知道是什么原因造成的吗？

Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of info@example.com) client-ip=69.123.123.123;
Date: Fri, 04 Mar 2011 01:01:45 +0000
From: info@example.com
To: test@gmail.com
Message-ID: <4d7039f9e9d3e_3449482ab7831658@test.mail>
Subject: Your example account was activated.
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_4d7039f9e6967_3449482ab7831370";
 charset=UTF-8
Content-Transfer-Encoding: 7bit

----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e95ed_3449482ab7831519@test.mail>

<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type" />
  </head>
  <body>
    <p><a href="http://example.com/"><img border="0" src="http://example.com/images/logo.png"  /></a></p>
    <p>Congratulations, Test!</p>
    <p>
      Your <a style="text-decoration:none;color:#ef4923;" href="http://example.com/">example</a> account was activated.
    </p>
  </body>
</html>

----==_mimepart_4d7039f9e6967_3449482ab7831370
Date: Fri, 04 Mar 2011 01:01:45 +0000
Mime-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-ID: <4d7039f9e8b0e_3449482ab78314b7@test.mail>

Congratulations, Test!

Your example.com account was activated.

----==_mimepart_4d7039f9e6967_3449482ab7831370--

【问题讨论】：

您使用什么标题（MIME 类型）发送电子邮件？ Gmail 允许您查看实际的电子邮件数据包数据，方法是转到电子邮件，单击电子邮件右侧回复文本旁边的向下箭头，然后选择“显示原始”。如果您在代码块中发布对此的测试，这可能会非常非常有帮助 MIME 边界可能失败？按照贾里德的指示。我用 Gmail 的“显示原始”结果更新了我的原始帖子 【参考方案1】：

尝试切换消息部分的顺序，将 HTML 部分放在纯文本部分之后。它可能会起作用:)。

注意：我现在不记得我在哪里读到这篇文章了（或者我什至可以肯定确实），但切换可能有帮助的原因是因为我认为消息的首选部分可能是最后一部分。

更新：我发现了一个地方，它说多部分 MIME 消息中的部分应该按优先级递增的顺序排列——here，在第 7.2.3 节中（编辑：最新版本 @ 987654322@；谢谢@ALEXintlsos!)，从倒数第三段开始。

更新：这是第 7.2.3 节的引述，（见https://***.com/help/referencing）：

7.2.3 The Multipart/alternative subtype
The multipart/alternative type is syntactically identical to multipart/mixed, 
but the semantics are different. In particular, each of the parts is an
"alternative" version of the same information. User agents should recognize
that the content of the various parts are interchangeable. The user agent
should either choose the "best" type based on the user's environment and
preferences, or offer the user the available alternatives. In general, choosing
the best type means displaying only the LAST part that can be displayed. This
may be used, for example, to send mail in a fancy text format in such a way
that it can easily be displayed anywhere:

From:  Nathaniel Borenstein <nsb@bellcore.com> 
To: Ned Freed <ned@innosoft.com> 
Subject: Formatted text mail 
MIME-Version: 1.0 
Content-Type: multipart/alternative; boundary=boundary42 


--boundary42 
Content-Type: text/plain; charset=us-ascii 

...plain text version of message goes here.... 

--boundary42 
Content-Type: text/richtext 

.... richtext version of same message goes here ... 
--boundary42 
Content-Type: text/x-whatever 

.... fanciest formatted version of same  message  goes  here 
... 
--boundary42-- 

In this example, users whose mail system understood the "text/x-whatever"
format would see only the fancy version, while other users would see only the
richtext or plain text version, depending on the capabilities of their system.

In general, user agents that compose multipart/alternative entities should
place the body parts in increasing order of preference, that is, with the
preferred format last. For fancy text, the sending user agent should put the
plainest format first and the richest format last. Receiving user agents should
pick and display the last format they are capable of displaying. In the case
where one of the alternatives is itself of type "multipart" and contains
unrecognized sub-parts, the user agent may choose either to show that 
alternative, an earlier alternative, or both.

NOTE: From an implementor's perspective, it might seem more sensible to reverse
this ordering, and have the plainest alternative last. However, placing the
plainest alternative first is the friendliest possible option when
multipart/alternative entities are viewed using a non-MIME- compliant mail
reader. While this approach does impose some burden on compliant mail readers,
interoperability with older mail readers was deemed to be more important in
this case.

It may be the case that some user agents, if they can recognize more than one
of the formats, will prefer to offer the user the choice of which format to
view. This makes sense, for example, if mail includes both a nicely-formatted
image version and an easily-edited text version. What is most critical, however,
is that the user not automatically be shown multiple versions of the same data.
Either the user should be shown the last recognized version or should 
explicitly be given the choice.

【讨论】：

哇，我很震惊这实际上是问题和解决方案。谢谢阿巴飞！如何控制零件的顺序？很棒的发现，阿巴菲。为了完整起见，我注意到您链接中的 RFC 1341 已被 RFC 1521 废弃；但是 1521 第 7.2.3 节也证实了您的发现：“与 multipart/mixed 一样，身体部位的顺序很重要。在这种情况下，替代品的出现顺序是对原始内容的忠诚度增加。一般来说，最好的选择是接收系统本地环境支持的类型的最后一部分。” ...当然，RFC 1521 已被 RFC 2046 淘汰，但第 5.1.4 节中的文本是相同的。我有同样的问题，我更希望看到 text/html 但 Gmail 向我显示 text/plain；不过，就我而言， text/html 出现在 text/plain 之前；在问题中也是如此

以上是关于GMail 显示纯文本电子邮件而不是 HTML的主要内容，如果未能解决你的问题，请参考以下文章

通过 Gmail API 发送带有纯文本回退的 HTML 电子邮件

通过 SMTP 发送带有附件、纯文本/文本和文本/html 的电子邮件

如何发送带有 HTML 标签的电子邮件，而不是 C# 中的 HTML 纯文本

发送文本和 HTML 电子邮件 - 为啥 Gmail 总是选择文本版本？

CakePHP / 通用 HTML 电子邮件

Gmail 显示电子邮件的 HTML 和文本以及 HTML 部分