前段时间，我在Python上编写了一个处理电子邮件的程序，总有一件事就是知道电子邮件是否是“多部分”。
经过一番研究后，我知道它与包含HTML或附件等的电子邮件有关......但我并不是真的理解它。
1。当我必须从原始电子邮件中保存附件时
我刚刚在互联网上发现了这一点（可能在这里 - 很抱歉没有记下编写它的人，但我似乎无法再找到他了：/）并将其粘贴在我的代码中
def downloadAttachments(emailMsg, pathToSaveFile):
"""
Save Attachments to pathToSaveFile (Example: pathToSaveFile = "C:\\Program Files\\")
"""
att_path_list = []
for part in emailMsg.walk():
# multipart are just containers, so we skip them
if part.get_content_maintype() == 'multipart':
continue
# is this part an attachment ?
if part.get('Content-Disposition') is None:
continue
filename = part.get_filename()
att_path = os.path.join(pathToSaveFile, filename)
#Check if its already there
if not os.path.isfile(att_path) :
# finally write the stuff
fp = open(att_path, 'wb')
fp.write(part.get_payload(decode=True))
fp.close()
att_path_list.append(att_path)
return att_path_list
2。当我必须从原始电子邮件中获取文本时
也是从互联网上的某人那里粘贴而没有真正理解它是如何运作的。
def get_text(emailMsg):
"""
Output: body of the email (text content)
"""
if emailMsg.is_multipart():
return get_text(emailMsg.get_payload(0))
else:
return emailMsg.get_payload(None, True)
如果电子邮件消息是多部分的，则可以迭代部分。
完全这些部分是什么？你怎么知道哪个是html例如？或者哪一个是附件？还是只是身体？
答案 0 :(得分：5)
对于如何使用多部分消息没有严格的层次结构或指导。 MIME只是定义了将多个有效负载收集到单个电子邮件中的方法。我认为最初的动机之一是能够将图片嵌入文本中;但是能够将二进制文件附加到文本消息中，更一般地说，能够创建具有以任意方式相关的有效负载的结构化消息，这些应用程序只需要以他们认为合适的方式使用。
一个常见的误解是将层次结构假定为“主要部分”和“从属”部分。创建这种结构当然是可能的，但绝不是普遍的。事实上，大多数多部分消息只有一系列没有任何层次结构的部分。用户的电子邮件客户端通常会选择其中一个“内联”部分作为首选“主要”部分显示在消息窗格中，但这绝不是由标准规定，或者可能由发送方强制执行。
每个MIME部分都有一组标题，告诉你类型，编码和处理;对于text/*类型的部分，默认处置是“内联”（因此通常没有明确说明），而大多数其他部分都有默认的“附件”配置。您需要参考相关标准以获得严格的定义，但可能需要花费很多时间，因为许多实际应用程序并不特别符合RFC。
对于您的具体问题，找到最内部（隐式或显式）内联的叶子部分，并显示一个支持您的用例作为“主”的叶子部分。如果要将HTML强制为首选格式，则可以执行此操作;但许多电子邮件应用程序将此推迟给用户决定，一些用户肯定 - 由于技术需要，身体残疾或个人品味 - 在可用时更喜欢纯文本。
不幸的是，消息制作者最近的常见做法是创建一个multipart/alternative容器，其中包含text/plain和text/html成员，但随后会提供完全无用的text/plain部分并且text/html部分中的所有实际内容。在这种情况下，正确的安排是，如果你不能在其中放置任何有用的东西，就根本不提供text/plain部分（但我想他们只关心过去一些误入歧途的垃圾邮件过滤器，而不是关于实际适应偏好收件人）。
答案 1 :(得分：0)
您正在寻找的答案都在MIME标准中，尤其是：
这些标准共同将电子邮件从明文，仅限英语的状态转换为目前的状态，我们可以通过有趣的方式发送Unicode便便，使用可爱的小猫进行专业的位图，以及针对不符合标准的软件和中间盒的数十种方式以微妙和非微妙的方式破坏消息的途径。有关这些功能的更多详细信息，请参阅：
对于问题的IMAP特定部分，即如何通过IMAP最佳地访问这些部分的MIME树，请参阅RFC3501，尤其是谈论BODY和{{1}的章节} constructs。
如果您想要了解MIME的美妙之处，请查看“MIME酷刑测试”。找到它有点棘手，因为this random item on github绝对不是我的意思。以下是创建IMAP的工程师Mark Crispin的原创作品：
是的，这是很多阅读。不幸的是，您确实需要理解以上所有内容才能正确安全地处理MIME。请不要跳过这些资源和标准，除非您想要创建诸如随机批量邮件程序之类的可憎行为，这些邮件一直将UTF-8中的非ASCII代码点分成几个相邻的MIME编码块，等等。谢谢。