RFC7578(淘汰了RFC2388)定义了multipart/form-data类型，当用户在Web页面上提交表单时，这种数据类型通常通过HTTP进行传输。如今，它往往被JSON编码的payload(负载)所取代;尽管如此，它仍然被广泛使用。
虽然你可以用Python原生解码使用JSON创建的HTTP主体请求(这多亏了JSON模块)，但是对于multipart/form-data却没有这样的方法。考虑到这种格式的历史悠久，这几乎是难以理解的。
有很多种方法可以对这种格式进行编码和解码。像requests之类的库在不引起你注意的情况下已经原生地支持这种特性，大多数Web服务器框架(比如Django或Flask)也是如此。
然而，在某些情况下，你可能需要自己对这种格式进行编码或解码。在这些情况下，通过添加外部依赖来处理编解码，不是一个可接受的选项（比如嵌入式设备上没有网，无法pip）。
编码
multipart/form-data格式非常容易理解，可以概括为一种编码键和值列表的简单方法，即，一种可移植的序列化字典的方法。
Python中没有任何东西可以生成这样的编码。这种格式非常简单，由键和值组成，并由一个随机的边界分隔符包围。分隔符必须作为 Content-Type的一部分进行传递，以便解码器能够解码表单数据。
urllib3中有完成这项工作的一个简单实现。我们在这个简单的实现中对它总结一下:
你可以通过传递一个字典来使用这种格式，其中键和值都是字节。例如:
它会返回:
你可以在HTTP应答头部Content-Type中使用返回的内容类型。注意，这种格式是用于表单的:它也可以用于电子邮件。
你说的是电子邮件吗?
使用email进行编码
是的，电子邮件通常是使用MIME编码的，MIME由另一个RFC—RFC2046—定义。事实证明，multipart/form-data只是一种特殊的MIME格式，如果你有实现MIME处理的代码，那么使用它来实现这种格式是很容易的。
对我们来说幸运的是，Python标准库附带了一个模块，该模块可以处理它:email.mime。我告诉过你它被电子邮件大量使用—我猜这就是为什么他们会把处理代码放在email子包中。
这里有一段代码，它使用几行代码来处理multipart/form-data :
使用这段代码会返回以下结果：
与我们的第一个实现相比，这个方法有几个优点:
- 它为每个添加的MIME部分处理Content-Type。我们可以添加其他数据类型，而不仅仅是text/plain，就像在第一个版本中显式所做的那样。我们还可以指定文本数据的字符集(编码方式)。
- 通过使用经过广泛测试的Python标准库，它很可能会更加健壮。
在这种情况下，主要的缺点是内容中包含了Content-Type头部。在处理HTTP时，这是有问题的，因为这需要作为HTTP头部的一部分被发送，而不是作为负载的一部分。
从email.generator构建一个完成这一任务的特定的生成器是可能的。我将把它留给你们做练习，读者们。
解码
我们必须能够使用相同的 email 包来解码我们的编码数据，对吗?事实证明是这样的，我们可以通过一段这样的代码来实现:
使用上面的示例数据，这段代码会返回：
超级棒，对吗？
这个故事的寓意是，你永远不要低估标准库的威力。虽然在你的依赖项列表中添加一行代码很容易，但是如果你深入研究一下Python为你提供了什么，你会发现你并不总是需要这样做!
英文原文：https://julien.danjou.info/handling-multipart-form-data-python/
译者：野生大熊猫
注：我这有个学习Python基地，里面有很多学习资料，感兴趣的+Q群：895817687
