空字节和多部分/表单数据的后果是什么？答案

【问题标题】：What are the ramifications of null bytes and multipart/form-data?空字节和多部分/表单数据的后果是什么？
【发布时间】：2009-12-17 16:45:47
【问题描述】：

第三方向我们发送了一个平面文件，该文件应该包含专有的可打印 ASCII 字符。但是，我们发现文件中间有一个大约 50 个0x00 字节的字符串。

我们希望能够将文件上传到我们的 Web 应用程序，但我发现 Django 似乎不喜欢 multipart/form-data 中的空字符。如果我删除空字符，则上传成功。（抱歉，我目前没有可用的堆栈跟踪，但如有必要会生成一个）

我们可以预处理文件以删除空字符和/或与我们的第三方合作修复他们的文件生成器，但我不喜欢留下这样的神秘问题。

这听起来像是 Django 中的错误，还是我不完全理解的 multipart/form-data 的某些方面？我是否需要设置某种传输编码，以便 Django 不会挂断空字符？

【问题讨论】：

【解决方案1】：

不，表单数据不需要（或浏览器曾经使用过）传输编码。在 multipart/form-data 值中包含 50 个空字节的运行是完全有效的……事实上，鉴于大多数二进制文件包含很多空值，这种情况应该经常出现，而不是文件上传！

这让我怀疑这是否真的是一个 Django 错误，或者是否没有其他问题。让我们拥有那个堆栈跟踪！

【讨论】：

不正确。有一个“Content-Transfer-Encoding”标头可用，即：“Content-Transfer-Encoding: binary”。或者使用“Content-Type: application/octet-stream”发送任意数据，无需解释。
Content-Transfer-Encoding 在 HTTP 中是不允许的，请参阅 RFC2616 19.4.5。编码始终为binary 或有效的同义词。
@bobince：CTE 对整个 HTTP 传输的全局头无效。但是，根据RFC 2388 Section 4.3，它对multipart/form-data 完全有效。按照我阅读规范的方式，您应该为每个非 ASCII 部分包含 Content-Transfer-Encoding: binary，即使许多实际实现不满足该要求。
RFC7578 sec 4.7 (2015) 提到“以前，建议发件人对 multipart/form-data 正文的每个非 ASCII 部分使用 Content-Transfer-Encoding 编码（例如 quoted-printable），因为将允许在仅支持 7bit 编码的传输中使用。不推荐在支持二进制数据（如 HTTP）的上下文中使用此用法。发件人不应生成任何带有 Content-Transfer-Encoding 标头字段的部分。 // 目前，未部署已发现发送此类主体的实现。”