ユーザーが multipart/form-data を使用してファイルをアップロードできるようにする単純な Web サーバーを Python で作成しています。私が知る限り、マルチパート MIME データは行ベースであると想定されています。たとえば、境界は行の先頭にある必要があります。
この点でバイナリデータがどのように処理されるかわかりません。私のクライアント (Firefox) は、それを 7 ビット ASCII などにエンコードしていません。送信している生のバイナリ データです。データを任意の場所で行に分割しますか? マルチパート データに指定された最大行長はありますか? multipart/form-data の RFC を調べてみましたが、何も見つかりませんでした。
RFC を掘り下げた後、ようやく頭の中ですべてを理解できたと思います。ボディ パーツ (つまり、multipart/*メッセージ内の個々のパーツのボディ コンテンツ) は、パーツの最後の境界がCR+LF. しかし、それ以外の場合、データは行ベースである必要はなく、コンテンツに改行が含まれている場合、それらの間に最大の距離はなく、とにかくエスケープする必要もありません (まあ、おそらくContent-Transfer-Encoding引用文字列でない限り) ）。の 7 ビット、8 ビット、およびバイナリ オプションはContent-Transfer-Encoding、データに対して何らかのエンコードが行われたことを実際には示しません (したがって、エンコードを元に戻す必要はありません)。ボディ部分に期待できます。
[表現が不十分な] 質問で私が実際に得ていたのは、ソケットからデータを読み取り/バッファリングして、任意に大きなバッファを持たずに境界を確実にキャッチできるようにする方法でした (たとえば、コンテンツに改行がないためreadline、全体がバッファリングされました)。
私がやったのはreadline、最大長を使用してソケットからバッファリングすることだったので、バッファはそれより長くなることはありませんが、改行が発生した場合は必ず終了します。CR+LFこれにより、(a に続いて) 境界が来たときに、それがバッファーの先頭にあることが保証されました。CR+LFRFC によると、境界の前に必要であり、コンテンツ自体の一部ではないため、実際の本文コンテンツにその final を含めないようにするために、少し余分な操作を行う必要がありました。
RFC 2045を確認してみてください。通常、バイナリ コンテンツはアプリケーションによってBASE64に変換され 、「Content-Transfer-Encoding : Base64」を使用してマルチパート メッセージに含まれます。バイナリ データを転送するメカニズムは他にもありますが、これは非常に一般的です。バイナリ データはオクテットに変換され、任意の長さの文字列に分割されます (エンコーディング バリアントに応じて - 上記の BASE64 リンクを参照してください)。受信アプリケーションは、それを元のバイナリ コンテンツにデコードします。
私は Python プログラマーではありませんが、これを自分でコーディングしなければならなかったことに驚きました。これを行うための事前構築済みのpythonライブラリ関数があると思います。