GMail顯示純文本電子郵件而不是HTML

我的Rails 3應用程序以純文本格式和HTML格式發送電子郵件。我使用RoundCube和Squirrel Mail客戶端在本地測試了它，並且它們都顯示帶有圖像，鏈接等的HTML版本.GGail則選擇純文本格式。任何想法是什麼造成這個？GMail顯示純文本電子郵件而不是HTML

Received-SPF: neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of [email protected]) client-ip=69.123.123.123; 
Date: Fri, 04 Mar 2011 01:01:45 +0000 
From: [email protected] 
To: [email protected] 
Message-ID: <[email protected]> 
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: <[email protected]> 

<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: <[email protected]> 

Congratulations, Test! 

Your example.com account was activated. 

----==_mimepart_4d7039f9e6967_3449482ab7831370--

來源

2011-03-04 Vincent

什麼頭（MIME類型）你發送電子郵件？ – 2011-03-04 01:16:29

Gmail允許您通過轉至電子郵件，單擊電子郵件右側的回覆文本旁邊的向下箭頭，然後選擇顯示原始郵件來查看實際的電子郵件數據包數據。如果您在代碼塊中發佈此測試，這可能會非常非常有幫助 – 2011-03-04 01:16:45

MIME邊界失敗或許？遵循Jared的inst。 – Shad 2011-03-04 01:18:01

嘗試切換消息部分的順序，將HTML部分放在純文本部分之後。它可能會工作:)。

注意：我現在不記得在那裏我閱讀（或者，如果我可以肯定，即使所做的那樣），但原因切換的可能幫助是因爲我覺得消息的首選部分可能是最後一部分。

更新：我發現一個地方，它說，在一個多部分MIME消息部分應該是遞增的優先順序 - here，在第7.2.3（編輯：！最新版本here;感謝@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 <[email protected]> 
To: Ned Freed <[email protected]> 
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.

來源

2011-03-04 02:06:56 Abbafei

謝謝，它工作正常！ – Vincent 2011-03-04 02:26:54

美麗的作品。 – Avishai 2012-02-13 19:55:23

很好的解釋/引證。 – RustyTheBoyRobot 2012-10-26 20:42:52

GMail顯示純文本電子郵件而不是HTML

回答

相關問題