MIME 消息

本文转载自:https://www.ibm.com/docs/en/integration-bus/10.0?topic=domain-mime-messages

MIME 消息

MIME 消息由数据和元数据组成。MIME 元数据由 HTTP 样式的标头和 MIME 边界分隔符组成。

MIME 标头

每个标头都是一行上以冒号分隔的名称-值对。ASCII 序列<CR><LF>终止该行。这些标题的序列称为标题块,以空行结尾:<CR><LF><CR><LF>此 HTTP 样式中的任何标头都可以出现在 MIME 文档中。MIME 标准头字段中描述了一些常见的 MIME 头

内容类型

必须存在的唯一标头是Content-Type标头。此标头指定消息中的数据类型。如果 Content-Type 值以multipart开头,则消息是多部分 MIME 消息。对于多部分消息,Content-Type 标头还必须包含一个边界属性,该属性给出用于分隔消息部分的文本。每个 MIME 部分都有自己的 Content-Type 字段,用于指定该部分中数据的类型。这也可以是多部分的,它允许嵌套多部分消息。具有任何其他 Content-Type 值的 MIME 部分将作为 BLOB 数据处理。

如果 MIME 文档通过 HTTP 发送,则 Content-Type 标头出现在 HTTP 标头块中,而不是 MIME 消息正文中。因此,集成节点将 Content-Type 标头的值作为逻辑树Properties文件夹中的ContentType 属性进行管理这允许 MIME 解析器获取通过 HTTP 接收的 MIME 文档的 Content-Type 值。如果您需要创建新的 MIME 树或修改 Content-Type 的值,请使用 MIME 域中的 ContentType 属性设置 Content-Type 值。如果直接在 MIME 树或 HTTP 树中设置 Content-Type 值,则此值可能会被忽略或使用不一致。以下 ESQL 是如何设置集成节点 ContentType 属性的示例:
SET OutputRoot.Properties.ContentType = 'text/plain';

解析

MIME 域不强制执行完整的 MIME 规范。因此,您可以处理在其他应用程序中可能无效的消息。例如,MIME 解析器不坚持使用MIME-Version标头。MIME 解析器强加了以下约束:
  • MIME 标头必须正确格式化:
    • 每个标头都是一个以冒号分隔的名称-值对,在它自己的一行上,以 ASCII 序列 结束<CR><LF>
    • 标题行必须使用 7 位 ASCII。
    • 分号用于分隔参数:
      Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
    • 标题可能包含括号中的注释,例如:
      MIME-Version: 1.0 (Generated by XYZ)
  • 以空格开头的行被视为上一行的延续。因此,一个长标题可以分成多行。
  • 如果标题块中的两个或多个标题具有相同的名称,则它们的值将连接到以逗号分隔的列表中。
  • 顶级 MIME Con​​tent-Type 标头必须可用。标头不区分大小写。如果传输是 HTTP,则 HTTP 标头中的任何 Content-Type 值都用作顶级 Content-Type。如果传输不是 HTTP,则 Content-Type 必须出现在 MIME 消息的初始标头块中。
  • Content-Type 值是一个媒体类型,后跟/字符和一个子类型。这方面的例子是text/xmlmultipart/related解析器不验证子类型。Content-Type 值后面可以跟一个或多个用分号分隔的参数。
  • 如果消息的媒体类型是多部分的,则边界属性必须提供用于分隔单独 MIME 部分的文本。
  • 每个单独的 MIME 部分都可以有自己的 Content-Type 标头。部分头可以有一个多部分的媒体类型,以便可以嵌套多部分消息。在这种情况下,必须提供有效的边界属性,并且其值必须不同于先前在消息中定义的任何值。具有任何其他 Content-Type 值的 MIME 部分将作为 BLOB 数据处理。
  • MIME 多部分边界定界符以 7 位 ASCII 表示。边界定界符由以连字符对开头的行和边界字符串组成。该序列不得出现在 MIME 消息内的任何点,而不是作为边界。MIME 结束分隔符是一个连字符对,后跟 MIME 边界字符串,然后是另一个连字符对。所有定界符行都必须以 ASCII 序列结尾<CR><LF>分隔消息的示例是:
    --MIME_boundary
    message data
    --MIME_boundary
    message data
    --MIME_boundary--
    其中MIME_boundary是边界分隔符字符串,消息数据表示消息数据。
  • 不支持MIME 媒体类型消息并在运行时导致错误。
  • 任何前导数据(初始 MIME 标头块和第一个边界定界符之间的文本)或结尾数据(最终边界定界符之后的文本)都作为仅值元素存储在逻辑树中。前导数据和尾声数据只能分别作为 Parts 节点的第一个和最后一个子节点出现。
  • MIME 解析器不支持按需解析并忽略Parse Timing属性。解析器不会根据消息模型验证 MIME 消息,并且会忽略IBM® Integration Toolkit Validate属性。

多部分 MIME 的特殊情况

MIME 解析器主要用于多部分 MIME 消息。但是,解析器也处理一些特殊情况:
  • 多部分 MIME,只有一个部分。MIME 部分的逻辑树照常保存 Content-Type 和其他信息,但附件的 Data 元素为空。
  • 单部分 MIME。对于单部分 MIME,逻辑树没有 Parts 子项。MIME 树的最后一个子元素是数据元素。Data 元素是包含消息数据的 BLOB 的父元素。
  • 没有内容的 MIME 部分。

安全 MIME (S/MIME)

S/MIME 是发送安全电子邮件的标准。S/MIME 具有multipart/signed的外层 Content-Type,带有参数protocolmialg,用于定义用于加密消息的算法。一个或多个 MIME 部分可以具有编码内容。这些部分具有 Content-Type 值,例如application/pkcs7-signaturebase64的 Content-Transfer-Encoding MIME 域不会尝试解释或验证消息是否已签名。

posted on 2021-06-08 17:32  Gary Zhang  阅读(3)  评论(0编辑  收藏  举报

导航