Question

我正尝试使用conflictedblocks_string来发送电子邮件，字符串>>>>>>>可以打印得很好，但是当作为电子邮件发送时却被弄乱了，谁能解释为什么和如何解决它？

conflictedblocks_string = ''
conflictedblocks = {'README': '<<<<<<< HEAD\nTBD1\n=======\nTRP1\n>>>>>>> b9bde66...\n', 'DO_NOT_READ': 'Probably a new file'}
for key,value in conflictedblocks.items():
    conflictedblocks_string += key + ":" + "\n" + value + "\n"
print conflictedblocks_string   --> `>>>>>>>` prints fine
sendemail(conflictedblocks_string ) --> `>>>>>>>` messed up while sending email

sendemail api代码段：

body = '''%s''' % (data)
msg = MIMEText(body)
mail = smtplib.SMTP('company.apple.com', 25)
mail.sendmail(sender, receivers, msg.as_string())

当前输出：-

预期的输出：-

README:
<<<<<<< HEAD
TBD1
=======
TRP1
>>>>>>> b9bde66... 

DO_NOT_READ:
Probably a new file

Answer 1

您的代码完全没有错。或邮件服务器。电子邮件中的>>>>>>>符合您的预期。

但是，许多邮件程序和网络邮件系统在格式化邮件以供查看时，将行首的>转换为缩进标记。

传统上，在行首的>是标记行内引用某人的方式。因此，为了使电子邮件线程更早阅读，邮件客户端将这些引号转换为看起来更像引号的内容。

例如，这是传统的纯文本电子邮件：

John shouted:
> My father said:
>> No! You will BE KILL BY DEMONS
> No! I must kill the demons

The radio said:
> No, John, You are the demons.

And then John was a zombie.

电子邮件客户端可能会这样呈现：

约翰大喊：


我父亲说：


不！您将被恶魔杀死       没有！我必须杀死恶魔


收音机说：


不，约翰，你是魔鬼。


然后约翰是一个僵尸。

没有适用于每个客户的通用解决方法，因为每个客户都有自己的启发式代码，这些代码使事情变得混乱。但是，有些事情经常起作用。

首先，如果您同时发送HTML和纯文本版本的邮件，则大多数将>视为格式的高级客户端将显示HTML，而您可以随意设置格式，而拒绝显示HTML的客户端可能也不会尝试使用>做任何事情。

另一个选择是将要包含的差异作为附件而不是正文。您可以尝试将其标记为嵌入式附件，希望某些客户端在不让用户单击附件并打开的情况下显示该附件，但我认为没有太多的客户喜欢嵌入式纯文本附件。

通常在行前加空格，如下所示：

<<<<<<< HEAD
TBD1
=======
TRP1
 >>>>>>> b9bde66

但是，当然，阅读邮件的人将必须了解额外的空间-如果他们正在复制和粘贴，他们将必须记住将其删除。

如果这行得通，则在电子邮件中的每一行（或仅在差异文件中的每一行加上前缀）也可以起作用。它看上去并不那么丑陋，但如果有的话，它会引起更多的复制粘贴头痛。

Answer 2

它与Python无关，与邮件发送无关...

从历史上看，当邮件只是纯ASCII文本时，>字符（作为惯例）用于响应来自原始邮件的标记引用。

有了HTML和更丰富的字符集，引文现在用竖线|和不同的颜色表示。

为了提供更好的用户体验，邮件阅读器会以纯文本邮件形式解释>字符并将其格式化为现代引文标记。

所以：

您的邮件已正确发送，并包含正确的>
罪魁祸首是您的邮件阅读器，（错误地在此处）在正文行中将开头的>格式化为引文

发送电子邮件时字符串“ >>>>>>>”弄乱了

2 个答案: