有关 MIME 和在 Exchange 2000 Server 和 Exchange Server 2003 中的内容转换的常见问题

文章翻译 文章翻译
文章编号: 836555 - 查看本文应用于的产品
展开全部 | 关闭全部

概要

本文包括有关 MIME 标准并使不同的邮件系统一起工作的编码方法的常见问题的解答。本文简要介绍了如何排除故障乱码或不可读的邮件消息,在 Microsoft Exchange 环境中。

更多信息

Q1: 什么是电子邮件的格式?

A1: Internet 电子邮件按照 RFC 2822 中定义的格式标准。一条消息是由标头字段和正文组成。 标头字段统称为被命名为"标题"的消息。在邮件的正文是可选的。可以发送一条消息,但不包括一个正文,但不是标头。

标头包含行具有特殊的语法的字符的序列,如在 RFC 2822 格式标准中定义。正文中包含的字符,请按照页眉并通过一个空的行 (也就是具有执行任何操作之前将回车的行) 和 $ 换行 [CRLF] 从标头分隔的序列。

标头字段是名称的行组成的一个字段后, 跟英文冒号 (:),跟一个字段正文,然后由一个 CRLF 结束。字段名称必须是可打印 US-ASCII 字符组成 (也就是字符有 33 和 126 (含) 之间的值的),冒号除外。作为分隔字符使用冒号。

字段正文可以由该 CRLF 除外的任何 US-ASCII 字符构成。但是,字段正文可能包含一个 CRLF 在标头 折叠展开 中使用时。折叠是当,为方便起见,一行出现在多行上时。unfolding 是这样的相反。所有字段主体必须都遵循以下语法 3 和 4 的 RFC 2822 格式标准的各部分所述。

在邮件正文可能包含一个或多个节。每个正文部分被分隔的边界。边界参数是两个连字符 (-) 开头的文本字符串。

Q2: 什么是 MIME?

A2: MIME 是一种标准,它可用于在单个邮件中包括各种类型的内容。MIME 将扩展以包括文本和非文本的多个内容的邮件消息的简单邮件传输协议 (SMTP) 格式。该消息的部分可能是图像音频,或不同字符中的文本设置。标准的 MIME 派生出 rfc 2821 和 2822年等。

Q3: Exchange 如何处理 MIME?

A3: 有 Exchange 中执行内容转换的三个主要组件:
  • IMAIL 组件是将 Internet 邮件转换为 MAPI 的核心组件 / 交换格式,反之亦然。它还会检查该消息的完整性。
  • EXMIME 组件负责翻译 Exchange 的内部对象表示形式中的 Internet 邮件并生成 MIME 格式的邮件。
  • RFHTML 组件将转换为 HTML,反之亦然,Microsoft Outlook 客户端上的设置和 $ 在 Exchange Server 计算机上的设置的多信息文本格式 (RTF) 消息。

Q4: 什么是 MIME 格式的电子邮件的最小要求?

A4: MIME 格式的电子邮件通常会有一个标头和正文。一个至少 MIME 邮件必须有一个标头。正文是可选的。在标题节包括 MIME 版本 1.0 标头 (每个邮件 RFC 2822 中定义一个)。

