2024年5月7日发(作者：皮寄南)聚合邮件（aggregated message） 假如我们发送一封包含网页（html文档）的电子邮件，并且希望接收方的用户邮件软件能够显示这张网页，那么邮件就必须有聚合资源的机制。我们知道，html文档中往往包含图象、视频片断、Applet等数据资源，这些数据资源并不是包含在html文档中的，而是存放在Web服务器上，html用URI指出获取这些资源的方法。例如，在html中，图象元素的语法是URI >，其中的URI是图象资源的URI，通常是http命名方案的URI，浏览器据此可获得图象数据并显示在网页窗口上。 又如Applet的语法是URI code=class_file >，其中的URI指出Applet代码的存放位置，class_file指出此处要执行的类文件名。浏览器获得html文档之后，必须根据这些信息从网络上获取代码，然后才能执行这些代码。 我们将包含图象、Applet等资源的html文档称为根数据（root resource），将其中包含的资源称为附属数据（subsidiary resource）。并非只有网页才包含附属数据，其它格式的文档（例如XML、pdf文档）也有这种情况。聚合邮件是用来包含这类文档的邮件。 不能要求用户邮件软件也像浏览器那样通过网络获取附属数据，因为用户经常要在脱机的环境中阅读已下载到本地的邮件。因此，必须在邮件中同时包含根数据和附属数据。我们可以利用分块邮件，将根数据和各种附属数据分别存放在各自的块中。分块邮件的每一块都可以指定块内数据类型和传送编码，完全可以包含各种类型的附属资源。但是这种邮件内各块是存在引用关系的，必须由根数据块引用附属数据块中的数据，因此必须指出哪个数据块是根数据，哪些是附属数据，以及根数据如何引用附属数据。MIME已定义的分块类型Multipart/*并没有反映这种关系，为此，RFC2387提出一种新的分块类型Multipart/Related，RFC2392提出一种命名方案为mid和cid的URI，用来标识被引用的附属数据块，而RFC2557则定义一个新的MIME头段Content-Location来标识数据块。 7．1 Multipart/Related Multipart/Related是一种分块数据类型，用在头段Content-Type中，其语法是 Content-type: Multipart/Related *(; params) 其中params是参数。可以使用多个参数，每个参数的格式都是“参数名 = 参数值”的形式。Multipart/Related类型使用的参数有： • • boundary：块分界字符串，所有的Multipart/*类型都必须有这个参数，详见4.4.1节。 type：参数值是MIME媒体类型，例如text/html，text/plain等。这个参数用来指出根数据的类型。这个参数是必有的。虽然根数据块内也可以用头段Content-type指出媒体类型，但是这个参数使得用户邮件软件一开始就可以知道根数据块的类型。 • start：参数值是标识根数据块的URI，其作用是指出当前邮件中哪一块是根数据块。这个参数是可选的，如果没有这个参数，则默认邮件中第一块为根数据块。 • strat-info：为邮件应用程序提供进一步的信息，例如一些可执行的命令。这个参数是可选的，其参数值由应用程序自行解释。 本章第六节提到头段Content-Disposition，这个头段可用来指出块内数据是inline还是attachment。当邮件正文为Multipart/Related时，所有的块都应该是inline，因此头段Content-Disposition在此处是没有意义的。但是仍然允许在块内使用这个头段，因为那些不知道Multipart/Related类型的软件将会将邮件作为Multipart/mixed处理，这时Content-Disposition可以告诉它们数据的处理方式。 支持Multipart/Related类型的软件则必须忽略块内的Content-Disposition头段。 7．2 Content-ID 为了让根数据引用附属数据，可以在附属数据块中用头段Content-ID指定一个URI，然后在根数据中按照这个URI引用数据。 例如，如果我们在邮件中包含一个html文档，则其中可能包含了引用附属数据的URI，例如 其中的/images/本身就是一个URI，但这种URI并不是指向聚合邮件内的数据，而是指向网络上的某个位置（头段Content-Location可利用这种URI，稍后介绍）。使用Content-ID的方法是改写根数据中的URI，使之指向邮件内的某一块。 这种URI有两种命名方案：cid和mid。cid用来标识邮件内的一个数据块，mid则用来标识一封邮件及其中的某一块。 cid的语法是： cid:localpart@domain 简单地说，就是“cid:”后面再加上一个“邮箱地址”，不过其中的localpart并非用户名，而是作为ID用的标识字符串，这串ID字符的唯一性由设计它的主机负责，domain是该主机的域名。由于域名是唯一的，localpart在域名对应的主机上也是唯一的，所以这种URI是全球唯一的。 当用cid标识数据块时，块内用头段Content-ID指出该块的cid，但要去掉开头的“cid:”并且loacalpart@domian要用一对尖括号括起来，而根数据中对应的cid则使用原状。 例6：使用cid的聚合邮件。 From:************To:************MIME-Version: 1.0 Content-type: multipart/related; boundary="simple-example"; type=text/html -- simple-example Content-type: text/html; charset="GB2312" Content-Transfer-Encoding: 8bit 此处为html内容，其中包括一幅图象，其中的URI已设为cid： --simple-example Content-ID:Content-type: image/gif Content-Transfer-Encoding: base64 --simple-example-- 命名方案mid的URI语法为： 2024年5月7日发(作者：皮寄南)聚合邮件（aggregated message） 假如我们发送一封包含网页（html文档）的电子邮件，并且希望接收方的用户邮件软件能够显示这张网页，那么邮件就必须有聚合资源的机制。我们知道，html文档中往往包含图象、视频片断、Applet等数据资源，这些数据资源并不是包含在html文档中的，而是存放在Web服务器上，html用URI指出获取这些资源的方法。例如，在html中，图象元素的语法是URI >，其中的URI是图象资源的URI，通常是http命名方案的URI，浏览器据此可获得图象数据并显示在网页窗口上。 又如Applet的语法是URI code=class_file >，其中的URI指出Applet代码的存放位置，class_file指出此处要执行的类文件名。浏览器获得html文档之后，必须根据这些信息从网络上获取代码，然后才能执行这些代码。 我们将包含图象、Applet等资源的html文档称为根数据（root resource），将其中包含的资源称为附属数据（subsidiary resource）。并非只有网页才包含附属数据，其它格式的文档（例如XML、pdf文档）也有这种情况。聚合邮件是用来包含这类文档的邮件。 不能要求用户邮件软件也像浏览器那样通过网络获取附属数据，因为用户经常要在脱机的环境中阅读已下载到本地的邮件。因此，必须在邮件中同时包含根数据和附属数据。我们可以利用分块邮件，将根数据和各种附属数据分别存放在各自的块中。分块邮件的每一块都可以指定块内数据类型和传送编码，完全可以包含各种类型的附属资源。但是这种邮件内各块是存在引用关系的，必须由根数据块引用附属数据块中的数据，因此必须指出哪个数据块是根数据，哪些是附属数据，以及根数据如何引用附属数据。MIME已定义的分块类型Multipart/*并没有反映这种关系，为此，RFC2387提出一种新的分块类型Multipart/Related，RFC2392提出一种命名方案为mid和cid的URI，用来标识被引用的附属数据块，而RFC2557则定义一个新的MIME头段Content-Location来标识数据块。 7．1 Multipart/Related Multipart/Related是一种分块数据类型，用在头段Content-Type中，其语法是 Content-type: Multipart/Related *(; params) 其中params是参数。可以使用多个参数，每个参数的格式都是“参数名 = 参数值”的形式。Multipart/Related类型使用的参数有： • • boundary：块分界字符串，所有的Multipart/*类型都必须有这个参数，详见4.4.1节。 type：参数值是MIME媒体类型，例如text/html，text/plain等。这个参数用来指出根数据的类型。这个参数是必有的。虽然根数据块内也可以用头段Content-type指出媒体类型，但是这个参数使得用户邮件软件一开始就可以知道根数据块的类型。 • start：参数值是标识根数据块的URI，其作用是指出当前邮件中哪一块是根数据块。这个参数是可选的，如果没有这个参数，则默认邮件中第一块为根数据块。 • strat-info：为邮件应用程序提供进一步的信息，例如一些可执行的命令。这个参数是可选的，其参数值由应用程序自行解释。 本章第六节提到头段Content-Disposition，这个头段可用来指出块内数据是inline还是attachment。当邮件正文为Multipart/Related时，所有的块都应该是inline，因此头段Content-Disposition在此处是没有意义的。但是仍然允许在块内使用这个头段，因为那些不知道Multipart/Related类型的软件将会将邮件作为Multipart/mixed处理，这时Content-Disposition可以告诉它们数据的处理方式。 支持Multipart/Related类型的软件则必须忽略块内的Content-Disposition头段。 7．2 Content-ID 为了让根数据引用附属数据，可以在附属数据块中用头段Content-ID指定一个URI，然后在根数据中按照这个URI引用数据。 例如，如果我们在邮件中包含一个html文档，则其中可能包含了引用附属数据的URI，例如 其中的/images/本身就是一个URI，但这种URI并不是指向聚合邮件内的数据，而是指向网络上的某个位置（头段Content-Location可利用这种URI，稍后介绍）。使用Content-ID的方法是改写根数据中的URI，使之指向邮件内的某一块。 这种URI有两种命名方案：cid和mid。cid用来标识邮件内的一个数据块，mid则用来标识一封邮件及其中的某一块。 cid的语法是： cid:localpart@domain 简单地说，就是“cid:”后面再加上一个“邮箱地址”，不过其中的localpart并非用户名，而是作为ID用的标识字符串，这串ID字符的唯一性由设计它的主机负责，domain是该主机的域名。由于域名是唯一的，localpart在域名对应的主机上也是唯一的，所以这种URI是全球唯一的。 当用cid标识数据块时，块内用头段Content-ID指出该块的cid，但要去掉开头的“cid:”并且loacalpart@domian要用一对尖括号括起来，而根数据中对应的cid则使用原状。 例6：使用cid的聚合邮件。 From:************To:************MIME-Version: 1.0 Content-type: multipart/related; boundary="simple-example"; type=text/html -- simple-example Content-type: text/html; charset="GB2312" Content-Transfer-Encoding: 8bit 此处为html内容，其中包括一幅图象，其中的URI已设为cid： --simple-example Content-ID:Content-type: image/gif Content-Transfer-Encoding: base64 --simple-example-- 命名方案mid的URI语法为：