Mime 7位編碼和UnsupportedEncodingException

Question

我已經實現了一種方法，但是我不確定這是正確的方法還是將來會給我帶來麻煩。
給這封電子郵件：

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是正確的。 但這似乎太簡單了。。。將來我會遇到哪些問題？ 有沒有更好的方法可以跳過異常並獲取電子郵件內容而無需強制使用車載音響系統和編碼？

Answer 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中），然后分配正確的content-type標頭。 或者說服發送這些消息的任何對象，使其遵循普通的舊US-ASCII或切換到UTF-8。 （或者，找到如何教Java處理UTF-7編碼的方法，但這超出了我的能力。）

另請參見http://en.wikipedia.org/wiki/UTF-7

---

基本RFC822電子郵件純粹是7位。 為了實現豐富的內容和不同的字符集， MIME是在1990年代初期開發的。 問題的中心是兩個MIME標頭： Content-Type:和Content-Transfer-Encoding: 這些都用於標識MIME部件的類型，但是它們是不同的概念。 Content-Type描述數據是什么（ text/html ， audio/midi ，用於未類型化二進制數據的application/octet-stream等）。 Content-Transfer-Encoding:指示如何對其進行編碼以通過電子郵件（或其他MIME管道）進行傳輸。

Content-Transfer-Encoding:基本上定義了兩種編碼和三種未編碼的類型。 CTE： 7bit表示數據本身適合在7位通道上傳輸（還有行長限制）； 8bit不是，如果通道不能容納8位數據，則​​需要重新編碼。 類似地， binary也是8位，但除此之外不能保證行長（即，它可能包含長於大約1,000個字符的行）。 因此，要通過7位通道傳輸binary或8-bit數據，您需要將內容重新編碼為base64或quoted-printable 。 這兩種編碼都將8位字符替換為7位序列。 期望接收者執行反向替換以便解碼和提取數據。

一旦提取完成，數據就基本上准備好在接收方使用。 但是，對於文本類型，還有字符集編碼的問題。 許多字符集只是7位或8位，因此流中的一個字節對應於一個字符。 但是多字節字符集的行為並非如此，因此也需要以某種方式對其進行編碼。 但這與上面描述的MIME 7bit / 8bit不同。 字符編碼告訴您字節流如何編碼多字節字符。

UTF-8將多字節字符編碼為8位字符序列（而便利的7位字符與US-ASCII 7位編碼相同）。 編碼具有一些不錯的屬性，您可以在Wikipedia中閱讀。

UTF-7從未被正式接受為正式的Unicode編碼，因此並未得到廣泛使用。 它不完全與US-ASCII兼容，因為+和-字符用於編碼多字節字符序列。

如果您想解碼UTF-7，並且您的語言不支持編碼，則必須編寫自己的解碼器。 替代方案是不對編碼進行解碼，而將其留給下游使用者進行解碼。 在這種情況下，請務必以某種方式將字符編碼中繼到下游。 但是，由於未廣泛支持UTF-7，因此我建議將其重新編碼為UTF-8，這已得到廣泛支持和理解（並且如上所述，如果不存在多字節字符，則與US-ASCII透明兼容）。

因此，僅作總結； 如果更改標題，則還必須更改編碼。 如果您很幸運（並且您的示例具有代表性），該文本不包含任何實際編碼的UTF-7多字節字符，在這種情況下，您可以安全地將其重新標記為US-ASCII。 如果它確實包含+或-字符，則它們是需要解碼的UTF-7序列的一部分（不過，您可能還很幸運，並且這些序列只是UTF-7轉義符，其編碼文字的正負號） 。