4

電子メールを送信するアプリを持っていますが、何ヶ月も正常に機能していました。最近utf-8、iPhone に送信されたエンコードされた電子メールに問題がありましたExchange account(つまり、そうではありませんIMAP)。
受信者が見なければならなかったのは、 のような無意味な文字の集まりだけでしたLS0tLS0tPV9QYXJ0XzE0N18[....]。

メールのヘッダーを Gmail と比較するContent-Transfer-Encodingと、Content-Type: multipart/alternative;.
私のメールは次のようになります

Delivered-To: ...
Received: ...
...
MIME-Version: ...
Content-Type: multipart/alternative; 
    boundary="----=_boundary" 
Content-Transfer-Encoding: Base64  # <= the extra setting

----=_boundary
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: Base64

YmVu0Cg==

----=_boundary
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: Base64

PGh0bWwgeG1sbnM6bz0iIj48aGVhZD48dGl0bGU+PC90aXRsZT48L2hlYWQ+PGJvZHk+YmVub2l0
PC9ib2R5PjwvaHRtbD4NCjx9IjAiIC8+Cg==

----=_boundary

余分な設定を削除すると、メールが受信され、正しく表示されます。

私の質問:

  1. 特定の場合でも、Encoding基本的には設定が必要ですか？Content-Type: multipart/alternative;
  2. それを削除して、以前と同じようにアプリを使い続けても安全ですか?

私が見つけた編集IETF：

エンコーディングに関する考慮事項: マルチパート コンテンツ タイプはエンコーディングを持つことができません。

しかし、私も見つけましたWikipedia：

マルチパート タイプの content-transfer-encoding は、複数レベルのデコードによって引き起こされる複雑さを回避するために、常に「7 ビット」、「8 ビット」、または「バイナリ」でなければなりません。

矛盾していませんか？

4

2 に答える 2

8

IETF とウィキペディアの声明は実際には矛盾していません。7bit、8bit、またはbinaryは、コンテンツの変換を指定しないという点で、実際にはコンテンツ エンコーディングではありません。それらは単に、コンテンツがエンコードされていないことを示しています。また、7bit8 ビット クリーンではないトランスポートを介してメッセージを送信する必要がある場合でも、コンテンツをエンコードする必要がないことも指定します。

メッセージの最下層のみに、またはContent-Transfer-Encodingなどの実体を含める必要があります。あなたが外側の部分から引用したメッセージでは、確かにbase64でエンコードされていないため、標準に違反しているだけでなく、間違っていると述べています。それは確かにそのメッセージの表示に問題を引き起こすと予想されます.base64quoted-printable

于 2012-11-28T07:59:57.070 に答える
5

実際には、マルチパートの各パートには独自のエンコーディングがあり、マルチパート コンテナーに対して 1 つを宣言しても意味がありません。とにかく、ウィキペディアの引用を理解できません。いずれにせよ、それはほとんど権威的ではありません。

于 2012-11-28T07:44:54.890 に答える