MIME解释

有时，我们经常使用或引用软件术语或技术而又不十分熟悉它。 MIME对我来说就是这些术语之一。 我们使用MIME标准在各种端点之间交换消息，例如在电子邮件通信，Web服务等中。

MIME无处不在，在我们的软件职业生涯中，我们可能使用了无数次。 但是MIME到底是什么？ 我向一些软件开发人员朋友提出了这个问题，并得到了模棱两可的答案。 有些人将MIME称为MIME类型，有些人试图引用MIME的完整形式。 很明显，MIME不是一个很好理解的概念。 在本文中，我们将尝试阐明什么是MIME？

历史

根据RFC 822 ，原始邮件协议被构建为仅支持标准的US ASCII字符集。 这有很多不足之处。

1. 如果发件人想使用其他字符集（例如印地语，西班牙语或其他任何字符集）发送消息怎么办？
2. 如果发件人想发送多部分消息怎么办？
3. 如果发件人想要添加一些非文本附件怎么办？
4. 如果发件人想在其他字符集中设置邮件头怎么办？

为了解决这些问题，Internet工程任务组（ IETF ）提出了邮件消息的新格式。 这是对著名的RFC822的扩展。 这种新格式称为MIME消息。

什么是MIME？

MIME表示多用途Internet邮件扩展， MIME是将电子邮件扩展为支持，非ASCII文本内容，非文本附件，多部分邮件正文和非US-ASCII标头的Internet标准。 MIME非常成功，以至于被用作一般Web和许多其他技术的消息格式。 MIME格式是使用以下RFC文档定义的。

1. RFC 2045 ：描述用于描述MIME消息结构的各种标头。
2. RFC 2046 ：定义一组初始的媒体类型
3. RFC 2047 ：描述了对RFC 822的扩展，以允许Internet邮件头字段中的非US-ASCII文本数据
4. RFC 2048 ：为MIME相关设施指定各种IANA注册程序
5. RFC 2049 ：提供MIME一致性标准以及MIME消息格式，确认和书目的一些示例。

MIME消息的结构

MIME-Version: 1.0
    From: Nathaniel Borenstein <nsb@nsb.fv.com>
    To: Ned Freed <ned@innosoft.com>
    Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
    Subject: A multipart example
    Content-Type: multipart/mixed;
                  boundary=unique-boundary-1

    --unique-boundary-1

      ... Some text appears here ...    

    --unique-boundary-1
    Content-type: text/plain; charset=US-ASCII

    --unique-boundary-1
    Content-Type: multipart/parallel; boundary=unique-boundary-2

    --unique-boundary-2
    Content-Type: audio/basic
    Content-Transfer-Encoding: base64

      ... base64-encoded 8000 Hz single-channel
          mu-law-format audio data goes here ...

    --unique-boundary-2
    Content-Type: image/jpeg
    Content-Transfer-Encoding: base64

      ... base64-encoded image data goes here ...

    --unique-boundary-2--

    --unique-boundary-1
    Content-type: text/enriched

    <b>this is a test</b>

    --unique-boundary-1
    Content-Type: message/rfc822

    From: (mailbox in US-ASCII)
    To: (address in US-ASCII)
    Subject: (subject in US-ASCII)
    Content-Type: Text/plain; charset=ISO-8859-1
    Content-Transfer-Encoding: Quoted-printable

      ... Additional text in ISO-8859-1 goes here ...

    --unique-boundary-1--

上面是MIME消息的示例。 经过仔细检查，您会发现它具有以下部分。

1. 标头
2. 不同内容类型的多个身体部位

多部分

MIME Multipart消息可以包含一个或多个正文部分，这些正文部分可以具有不同的内容类型，这些正文部分可以嵌入到另一个正文部分中，并包含在父正文部分的内容类型标头上的边界参数中指定的边界内。

剖析MIME标头

MIME版本

MIME-Version: 1.0

此标头的存在让我们知道我们有一个哑剧电子邮件。 该头文件的初衷是为了支持mime的未来版本。 但是实现MIME的方式使得无法更改版本。 现在版本始终固定为1.0，表示我们有一条带有非文本附件的非US ASCII消息。

内容类型标题

Content-Type: multipart/mixed;
              boundary=unique-boundary-1

内容类型标头定义消息的正文和正文部分中存在的数据类型。 这有助于客户端选择适当的机制，以便他们可以向用户显示消息。 类型/子类型定义通常后跟一个边界值。 边界值表示身体部位块，并且所有身体部位都必须以该边界开始和结束。 例如

--unique-boundary-1--

body part goes here

--unique-boundary-1--

内容配置标题

content-disposition = "Content-Disposition" ":"
                              disposition-type *( ";" disposition-parm )
        disposition-type = "attachment" | disp-extension-token
        disposition-parm = filename-parm | disp-extension-parm
        filename-parm = "filename" "=" quoted-string
        disp-extension-token = token
        disp-extension-parm = token "=" ( token | quoted-string )
An example is

        Content-Disposition: attachment; filename="fname.ext"

除非将内容处置标头指定为附件，否则MIME消息的正文类型应按原样显示。 指定Content-Disposition：附件标头后，这意味着正文部分不应正常显示，而应显示为附件，单击它应导致正文部分以标题的文件名参数指定的文件名下载。

内容传输编码

我们知道，像SMTP这样的许多协议只允许消息使用7BIT编码。 现在，借助MIME，还可以跨8位二进制数据发送数据。 仅通过将7位格式的8位或二进制数据编码才能实现。 为此，MIME提供了Content-Transfer-Encoding标头。 例如，考虑由音频文件组成的主体部分。

Content-Type: audio/basic
Content-Transfer-Encoding: base64

现在，由于音频文件为二进制格式，因此应将其重新编码为7BIT格式。 我们使用Content-Transfer-Encoding标头将其转换为BASE 64编码的7BIT支持格式。 除了base 64外，我们还有以下编码。

1. 7BIT –默认
2. Base64
3. 报价优先
4. 8位
5. 二进制
6. x-EncodingName

我希望这篇文章可以进一步说明MIME是什么。 这篇POST是我最近几天所做的研究和阅读的结果，由于我是人类，所以这也可能会出现一些错误。 如果您发现缺少任何重要的基本要点，请告诉我，以便将其添加到帖子中。 如果您发现此帖子有用，请发表一两个评论。

参考： MIME在Weblog4j博客上由我们的JCG合作伙伴 Niraj Singh 解释 。

翻译自: https://www.javacodegeeks.com/2013/09/mime-explained.html