适用于
：Outlook 2013 | Outlook 2016
如果在对邮件内容进行编码时使用具有 TNEF 的 MIME，则所有附件属性和内容都在 TNEF 流中。 TNEF 本身是名为 Winmail.dat 的单个二进制附加文件，按照没有 TNEF 的 MIME 所述进行编码。
如果在不使用 TNEF 的情况下使用 MIME，附加文件将作为 MIME 消息内容部分发送。 文件名放置在附件的
Content-type
标头的
name
参数中。 附件的字符集放置在
content-type
的
charset
参数中;它和内容传输编码是通过扫描整个附件内容来确定的。 URL 附件受到特殊处理：
如果附件是 URL (扩展名为 的附加文件。URL) ，其中定义的访问模式是匿名 FTP，它编码为外部消息，并将 URL (文件的内容) 复制到外部消息的标头中。
内容类型：message/external-body;access-type=anon-ftp
(Content-Transfer-Encoding：假定为 7 位。)
如果仅找到 7 位字符，并且没有行长度超过 140 个字符，则附件为 ASCII 文本。
内容类型：text/plain;charset=us-ascii Content-Transfer-Encoding： 7bit
如果找到长行或最多 25% 8 位字符，则附件内容为文本，字符集由区域设置确定。 应从 ISO 标准 8859 定义的字符集中选择它。
内容类型：text/plain;charset=ISO-8859-1
(例如)
Content-Transfer-Encoding: quoted-printable
如果 25% 或更多字符设置了高位，则附件为二进制。 它使用 Base64 算法进行编码。
内容类型：默认情况下，application/octet-stream
(;基于文件扩展名)
Content-Transfer-Encoding：base64 *
在出站消息上，内容类型应派生自文件名的三字母扩展名。 此映射存在于系统注册表中;下有一个名为“Content Type”的字符串值，如果定义了 MIME 内容类型，则会提供 MIME 内容类型。 此示例适用于 TIFF 图像文件：
HKEY_LOCAL_MACHINE\
内容类型 = “image/tiff”
如果文件扩展名没有映射，则应使用默认
应用程序/八位字节
流。
在入站邮件上，附件的内容类型应始终复制到 MAPI 属性
，PR_ATTACH_MIME_TAG
(
PidTagAttachMimeTag
) 。 即使为附加文件定义了文件名，也应在
PR_ATTACH_FILENAME
(
PidTagAttachFilename
) 中使用内容类型
映射的扩展名，PR_ATTACH_EXTENSION (
PidTagAttachExtension
) 属性。
RFC 821 正式弃用
了 name
参数。 随着标准的发展，Microsoft 将考虑为附加文件名指定备用映射。
出站附加消息以内容类型的形式发送：附加消息中的
message/rfc822
消息在其适当位置以递归方式编码。 使用
Content-Type： multipart/digest
的入站消息内容部分也会映射到嵌入的消息。
如果在对邮件内容进行编码时使用带有 TNEF 的 uuencode，则所有附件属性和内容都在 TNEF 流中。 TNEF 本身是名为 Winmail.dat 的单个二进制附加文件，按照没有 TNEF 的 Uuencode 所述进行编码。
如果在不使用 TNEF 的情况下使用 uuencode，则所有附加文件都被视为二进制文件和 uuencoded，在消息文本之后。 文件名位于 uuencode 标头中：
begin 0755 Winmail.dat
...数据。。。
附加的消息将文本化为消息文本。 附加消息的层次结构始终平展;也就是说，附加消息中的消息将拉出到顶层。
将丢弃嵌入的 OLE 对象。
附件呈现位置在 TNEF
中使用属性PR_ATTACH_RENDERING (
PidTagAttachRendering
) 以字面方式传输。 如果未使用 TNEF，它们将丢失。 没有呈现位置的传入附件 (包括当没有 TNEF 时) 其呈现位置设置为0xFFFFFFFF，即邮件文本中没有位置。
Internet 邮件属性到 MAPI 属性的映射
