私は、ユーザーがmultipart/form-dataを使ってファイルをアップロードできる、単純なWebサーバーをPythonで書いています。私が知る限り、マルチパートのMIMEデータは行ベースであると考えられています。例えば、境界線は行の先頭になければなりません。multipart/form-data（ファイルアップロード）のバイナリ行
この点でバイナリデータがどのように処理されるかわかりません。私のクライアント（Firefox）はではありません。は7bit ASCIIなどにエンコードされていません。送信する生のバイナリデータです。データを任意の場所の行に分割しますか？マルチパートデータに最大行長が指定されていますか？私はmultipart/form-dataのRFCを調べてみましたが、何も見つかりませんでした。
RFCを掘り下げた後、ついに私は頭の中でまっすぐになったと思います。身体部分（すなわち、multipart/*メッセージ内の個々の部分の身体内容）は、部分の末尾の境界がCR+LFで始まるという点で行ベースである必要があります。しかし、そうでなければ、データはラインベースである必要はなく、コンテンツに改行があった場合、それらの間に最大距離はなく、とにかくエスケープする必要もありません（おそらくContent-Transfer-Encodingが引用されていない限り、文字列）。 Content-Transfer-Encodingの7ビット、8ビット、およびバイナリのオプションは、実際にデータに対してエンコーディングが行われたことを示していないため、エンコーディングを元に戻す必要はありません。あなたは体の部分で見ることを期待することができます。
私が本当に問題になっていたのは、ソケットからデータを読み込み/バッファする方法でした。境界を捕まえたことを確認できるようにしました。コンテンツ内に改行がない場合は、readlineが全体をバッファリングしてしまいました）。
最後に、最大長を使用してreadlineでソケットからバッファリングしていたので、バッファは決してそれよりも長くなることはありませんでしたが、改行が発生した場合は必ず終了します。これにより、境界が来たとき（CR+LFに続いて）、バッファの先頭にあることが保証されました。 RFCによれば、それは境界の前に必要であり、したがってコンテンツ自体の一部ではないため、実際の本文コンテンツにその最終的なCR+LFを含まないようにするために、ちょっとしたモンキーが必要でした。
RFC 2045をお試しください。通常、 バイナリコンテンツはアプリケーションによってBASE64 に変換され、 "Content-Transfer-Encoding：Base64"を使用してマルチパートメッセージに含まれます。 バイナリデータを転送する他のメカニズムがありますが、これはかなり一般的です。バイナリデータは、 がオクテットに変換され、任意の長さの文字列でチャンクアウトされます（エンコーディングバリアントに応じて - 上記のBASE64リンクの を参照）。受信アプリケーション はそれを元のバイナリコンテンツにデコードします。
私はPythonプログラマーではありませんが、あなたは本当にこのコードを自分で作成しなければならないと驚いています。私はあなたのためにこれを行うためのビルドされたPythonライブラリ関数があると思われる。
ありがとう、私は有益ではなかった別のRFCを見ていました。私はまた、セクション5でマルチパートメッセージを具体的に定義するRFC 2046を発見しました。これらのRFCには、私から離れた微妙なものがあります。マルチパートメッセージは、7ビット、8ビット、バイナリ以外のエンコーディング（すなわち、Base-64ではない）。しかし、マルチパート内の個々のパーツには独自のコンテンツエンコーディングを持たせることができるので、Base-64が可能であることは間違いありません。 – brianmearns