介绍

背景

我正在编写一个脚本来使用 RFC 2388 中定义的 multipart/form-data 内容类型上传包括文件在内的内容。 .从长远来看，我试图提供一个简单的 Python 脚本来执行 uploads of binary packages for github ，这涉及将类似表单的数据发送到 Amazon S3。

相关

This question已经问过如何做到这一点，但到目前为止还没有一个可以接受的答案，the more useful目前有两个答案指向 these recipes依次手动构建整个消息。我有点担心这种方法，尤其是在字符集和二进制内容方面。

还有this question , 及其 currently highest-scoring answer建议 MultipartPostHandler模块。但这与我提到的食谱没有太大区别，因此我的担忧也适用于此。

关注点

二进制内容

RFC 2388 Section 4.3明确指出内容应为 7 位，除非另有声明，因此 Content-Transfer-Encoding header可能需要。这是否意味着我必须对二进制文件内容进行 Base64 编码？或者 Content-Transfer-Encoding: 8bit 是否足以用于任意文件？或者应该读作 Content-Transfer-Encoding: binary？

标题字段的字符集

一般的标题字段，特别是 filename 标题字段，默认情况下仅为 ASCII。我希望我的方法也能够传递非 ASCII 文件名。我知道对于我当前为 github 上传内容的应用程序，我可能不需要它，因为文件名在单独的字段中给出。但我希望我的代码可以重用，所以我宁愿以一种一致的方式对文件名参数进行编码。 RFC 2388 Section 4.4建议在 RFC 2231 中引入的格式，例如filename*=utf-8''t%C3%A4st.txt.

我的方法

使用 python 库

由于 multipart/form-data 本质上是一种 MIME 类型，我认为应该可以使用 email package从标准 python 库来撰写我的帖子。特别是对非 ASCII header 字段的相当复杂的处理是我想委托(delegate)的事情。

到目前为止的工作

所以我写了下面的代码:

#!/usr/bin/python3.2

import email.charset
import email.generator
import email.header
import email.mime.application
import email.mime.multipart
import email.mime.text
import io
import sys

class FormData(email.mime.multipart.MIMEMultipart):

    def __init__(self):
        email.mime.multipart.MIMEMultipart.__init__(self, 'form-data')

    def setText(self, name, value):
        part = email.mime.text.MIMEText(value, _charset='utf-8')
        part.add_header('Content-Disposition', 'form-data', name=name)
        self.attach(part)
        return part

    def setFile(self, name, value, filename, mimetype=None):
        part = email.mime.application.MIMEApplication(value)
        part.add_header('Content-Disposition', 'form-data',
                        name=name, filename=filename)
        if mimetype is not None:
            part.set_type(mimetype)
        self.attach(part)
        return part

    def http_body(self):
        b = io.BytesIO()
        gen = email.generator.BytesGenerator(b, False, 0)
        gen.flatten(self, False, '\r\n')
        b.write(b'\r\n')
        b = b.getvalue()
        pos = b.find(b'\r\n\r\n')
        assert pos >= 0
        return b[pos + 4:]

fd = FormData()
fd.setText('foo', 'bar')
fd.setText('täst', 'Täst')
fd.setFile('file', b'abcdef'*50, 'Täst.txt')
sys.stdout.buffer.write(fd.http_body())

结果是这样的:

--===============6469538197104697019==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: form-data; name="foo"

YmFy

--===============6469538197104697019==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: form-data; name*=utf-8''t%C3%A4st

VMOkc3Q=

--===============6469538197104697019==
Content-Type: application/octet-stream
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: form-data; name="file"; filename*=utf-8''T%C3%A4st.txt

YWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJj
ZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVm
YWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJj
ZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVm
YWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJjZGVmYWJj
ZGVmYWJjZGVmYWJjZGVm

--===============6469538197104697019==--

它似乎确实可以很好地处理 header 。二进制文件内容将得到 base64 编码，这可能是可以避免的，但应该工作得很好。让我担心的是中间的文本字段。它们也是 base64 编码的。我认为根据标准，这应该工作得很好，但我宁愿在那里有纯文本，以防某些愚蠢的框架必须在中间级别处理数据并且不知道 Base64 编码数据。

问题

• 我可以在我的文本字段中使用 8 位数据并仍然符合规范吗？
• 我可以获得电子邮件包以将我的文本字段序列化为 8 位数据而无需额外编码吗？
• 如果我必须坚持使用某种 7 位编码，我能否让实现对那些编码短于 base64 的文本部分使用引用可打印？
• 我是否也可以避免对二进制文件内容进行 base64 编码？
• 如果可以避免，我应该将 Content-Transfer-Encoding 写成 8bit 还是 binary？
• 如果我必须自己序列化正文，我怎么能使用 email.header package单独格式化 header 值？(email.utils.encode_rfc2231 这样做。)
• 是否有一些实现已经完成了我想做的所有事情？

这些问题密切相关，可以概括为“您将如何实现”。在许多情况下，回答一个问题要么回答另一个问题，要么使另一个问题过时。因此，我希望您同意将所有这些都发布在一个帖子中是合适的。

最佳答案

这是一个占位符答案，描述了我在等待对我的一些问题的权威输入时所做的事情。如果证明这种方法在至少一个设计决策中是错误的或不合适的，我将很乐意接受不同的答案。

Here是我现在根据自己的喜好来完成这项工作的代码。 我做出了以下决定:

Can I use 8 bit data for my text fields and still conform to the specification?

我决定这样做。至少对于这个应用程序，它确实有效。

Can I get the email package to serialize my text fields as 8 bit data without extra encoding?

我找不到办法，所以我正在做我自己的序列化，就像所有 other recipes我看到了。

Can I avoid base64 encoding for binary file content as well?

简单地以二进制形式发送文件内容似乎效果很好，至少在我的单个应用程序中是这样。

If I can avoid it, should I write the Content-Transfer-Encoding as 8bit or as binary?

作为RFC 2045 Section 2.8指出，8bit 数据受 CRLF 对之间 998 个八位字节的行长度限制，我认为 binary 更通用，因此这里的描述更合适。

If I had to serialize the body myself, how could I use the email.header package on its own to just format header values?

正如我的问题中已经编辑的那样，email.utils.encode_rfc2231对此非常有用。我首先尝试使用 ascii 编码，但在双引号字符串中禁止使用非 ascii 数据或 ascii 字符的情况下使用该方法。

Is there some implementation that already did all I'm trying to do?

据我所知不是。邀请其他实现采用来自 my code 的想法, 不过。

编辑:

感谢this comment我现在知道对 header 使用 RFC 2231 并未得到普遍接受:HTML 5 的当前草案 forbids its use .也有人看过cause problems in the wild .但是由于 POST header 并不总是对应于特定的 HTML 文档(例如考虑 Web API)，我不确定在这方面我是否会信任该草案。也许正确的做法是同时提供编码和未编码的名称，即 RFC 5987 Section 4.2建议。但该 RFC 用于 HTTP header ，而 multipart/form-data header 在技术上是 HTTP 主体。因此，该 RFC 不适用，而且我不知道有任何 RFC 会明确允许(甚至鼓励)对 multipart/form-data 同时使用这两种形式。

关于python - 正确格式化多部分/表单数据主体，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13514713/