2 回答
这是一个占位符答案，描述了我在等待对我的一些问题的权威输入时所做的事情。如果它表明这种方法在至少一个设计决策中是错误的或不适合的，我将很乐意接受不同的答案。
这是我用来根据我现在的口味进行这项工作的代码。我做了以下决定：
我可以为我的文本字段使用 8 位数据并且仍然符合规范吗？
我决定这样做。至少对于这个应用程序，它确实有效。
我可以让电子邮件包将我的文本字段序列化为 8 位数据而无需额外编码吗？
我没有找到办法，所以我正在做自己的序列化，就像我在这上面看到的所有其他食谱一样。
我也可以避免对二进制文件内容进行 base64 编码吗？
至少在我的单个应用程序中，只需以二进制形式发送文件内容似乎就足够了。
如果可以避免，我应该将 Content-Transfer-Encoding 编写为 8 位还是二进制？
正如RFC 2045 第 2.8 节所述，该8bit数据受到 CRLF 对之间的 998 个八位字节的行长限制，我认为这binary是更通用的，因此这里的描述更合适。
如果我必须自己序列化正文，我怎么能单独使用 email.header 包来格式化标题值？
正如已经在我的问题中编辑的那样，email.utils.encode_rfc2231对此非常有用。我首先尝试使用 ascii 进行编码，但在非 ascii 数据或双引号字符串中禁止使用的 ascii 字符的情况下使用该方法。
是否有一些实现已经完成了我想做的所有事情？
不是我知道的。不过，请其他实现采用我的代码中的想法。
编辑：
多亏了这条评论，我现在知道将 RFC 2231 用于标头并未被普遍接受：当前的 HTML 5 草案禁止使用. 它也被认为会在野外引起问题。但是由于 POST 标头并不总是对应于特定的 HTML 文档（例如考虑 Web API），我也不确定在这方面我是否会信任该草案。也许正确的方法是同时给出编码和未编码的名称，就像RFC 5987 第 4.2 节所建议的那样。但是该 RFC 是针对 HTTP 标头的，而 multipart/form-data 标头在技术上是 HTTP 正文。因此，该 RFC 不适用，而且我不知道有任何 RFC 明确允许（甚至鼓励）同时对多部分/表单数据使用两种形式。
您可能想从一个 Python 脚本问题中查看使用 POST 发送文件，该问题指向Requests库，该库正在成为 http 最常用的 Python 库。如果您在那里找不到所有需要的功能并决定自己实现它，我鼓励您将它贡献给这个项目。