7

我正在用 python 编写一个简单的网络服务器，它允许用户使用 multipart/form-data 上传文件。据我所知，多部分 MIME 数据应该是基于行的。例如，边界必须在一行的开头。

我无法弄清楚在这方面如何处理二进制数据。我的客户端（Firefox）没有将其编码为 7 位 ASCII 或任何内容，它只是发送的原始二进制数据。它是否将数据拆分为任意位置的行？是否为多部分数据指定了最大行长度？我尝试通过 RFC 查看 multipart/form-data，但没有找到任何东西。

4

2 回答 2

8

在深入研究了 RFC 之后，我想我终于明白了。正文部分（即消息中单个部分的正文内容multipart/*）只需要基于行，因为部分末尾的边界以a开头CR+LF。但除此之外，数据不必是基于行的，如果内容中恰好有换行符，则它们之间没有最大距离，也不需要转义（好吧，除非可能Content-Transfer-Encoding是引用字符串）。的 7 位、8 位和二进制选项Content-Transfer-Encoding实际上并不表示已对数据进行任何编码（因此无需撤消编码），它们只是表示您的数据类型可以期待在身体部位看到。

我在[表达不佳]问题中真正得到的是如何从套接字读取/缓冲数据，以便我可以确保我抓住了边界，而不必有一个任意大的缓冲区（例如，如果发生了内容中没有换行符，因此readline最终缓冲了整个内容）。

我最终做的是readline使用最大长度从套接字缓冲，所以缓冲区永远不会超过这个长度，但如果遇到换行符，也会确保终止。这确保了当边界到达时（在 a 之后CR+LF），它将位于缓冲区的开头。我不得不做一些额外的工作以确保我没有CR+LF在实际的正文内容中包含该 final，因为根据 RFC，它需要在边界之前，因此不是内容本身的一部分。

于 2013-04-05T12:02:57.367 回答
3

尝试查看RFC 2045。通常，二进制内容由您的应用程序转换为BASE64 ，并使用“Content-Transfer-Encoding : Base64”包含在多部分消息中。还有其他传输二进制数据的机制，但这很常见。二进制数据被转换为八位字节并以任意长度的字符串分块（取决于编码变体 - 请参阅上面的 BASE64 链接）。然后接收应用程序将其解码为原始二进制内容。

我不是 python 程序员，但如果你真的必须自己编写任何代码，我会感到惊讶。我怀疑有预构建的 python 库函数可以为您执行此操作。

于 2013-03-27T17:43:25.690 回答