2 に答える
これはプレースホルダーの回答であり、いくつかの質問に対する信頼できる入力を待っている間に私が何をしたかを説明しています。少なくとも 1 つの設計上の決定において、このアプローチが間違っているか不適切であることが示されれば、別の回答を喜んで受け入れます。
これが、今のところ私の好みに応じてこの作業を行うために使用したコードです。私は次の決定を下しました。
テキスト フィールドに 8 ビット データを使用しても、仕様に準拠できますか?
そうすることにしました。少なくともこのアプリケーションでは、機能します。
テキスト フィールドを追加のエンコードなしで 8 ビット データとしてシリアル化する電子メール パッケージを入手できますか?
方法が見つからなかったので、これで見た他のすべてのレシピと同じように、私は自分の連載を行っています.
バイナリ ファイル コンテンツの base64 エンコーディングも回避できますか?
少なくとも私の単一のアプリケーションでは、ファイルの内容をバイナリで送信するだけで十分に機能するようです。
回避できる場合、Content-Transfer-Encoding を 8 ビットまたはバイナリとして記述する必要がありますか?
RFC 2045 セクション 2.8が述べているように、データ8bitは CRLF ペア間で 998 オクテットの行の長さの制限を受けるため、binaryそれがより一般的であり、したがってここでのより適切な説明であると判断しました。
本文を自分でシリアル化する必要がある場合、ヘッダー値をフォーマットするだけで email.header パッケージを単独で使用するにはどうすればよいでしょうか?
すでに私の質問に編集されているように、これにemail.utils.encode_rfc2231は非常に役立ちます。最初に ascii を使用してエンコードしようとしますが、二重引用符で囲まれた文字列内で禁止されている非 ASCII データまたは ASCII 文字の場合は、その方法を使用します。
私がやろうとしているすべてのことをすでに行っている実装はありますか?
私が知っているわけではありません。ただし、他の実装は、私のコードからアイデアを採用するよう招待されています。
編集：
このコメントのおかげで、ヘッダーに RFC 2231 を使用することが広く受け入れられているわけではないことに気付きました。HTML 5 の現在のドラフトでは、その使用が禁止されています。また、野生で問題を引き起こすことも確認されています。しかし、POST ヘッダーは必ずしも特定の HTML ドキュメント (たとえば、Web API を考えてください) に対応しているとは限らないため、その点でもそのドラフトを信頼できるかどうかはわかりません。おそらく正しい方法は、RFC 5987 セクション 4.2が示唆する方法で、エンコードされた名前とエンコードされていない名前の両方を与えることです。ただし、その RFC は HTTP ヘッダー用ですが、 multipart/form-data ヘッダーは技術的には HTTP 本文です。したがって、そのRFCは適用されず、マルチパート/フォームデータに対して両方のフォームを同時に使用することを明示的に許可する（または奨励する）RFCを知りません。
HTTP で最もよく使用される Python ライブラリになりつつあるRequestsライブラリを指すPython スクリプトの質問から POST を使用してファイルを送信を参照することをお勧めします。必要な機能がすべて見つからず、自分で実装することにした場合は、このプロジェクトに貢献することをお勧めします。