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

Question

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

53

我的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" alt="example logo" /></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--

- Vincent

您发送电子邮件时使用的头部信息（MIME类型）是什么？ - Matt Ball

2

Gmail允许您通过转到电子邮件，单击电子邮件右侧回复文本旁边的向下箭头，并选择“显示原始数据”来查看实际的电子邮件数据包。如果您在代码块中发布此测试，则可能非常有用。 - Jared Farrish

MIME边界失败了吗？按照Jared的指示操作。 - Shad

我已经更新了我的原始帖子，并附上了Gmail的“显示原始邮件”结果。 - Vincent

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Abbafei · Accepted Answer

尝试交换消息部分的顺序，将HTML部分放在纯文本部分之后。这样或许会起作用：)。

注意：我现在记不清我在哪里读到这个（或者我是否真的读到了），但是交换顺序可能有助于解决问题，因为我认为偏好的消息部分可能是最后一部分。

更新：我找到了一个地方，说多部分MIME消息中的部分应按照递增偏好的顺序排列--此处，在第7.2.3节（编辑：最新版本此处；感谢@ALEXintlsos！），从倒数第三段开始。

更新：以下是第7.2.3节的引用（请参见https://stackoverflow.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.