2011-03-04 22 views
36

मेरा रेल 3 एप्लिकेशन सादा पाठ और HTML प्रारूप दोनों में ईमेल भेजता है। मैंने इसे स्थानीय रूप से RoundCube और Squirrel Mail क्लाइंट का उपयोग करके परीक्षण किया है और वे दोनों छवियों, लिंक इत्यादि के साथ HTML संस्करण प्रदर्शित करते हैं। दूसरी तरफ जीमेल अन्य सादे पाठ प्रारूप चुनता है। कोई विचार यह क्या कर रहा है?जीमेल के बजाय सादा पाठ ईमेल प्रदर्शित करता है HTML

Delivered-To: [email protected] 
Received: by 10.42.166.2 with SMTP id m2cs16081icy; 
     Thu, 3 Mar 2011 17:01:48 -0800 (PST) 
Received: by 10.229.211.138 with SMTP id go10mr1544841qcb.195.1299200507499; 
     Thu, 03 Mar 2011 17:01:47 -0800 (PST) 
Return-Path: <[email protected]> 
Received: from beta.example.com (testtest.test.com [69.123.123.123]) 
     by mx.google.com with ESMTP id j14si1690118qcu.136.2011.03.03.17.01.46; 
     Thu, 03 Mar 2011 17:01:46 -0800 (PST) 
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; 
Authentication-Results: mx.google.com; spf=neutral (google.com: 69.123.123.123 is neither permitted nor denied by best guess record for domain of [email protected]) [email protected] 
Received: from localhost.localdomain (localhost [127.0.0.1]) 
    by beta.example.com (Postfix) with ESMTP id F3C273A3EC 
    for <[email protected]>; Fri, 4 Mar 2011 01:01:45 +0000 (UTC) 
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-- 
+0

क्या हेडर (MIME प्रकार) आप के साथ ईमेल भेज रहे हैं? –

+2

जीमेल आपको ईमेल पर जाकर वास्तविक ईमेल पैकेट डेटा देखने, ईमेल के दाईं ओर उत्तर टेक्स्ट के बगल में नीचे तीर पर क्लिक करने और मूल दिखाएँ चुनने की अनुमति देता है। यदि आप कोड ब्लॉक में इसका परीक्षण पोस्ट करते हैं, तो शायद यह बहुत उपयोगी होगा, बहुत उपयोगी, –

+0

एमआईएम सीमा विफलता शायद? जेरेड के इंस्टेंट का पालन करें। – Shad

उत्तर

79

संदेश के हिस्सों के क्रम को स्विच करने का प्रयास करें, सादे-पाठ भाग के बाद HTML भाग डालें। यह काम हो सकता है :)।

नोट: मैं अब याद नहीं कर सकते हैं, जहां मैं इस (या अगर मुझे यकीन है कि के लिए भी किया) पढ़ते हैं, लेकिन कारण स्विचिंग मदद कर सकता है, क्योंकि मुझे लगता है कि संदेश की पसंदीदा हिस्सा आखिरी हिस्सा हो सकता है।

अद्यतन: मैं एक जगह है जहाँ यह कहते हैं कि एक बहुखण्डीय माइम संदेश में भागों बढ़ती वरीयता के क्रम में होना चाहिए पाया - 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. 
+0

धन्यवाद, यह काम किया! – Vincent

+0

खूबसूरती से काम करता है। – Avishai

+0

ग्रेट स्पष्टीकरण/उद्धरण। – RustyTheBoyRobot

संबंधित मुद्दे