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转义符，其编码文字的正负号） 。