0

私はアプローチを実装しましたが、それが正しいものであるか、将来問題を引き起こす可能性があるかどうかはわかりません。
このメールを送る：

Date: Mon, 17 Sep 2012 04:14:36 +0200   
Content-Type: text/plain;
    charset="utf-7"   
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
To: user@address.com

Dear Sir/madam, ... etc

そして、このコードは次のとおりです。

MimePart part; //The email 
if (part.isMimeType("text/plain")) {
   String plainContent = part.getContent().toString();

例外は次のとおりです。

java.io.UnsupportedEncodingException: utf-7

私はこの変更を行ったので、文字セットは常にutf-8であり、エンコーディングはquoted-printable

part.setHeader("Content-Transfer-Encoding", "quoted-printable");
part.setHeader("Content-Type", "text/plain; charset=utf-8");

例外はもうありません、そしてそれplainContentは正しいです。しかし、それは簡単すぎる解決策のようです...私は将来どのような問題を抱えることができますか？例外をスキップして、カーセットとエンコードを強制せずに電子メールコンテンツを取得するためのより良い方法はありますか？

4

1 に答える 1

1

誰かが実際にUTF-7を送信すると、クライアントはそれを誤ってデコードします。しかし、それは非常にまれです。ほとんどのサイトは、Unicodeを使用している場合、UTF-8を送信します。投稿したサンプルコンテンツの場合、これは純粋なASCIIであるため、UTF-7とUTF-8の両方で有効です。（UTF-7は+と-に特別なセマンティクスを割り当てるため、これらの文字のシーケンスを含むメッセージの場合、ASCIIでさえ安全ではありません。つまり、UTF-7が誤ってUS-ASCIIとしてラベル付けされているか、またはその逆の場合、正しくデコードされません。）

Quoted-Printableを実際にはそうではないものに割り当てることも同様に無計画です。メッセージ内の等号は、QPでは特別な意味を持ちます。私はあなたがそれを残すべきだと思います。

適切な解決策は、メッセージ本文を実際に再コーディングすることです。つまり、UTF-7からUTF-8に変換し（場合によってはquoted-printableでラップし）、正しいコンテンツタイプヘッダーを割り当てます。または、これらのメッセージを送信しているものはすべて、単純な古いUS-ASCIIに固執するか、UTF-8に切り替えるように説得します。（または、JavaにUTF-7エンコーディングを処理するように教える方法を見つけてください。しかし、それは私の能力の範囲外です。）

http://en.wikipedia.org/wiki/UTF-7も参照してください

基本的なRFC822電子メールは純粋に7ビットでした。リッチコンテンツとさまざまな文字セットを有効にするために、MIMEは1990年代初頭に開発されました。質問の中心となるのは、2つのMIMEヘッダーContent-Type:とContent-Transfer-Encoding:です。これらは両方ともMIMEパーツのタイプを識別するために使用されますが、これらは別個の概念です。は、Content-Typeデータが何であるかを記述します（text/html、、、型指定されていないバイナリデータの場合など）。は、電子メール（または別のMIMEコンジット）を介した送信のためにどのようにエンコードされているかを示します。audio/midiapplication/octet-streamContent-Transfer-Encoding:

Content-Transfer-Encoding:基本的に、2つのエンコーディングと3つのエンコードされていないタイプを定義します。CTE：7bitデータ自体が7ビットチャネルでの送信に適していることを示します（回線長の制限もあります）。8bitではなく、チャネルが8ビットデータに対応できない場合は、再エンコードする必要があります。同様に、binaryも8ビットですが、行の長さは保証されません（つまり、約1,000文字を超える行が含まれる場合があります）。したがって、7ビットチャネルを介してbinaryまたはデータを送信するには、コンテンツをまたはとして再コーディングする必要があります。これらのエンコーディングは両方とも、8ビット文字を7ビットシーケンスに置き換えます。受信者は、データをデコードおよび抽出するために逆置換を実行することが期待されます。8-bitbase64quoted-printable

抽出が行われると、データは基本的に受信者側で使用できるようになります。ただし、テキストタイプの場合、文字セットのエンコードの問題もあります。多くの文字セットは単純に7ビットまたは8ビットであるため、ストリーム内の1バイトは1文字に対応します。ただし、マルチバイト文字セットはこのように動作しないため、それらも何らかの方法でエンコードする必要があります。ただし、これは上記のMIME 7bit/8bitのものとは異なります。文字エンコードは、バイトストリームがマルチバイト文字をどのようにエンコードするかを示します。

UTF-8は、マルチバイト文字を8ビット文字のシーケンスとしてエンコードします（便利なことに、7ビット文字はUS-ASCII 7ビットエンコードと同じです）。エンコーディングには、ウィキペディアで読むことができるいくつかの優れたプロパティがあります。

UTF-7は、公式のUnicodeエンコーディングとして正式に受け入れられることはなく、広く使用されていません。+および-文字はマルチバイト文字シーケンスのエンコードに使用されるため、US-ASCIIと完全に互換性があるわけではありません。

UTF-7をデコードしたいが、言語がエンコードをサポートしていない場合は、独自のデコーダーを作成する必要があります。別の方法は、エンコーディングをデコードせず、ダウンストリームのコンシューマーにデコードを任せることです。この場合、文字エンコードをダウンストリームに中継するように注意してください。ただし、UTF-7は広くサポートされていないため、広くサポートされ理解されているUTF-8に再コーディングすることをお勧めします（また、前述のように、マルチバイト文字が存在しない場合はUS-ASCIIと透過的に互換性があります）。

要約すると、ヘッダーを変更する場合は、エンコーディングも変更する必要があります。運が良ければ（そしてあなたの例が代表的であるなら）、テキストには実際にエンコードされたUTF-7マルチバイト文字が含まれていません。その場合、US-ASCIIとして安全にラベルを変更できます。+または文字が含まれている場合-、それらはデコードする必要のあるUTF-7シーケンスの一部です（ただし、幸運なことに、シーケンスは文字通りのプラスまたはマイナス記号をエンコードするUTF-7エスケープにすぎません）。

于 2012-10-02T08:40:55.587 に答える