在深入了解RFC之后，我想我终于彻底解决了这个问题 . 身体部位（即， multipart/* 消息中各个部分的身体内容）只需要基于行，因为部分末端的边界以 CR+LF 开头 . 但除此之外，数据不一定是基于行的，如果内容中恰好有换行符，它们之间没有最大距离，也不需要进行转义（好吧，除非引用 Content-Transfer-Encoding ）串） . Content-Transfer-Encoding don 't actually indicate that any encoding has been done on the data (and therefore no encoding needs to be undone), they'的7位，8位和二进制选项只是表示您可以在正文部分中看到的数据类型 .
2 回答
在深入了解RFC之后，我想我终于彻底解决了这个问题 . 身体部位（即，
multipart/*消息中各个部分的身体内容）只需要基于行，因为部分末端的边界以CR+LF开头 . 但除此之外，数据不一定是基于行的，如果内容中恰好有换行符，它们之间没有最大距离，也不需要进行转义（好吧，除非引用Content-Transfer-Encoding）串） .Content-Transfer-Encodingdon 't actually indicate that any encoding has been done on the data (and therefore no encoding needs to be undone), they'的7位，8位和二进制选项只是表示您可以在正文部分中看到的数据类型 .在我的[表达不好]的问题中，我真正得到的是如何从套接字中读取/缓冲数据，这样我就能确保 grab 边界，而不必拥有任意大的缓冲区（例如，如果发生了在内容中没有换行符，所以
readline最终缓冲了整个事情） .我最后做的是使用
readline使用最大长度从套接字缓冲，因此缓冲区永远不会长于此，但如果遇到换行符，也会确保终止 . 这确保了当边界到来时（在CR+LF之后），它将位于缓冲区的开头 . 我不得不做一些额外的monkeying以确保我没有在实际的身体内容中包含最终的CR+LF，因为根据RFC在边界之前需要它，因此不是内容本身的一部分 .请尝试查看RFC 2045 . 通常，二进制内容由应用程序转换为BASE64，并使用"Content-Transfer-Encoding : Base64"包含在多部分消息中 . 还有其他传输二进制数据的机制，但这很常见 . 二进制数据被转换为八位字节并以仲裁长度字符串分块（取决于编码变体 - 请参阅上面的BASE64链接） . 接收应用程序然后将其解码为原始二进制内容 .
我不是一个python程序员，但我很惊讶你真的必须自己编写任何代码 . 我怀疑有预建的python库函数为你做这个 .