正文部分包括:
  • 内容类型 (这是可选的。默认值是文本/纯,RFC 2822 5.2 中定义)。
  • 内容传送编码标头 (这是可选的。默认值是 7 位 RFC 2822 6.1 中定义。
  • 内容处理标头 (这是可选)。
  • 内容 ID (这是可选)。


Q5: 什么是 MIME 版本标头?

A5: MIME 版本标头字段表示 MIME 格式的邮件。发送的邮件从早期的软件不支持 MIME 不具有此字段。 邮件客户端使用此字段的缺勤非 MIME 邮件邮件加以区别。

Q6: 什么是内容类型标头?

A6: 若要在字段中指定类型和子类型的数据使用内容类型域。

某些标头类型是多部分/混合、 多部分/备选、 文本/纯、 文本/html、 应用程序/applefile、 应用程序/毫秒-tnef 和应用程序/八位字节的流。

Q7: 什么是内容传送编码?

A7: 其他邮件系统以不同方式,处理数据和某些较早的邮件系统无法处理多媒体数据。

若要解决的多媒体数据将无法处理系统,编码方案用于将数据转换为统一的 7 位格式。当收件人接收邮件时,将数据还原到其原始格式。内容传送编码格式的一些示例包括:
  • 用引号引起来的可打印
  • Base64
  • 8 位
  • 7 位
  • 二进制


Q8: 方法在 Exchange 5.5 中传送编码实现?

A8: Exchange 5.5 编码用引号引起来的可打印的格式或根据需要的 7 位格式。此外,Exchange 5.5 编码 base64 格式的邮件,如果 25%的消息由组成的 8 位字符 (也就是 US-ASCII 区域之外的字符)。这仅适用于邮件正文 ; 附件始终是 base64 编码。

Q9: 方法在 Exchange 2000 Server 中传送编码实现?

A9: 路由组边界和 SMTP 目标目标确定 Exchange 2000 Server 如何对邮件进行编码。Exchange 2000 将编码为带引号的可打印或 7 位或传输中性封装格式 (TNEF) 发送两个服务器/收件人之间不同的路由组中和到 Internet 时。

在二进制或摘要 TNEF,发送到同一个路由组中的收件人/服务器时,Exchange 2000 Server 将进行编码。

Q10: Microsoft Exchange Server 2003 中实现了传送编码如何?

A10: 当路由组边界,Exchange 和 SMTP 目标目标还确定 Exchange Server 2003 如何对邮件进行编码。

在混合的模式 Exchange Server 2003 将编码为带引号的可打印或 7 位 (TNEF 格式) 发送两个服务器/收件人之间不同路由组中和到 Internet 时。

本机的模式 Exchange Server 2003 编码在二进制 (摘要 TNEF) 时发送到相同或其他路由组中的收件人/服务器。

Q11: 什么是内容处理标头?

A11:此标头标识是否一节将显示作为附件或邮件正文中显示。

Q12: Exchange 如何处理附件?

A12:Exchange Server 2003 将 Internet 的邮件保存在其本机格式中。这意味着如果在邮件被阅读来自 Internet 的格式识别客户端 (如 Outlook Express,它们将会呈现以原始格式。

但是,当邮件从 MAPI 客户端读取,IMAIL 将 Internet 格式中的相应元素映射到 MAPI 属性。事实上,甚至的 Internet 邮件传递到邮箱之前,必须从 Internet 邮件提升的 MAPI 属性的最小集合,其中包括 PR_SENT_REPRESENTING、 PR_SUBJECT 和收件人表。

从 Internet 格式按需计算 (如 PR_BODY、 PR_HTML 和 PR_ATTACH_DATA_BIN 其他 MAPI 属性。当 MAPI 客户端第一次请求消息时,将发生转换。Exchange 2000 服务器然后将升级为 MAPI 格式这些本机的 MIME 属性。

内容转换在 Exchange Server 2003,呈现给客户端的入站的 MIME 消息时,期间 IMAIL 执行以下操作:
  1. IMAIL 检查输入完整的文件的名称 (Nameext) MIME 标头中。如果找到一个名称,则使用该文件的名称。
  2. IMAIL 检查输入部分文件的名称。如果找到一个 IMAIL 查看
    HKEY_CLASSES_ROOT/MIME/Database/content-type
    子项,若要将文件扩展名映射到内容类型。如果找到匹配的内容类型,则该附件以添加该扩展名。如果找到不匹配的内容类型,则使用该部分的文件名。
  3. 如果没有文件的名称在内容类型或内容处置标头中指定的 IMAIL 搜索匹配的内容类型。如果找到一个附件将具有 ATT name 的格式 extext 其中是与此内容类型相关联的扩展名。如果找到不匹配的内容类型,则使用".att"的扩展。Exchange 2000 Server 需要一个内容类型标头中的文件名称。


Q13: 什么是完整的消息的结构?

A13:下面是一个示例所示的所有标题都带有完整邮件。通常,收件人将看到仅正文部分。在方括号中添加了注释。

Received: from SMTP server (server1.example1.com IP address) 

by Receiver SMTP version 1.0 (server2.example2.com IP address); 

Mon, 28 Oct 2002 08:42:42 -0500 (EST)

Message-ID: <006@example1.com>

From: "User1" <user1@example1.com> (RFC 2822 sender) 

To: "User2" user2@example2.com> (RFC 2822 recipient) 

Subject: A test message to see if you can see me now!

Date: Mon, 8 Nov 2002 13:46:54 +0100

MIME-Version: 1.0

Content-Type: multipart/mixed; 
boundary="----=_NextPart_000_005A_01C27E88.79B98A90"

X-Priority: 3

Return-Path: user1@domain1.com

X-OriginalArrivalTime: 28 Oct 2002 13:45:00.0541 (UTC) 
FILETIME=[35F0A2D0:01C27E88]

 

This is a multi-part message in MIME format (If you see this in the message 
body, there is a problem. Notice there is no space or CRLF in the headers in the previous text. There must be no space until the message body itself)

 

This message is in MIME format. Since your mail reader does not understand this 
format, some or all of this message may not be legible. (If you see this in the 
message body, there is a problem)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary) 

 

Content-Type: text/plain;

charset="iso-8859-1"

Content-Transfer-Encoding: 7bit

 

Can you see me now??! (This is the text of the message. You see this in your mail client.)

 

------=_NextPart_000_005A_01C27E88.79B98A90 (Boundary. See Multipart/Mixed 
definition earlier in this article.) 

Content-Type: image/jpeg;

name="Haloweenpictures.jpg"

Content-Transfer-Encoding: base64 (All attachments in Exchange 2000 Server are encoded by using base64 and bloat 33%.)  

Content-Disposition: attachment;

filename="Haloweenpictures.jpg"

 

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB  (Base64 data in raw format. This is the picture being encoded in binary format; to 
be repackaged later back as a picture.)

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB/9j/4AAQSkZJRgABAQEBLAEsAAD/2wB

------=_NextPart_000_005A_01C27E88.79B98A90--


Q14: 为何执行邮件地址出现在我的邮件的正文中?

A14:在第一个 CRLF CRLF MIME 流中表示邮件正文的开始处。因此,如果两个标头之间有一个 <CRLF><CRLF>序列客户端 (Outlook 或 Microsoft Outlook Express) 将显示一条消息,乱码。

第一个 CRLF CRLF 将从邮件正文分开 Internet 邮件头。这些标题称为 P1 邮件头。P1 邮件头是信封邮件头,而不会包含在由 IMAIL 处理的 Internet 邮件。

Exchange 可能会被转发到智能主机、 内容扫描设备、 病毒墙上或防火墙。第三方防火墙软件有时可能会扭曲消息。

您可能还会收到通过 UNIX 系统、 通过一个防火墙或通过病毒墙上的电子邮件。另外,第三方内容扫描设备可能会在网络上。如果在网络中有类似的应用程序或设备验证收件人限制。避免使用此类设备或应用程序中的诊断测试。

Q15: 为什么并出现在我的邮件中问号?

A15:如果在邮件中显示问号,则意味着系统不知道如何转换包含在消息中的某些 ANSI 或 Unicode 字符。您必须确保客户端查看邮件时已安装的匹配入站的字符集的代码页。例如对于确保 Windows 工作站具有日语区域设置以查看邮件,在日语中编写的安装。

Q16: 为什么有困难打开 HTML 邮件和我在我的应用程序日志中看到事件 12002 和 12003?

A16:这些应用程序日志事件来源 Exchange 信息存储,并内容转换错误。一些这些消息可以忽略,并接收的邮件没有任何影响。但是,如果您看到的许多应用程序日志中的这些邮件,请参阅客户端是否已打开 HTML 邮件的问题。

这是否大小写建立更多的诊断信息,类似的问题消息的应用程序和系统日志的副本的副本的服务包版本,然后进行故障排除。

Q17: 为什么我有时看消息正文作为附件?

A17:您必须建立关于消息的源的信息。您必须建立在源服务器的所有详细信息。您必须检查发件人是否在 UNIX 网络上。有关此问题的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
323482 Exchange 会显示使用"内联"MIME 内容处理标头作为附件的邮件
Q18: 为什么我看这是一个多部分消息,在或该邮件中 MIME 格式"电子邮件的正文中? MIME 格式。

A18:您可能会看到文本正文中下列选项之一:
  • 这是 MIME 格式的多部分消息。
  • 该邮件是 MIME 格式。因为您的邮件阅读程序不能理解此格式,部分或全部此消息可能无法清晰显示。

此文本将被插入第一个边界之前、 通常出现在每个多部分消息和看不到客户端,除非有电子邮件格式有问题。例如对于硬盘分行符可能已插入邮件中错误的位置中。

若要此问题的疑难解答打开邮件存档在 Microsoft Exchange Internet 邮件服务。若要打开存档的邮件,使用 Exchange Server 2003 存档接收器实用程序、 将邮件另存为.eml 或.pst,然后执行详细分析。有关存档接收器功能的详细信息,请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
307798存档接收器实用程序是在 Service Pack 2 中可用
Q19: 为什么我的邮件的大小大于我所的期望约 33%,为什么它 base64 编码即使它不包含附件?

A19:如果您使用下列字符集,则会发生此行为:
  • 日语 shift-jis
  • KOR
  • 日语 EUC
  • 朝鲜语 ISO-2202年-KR
  • 台湾 ISO-2202年-台湾
  • 中文 ISO-2202年-CN
  • 中文 HZ_GB,Big5,gb18030 字符


Q20: 其他常见的和已知的问题是什么?

A20:可能会出现乱码,从一台 Exchange Server 2003 服务器到另一个被中继的消息,该邮件的收件人可能会显示在邮件的正文中。

例如对于这可能会出现一条消息,从 Internet 传递到一个入站的 Internet Exchange Server 2003 计算机,然后再到另一台 Exchange Server 2003 计算机中。
消息在入站 Internet Exchange Server 2003 上,可能会正确显示,但在后端 Exchange 服务器上出现乱码。如果减少了对邮件的收件人数,也可能会更改这些症状。 由于某些原因可以出现此问题,但两个最常见的原因是:
  • RFC 2822 邮件头中一行,而不是 998 字符在行中有多个 1000年或 1024年个字符。有关详细的信息,请参阅注释 (rfc) 2822年。要这样,请访问下面的 Internet 工程任务组 (IETF) 的网站:
    http://www.ietf.org/rfc/rfc2822.txt?number=2822
    如果通过使用二进制数据或通过 分块,将邮件中继到 Exchange Server 2003 的计算机,您可能会遇到此问题。分块是扩展为支持以块的形式发送的数据的 SMTP 格式。

    当 Exchange Server 2003 收到一条消息,在行中有多个 998 字符时,SMTP 服务将分析标头,并发现在行的长度超过 1000年个字符。然后,SMTP 服务假定这行不是页眉部分,在 $ 正文中包括该。

    SMTP 服务在 Exchange Server 计算机上的然后将重写其自身的页眉包括消息 ID 和一个 DATE 标头后面空一行或一 CRLF。
  • 行长度限制。有许多的实现,依照的 RFC 2821 传输要求不接受了每行,包括该 CRLF 1000 个以上字符的邮件。因此,邮件应用程序必须不创建此类消息。若要变通解决此问题,关闭 Exchange Server 计算机上的 ESMTP 谓词 (或分块) 功能,并强制 Exchange Server 计算机,若要设置格式时邮件被中继,设置格式中典型的 SMTP 邮件。有关详细的信息请单击下面的文章编号,以查看 Microsoft 知识库中相应的文章:
    257569如何关闭 ESMTP 谓词在 Exchange 2000 Server 和 Exchange Server 2003 中
    821733如果收件人行中超过 1,022 字符传入邮件是乱码

参考

ARPA Internet 文本邮件的格式标准的详细信息,请参阅 RFC 822。要执行此操作,请访问下面的 IETF 网站:
http://www.ietf.org/rfc/rfc0822.txt?number=822
有关 MIME 的详细信息,请参阅 RFC 2045 2046年、 2047年、 2048,和 2049年。此,请访问下面的 IETF 网站:
http://www.ietf.org/rfc/rfc2045.txt?number=2045
http://www.ietf.org/rfc/rfc2046.txt?number=2046
http://www.ietf.org/rfc/rfc2047.txt?number=2047
http://www.ietf.org/rfc/rfc2048.txt?number=2048
http://www.ietf.org/rfc/rfc2049.txt?number=2049
有关内容处理标头字段的详细信息,请参阅 RFC 2183。要这样,请访问下面的 IETF 网站:
http://www.ietf.org/rfc/rfc2183.txt?number=2183

属性

文章编号: 836555 - 最后修改: 2007年10月25日 - 修订: 3.4
这篇文章中的信息适用于:
  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Server 标准版
关键字:?
kbmt kbfaq kbinfo KB836555 KbMtzh
机器翻译
注意:这篇文章是由无人工介入的微软自动的机器翻译软件翻译完成。微软很高兴能同时提供给您由人工翻译的和由机器翻译的文章, 以使您能使用您的语言访问所有的知识库文章。然而由机器翻译的文章并不总是完美的。它可能存在词汇,语法或文法的问题,就像是一个外国人在说中文时总是可能犯这样的错误。虽然我们经常升级机器翻译软件以提高翻译质量,但是我们不保证机器翻译的正确度,也不对由于内容的误译或者客户对它的错误使用所引起的任何直接的, 或间接的可能的问题负责。
点击这里察看该文章的英文版: 836555
Microsoft和/或其各供应商对于为任何目的而在本服务器上发布的文件及有关图形所含信息的适用性,不作任何声明。 所有该等文件及有关图形均"依样"提供,而不带任何性质的保证。Microsoft和/或其各供应商特此声明,对所有与该等信息有关的保证和条件不负任何责任,该等保证和条件包括关于适销性、符合特定用途、所有权和非侵权的所有默示保证和条件。在任何情况下,在由于使用或运行本服务器上的信息所引起的或与该等使用或运行有关的诉讼中,Microsoft和/或其各供应商就因丧失使用、数据或利润所导致的任何特别的、间接的、衍生性的损害或任何因使用而丧失所导致的之损害、数据或利润不负任何责任。

提供反馈

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com