Преобразование содержимогоContent conversion

Применимо к: Exchange Server 2013Applies to: Exchange Server 2013

Преобразование содержимого — это процесс правильного форматирования сообщения для каждого получателя.Content conversion is the process of correctly formatting a message for each recipient. Решение о выполнении преобразования контента для сообщения зависит от места назначения и формата обрабатываемого сообщения.The decision to perform content conversion on a message depends on the destination and format of the message being processed. В Microsoft Exchange Server 2013 существует два разных типа преобразования контента:In Microsoft Exchange Server 2013, there are two different kinds of content conversion:

  • Преобразование сообщений для внешних получателей: этот тип преобразования контента включает параметры преобразования формата TNEF и параметры кодирования сообщений для внешних получателей.Message conversion for external recipients: This type of content conversion includes the Transport Neutral Encapsulation Format (TNEF) conversion options and message encoding options for external recipients. Сообщения, отправляемые получателям в организации Exchange, не требуют такого типа преобразования контента.Messages sent to recipients inside the Exchange organization don't require this type of content conversion. Этот тип преобразования контента обрабатывается классификатором в службе транспорта на сервере почтовых ящиков.This type of content conversion is handled by the categorizer in the Transport service on Mailbox server. Классификация каждого полученного сообщения выполняется после того как сообщение помещено в очередь передачи.Categorization on each message happens after a newly arrived message is put in the Submission queue. Перед помещением сообщения в очередь доставки для него (помимо разрешения получателей и разрешения маршрутизации) выполняется преобразование содержимого.In addition to recipient resolution and routing resolution, content conversion is performed on the message before the message is put in a delivery queue. Если одно сообщение адресовано нескольким получателям, классификатор определяет соответствующее кодирование для каждого получателя сообщения.If a single message contains multiple recipients, the categorizer determines the appropriate encoding for each message recipient. При трассировке преобразования содержимого не фиксируются ошибки преобразования содержимого, обнаруженные классификатором в ходе преобразования сообщений, отправляемых внешним получателям.Content conversion tracing doesn't capture any content conversion failures that the categorizer encounters as it converts messages sent to external recipients.

  • Преобразование MAPI для внутренних получателей: этот тип преобразования контента обрабатывается службой транспорта почтовых ящиков.MAPI conversion for internal recipients: This type of content conversion is handled by the Mailbox Transport service. Служба передачи почтовых ящиков используется на серверах почтовых ящиков для передачи сообщений между базами данных сообщений на локальном сервере и службой передачи на серверах почтовых ящиков.The Mailbox Transport service exists on Mailbox servers to transmit messages between mailbox databases on the local server, and the Transport service on Mailbox servers. А именно, служба отправки и передачи почтовых ящиков передает сообщения из папки "Исходящие" отправителя службе передачи на сервере почтовых ящиков.Specifically, the Mailbox Transport Submission service transmits messages from the sender's Outbox to the Transport service on a Mailbox server. Служба отправки и передачи почтовых ящиков передает сообщения от службы передачи на сервере почтовых ящиков в папку "Входящие" получателя.The Mailbox Transport Delivery service transmits messages from the Transport service on a Mailbox server to the recipient's Inbox. Служба отправки и передачи почтовых ящиков преобразует все исходящие сообщения с формата MAPI, а служба доставки и передачи почтовых ящиков преобразует все входящие сообщения в формат MAPI.The Mailbox Transport Submission service converts all outgoing messages from MAPI and the Mailbox Transport Delivery service converts all incoming messages to MAPI. Ошибки преобразования MAPI регистрируются при трассировке преобразования содержимого.Content conversion tracing captures these MAPI conversion failures. Дополнительные сведения см. For more information, see Content conversion tracing.

В этом разделе описываются параметры преобразования сообщений для внешних получателей.This topic explains the message conversion options for external recipients.

Форматы сообщений Exchange и OutlookExchange and Outlook message formats

В следующем списке описываются основные форматы сообщений, доступные в Exchange и Microsoft Outlook:The following list describes the basic message formats available in Exchange and Microsoft Outlook:

  • Обычный текст: в обычном текстовом сообщении используется только текст US – ASCII, как описано в документе RFC 2822.Plain text: A plain text message uses only US-ASCII text as described in RFC 2822. В сообщении не используются разные шрифты или другие способы форматирования текста.The message can't contain different fonts or other text formatting. Два возможных формата обычного текстового сообщения:The following two formats can be used for a plain text message:

    • Заголовки и тело сообщения состоят из текстовых знаков US-ASCII. Вложения кодируются с использованием алгоритма Uuencode («Unix-to-Unix encoding»). Данный алгоритм представляет собой кодировку Unix-to-Unix и позволяет хранить двоичные вложения в тексте сообщения электронной почты с использованием текстовых символов US-ASCII.The message headers and the message body are composed of US-ASCII text. Attachments must be encoded by using Uuencode. Uuencode represents Unix-to-Unix encoding and defines an encoding algorithm to store binary attachments in the body of an email message by using US-ASCII text characters.

    • Для сообщения используется кодирование MIME, при этом параметр Content-Type имеет значение text/plain, а параметр Content-Transfer-Encoding — значение 7bit для текстовых частей составного сообщения.The message is MIME-encoded with a Content-Type value of text/plain, and a Content-Transfer-Encoding value of 7bit for the text parts of a multipart message. Для любых текстовых вложений используется кодирование Quoted Printable или Base64.Any message attachments are encoded by using Quoted-printable or Base64 encoding. По умолчанию при создании и отправке сообщения в формате обычного текста в Outlook сообщение кодируется в кодировке MIME с типом содержимого text/plain.By default, when you compose and send a plain text message in Outlook, the message is MIME-encoded with a Content-Type value of text/plain.

  • HTML: сообщение в формате HTML поддерживает форматирование текста, фоновые изображения, таблицы, точки маркеров и другие графические элементы.HTML: An HTML message supports text formatting, background images, tables, bullet points, and other graphical elements. Для сохранения этих элементов форматирования сообщения в формате HTML должны кодироваться в кодировке MIME.By definition, an HTML-formatted message must be MIME-encoded to preserve these formatting elements.

  • Форматированный текст (RTF): RTF поддерживает форматирование текста и другие графические элементы.Rich text format (RTF): RTF supports text formatting and other graphical elements. Формат RTF является синонимом формата TNEF.RTF is synonymous with TNEF. Формат TNEF и RTF можно использовать в качестве взаимозаменяемых.TNEF and RTF can be used interchangeably. Формат RTF-сообщений полностью отличается от формата документов в формате RTF, доступного в Microsoft Word.The rich text message format is completely different from the rich text document format available in Microsoft Word.

    Сообщения в формате RTF поддерживаются только Outlook и несколькими другими почтовыми клиентами MAPI.Only Outlook and a few other MAPI email clients understand RTF messages.

  • TNEF: формат инкапсуляции отнейтральной к транспорту относится к формату Майкрософт для инкапсуляции свойств сообщения MAPI.TNEF: The Transport Neutral Encapsulation Format is a Microsoft-specific format for encapsulating MAPI message properties. Сообщение в формате TNEF содержит сообщение в виде обычного текста и вложение, в которое упакована исходная отформатированная версия сообщения.A TNEF message contains a plain text version of the message and an attachment that packages the original formatted version of the message. Обычно такое вложение имеет название Winmail.dat.Typically, this attachment is named Winmail.dat. Вложение Winmail.dat включает следующие сведения:The Winmail.dat attachment includes the following information:

    • Исходная отформатированная версия сообщения, включая, например, шрифты, размеры текста и цвета текстаOriginal formatted version of the message, including, for example, fonts, text sizes, and text colors

    • Объекты OLE, включая, например, внедренные изображения или документы Microsoft Office EmbeddedOLE objects, including, for example, embedded pictures or embedded Microsoft Office documents

    • Специальные функции Outlook, включая, например, настраиваемые формы, кнопки голосования или приглашения на собранияSpecial Outlook features, including, for example, custom forms, voting buttons, or meeting requests

    • обычные вложения, которые имелись в исходном сообщенииRegular message attachments that were in the original message

      Получающееся обычное текстовое сообщение может быть представлено в следующих форматах:The resulting plain text message can be represented in the following formats:

    • Сообщение, удовлетворяющее спецификации RFC 2822, состоящее только из текста US – ASCII с вложением Winmail. dat, закодированным в формате UUEncodeRFC 2822-compliant message composed of only US-ASCII text with a Winmail.dat attachment encoded in Uuencode

    • составное сообщение с кодированием MIME и вложением Winmail.dat.Multipart MIME-encoded message that has a Winmail.dat attachment

      Клиент электронной почты, совместимый с MAPI, который полностью понимает формат TNEF, например Outlook, обрабатывает вложение Winmail. dat и отображает содержимое исходного сообщения без отображения вложения Winmail. dat.A MAPI-compliant email client that fully understands TNEF, such as Outlook, processes the Winmail.dat attachment and displays the original message content without ever displaying the Winmail.dat attachment. Почтовый клиент, не поддерживающий формат TNEF, может представить сообщение TNEF несколькими способами, которые описаны ниже.An email client that doesn't understand TNEF may present a TNEF message in any of the following ways:

    • Отображается обычная текстовая версия сообщения, при этом сообщение содержит вложение с именем Winmail.dat, Win.dat или каким-либо другим универсальным именем, таким как Attnnnnn.dat или Attnnnnn.eml, где nnnnn — случайное число.The plain text version of the message is displayed, and the message contains an attachment named Winmail.dat, Win.dat, or some other generic name such as Attnnnnn.dat or Attnnnnn.eml where the nnnnn placeholder represents a random number.

    • Отображается обычная текстовая версия сообщения.The plain text version of the message is displayed. Вложение TNEF пропускается или удаляется.The TNEF attachment is ignored or removed. В результате отображается обычное текстовое сообщение.The result is a plain text message.

    • Серверы обмена сообщениями, поддерживающие формат TNEF, можно настроить так, чтобы они удаляли вложения TNEF из входящих сообщений.Messaging servers that understand TNEF can be configured to remove TNEF attachments from incoming messages. В результате остается обычное текстовое сообщение.The result is a plain text message. Кроме того, некоторые почтовые клиенты, например Microsoft Outlook Express, могут не распознать формат TNEF, а также распознавать и пропускать вложения в формате TNEF.Moreover, some email clients such as Microsoft Outlook Express may not understand TNEF, but recognize and ignore TNEF attachments. В результате отображается обычное текстовое сообщение.The result is a plain text message.

      Существуют программы сторонних разработчиков, с помощью которых можно преобразовывать вложения Winmail.dat.There are third-party utilities that can help convert Winmail.dat attachments.

      Формат TNEF поддерживается во всех версиях Exchange, начиная с Exchange Server версии 5.5.TNEF is understood by all versions of Exchange since Exchange Server version 5.5.

  • Сводный формат инкапсуляции протокола инкапсуляции (STNEF): STNEF ЭКВИВАЛЕНТен формату TNEF.Summary Transport Neutral Encapsulation Format (STNEF): STNEF is equivalent to TNEF. Формат STNEF эквивалентен формату TNEF, но кодирование сообщений в формате STNEF отличается от кодирования сообщений в формате TNEF.However, STNEF messages are encoded differently than TNEF messages. В частности, сообщения STNEF всегда кодируются в кодировке MIME и всегда имеют двоичное значение для передачи содержимого.Specifically, STNEF messages are always MIME-encoded and always have a Content-Transfer-Encoding value of Binary. Таким образом, у этих сообщений нет представления в виде обычного текста, а в тексте сообщения нет отдельного вложения Winmail.dat.Therefore, there's no plain text representation of the message, and there's no distinct Winmail.dat attachment contained in the body of the message. Все сообщение представлено с использованием только двоичных данных.The whole message is represented by using only binary data. Сообщения с двоичным значением "передача содержимого" можно передавать только между серверами обмена сообщениями SMTP, поддерживающими и объявляющие расширения SMTP BINARYMIME и блоки SMTP, как определено в RFC 3030.Messages that have a Content-Transfer-Encoding value of Binary can only be transferred between SMTP messaging servers that support and advertise the BINARYMIME and CHUNKING SMTP extensions as defined in RFC 3030. Сообщения всегда передаются между SMTP-сообщениями с помощью команды BDAT вместо стандартной команды данных.The messages are always transferred between SMTP messaging by using the BDAT command, instead of the standard DATA command.

    Формат STNEF поддерживается во всех версиях Exchange, начиная с Exchange 2000. Формат STNEF автоматически используется для всех сообщений, передаваемых между серверами Exchange в организации с момента появления основного режима Exchange Server 2003.STNEF is understood by all versions of Exchange since Exchange 2000. STNEF is automatically used for all messages transferred between Exchange servers in the organization since native mode Exchange Server 2003.

    Exchange никогда не отправляет сообщения в формате STNEF внешним получателям. Получателям за пределами организации Exchange можно отправлять сообщения только в формате TNEF.Exchange never sends STNEF messages to external recipients. Only TNEF messages can be sent to recipients outside the Exchange organization.

Параметры преобразования содержимого для внешних получателейContent conversion options for external recipients

Параметры преобразования содержимого, которые можно задать в организации Exchange для внешних получателей, делятся на следующие категории:The content conversion options that you can set in an Exchange organization for external recipients can be described in the following categories:

  • Параметры преобразования формата TNEF. Эти параметры преобразования определяют, следует ли сохранять формат TNEF в сообщениях, открывая организацию Exchange.TNEF conversion options: These conversion options specify whether TNEF should be preserved or removed from messages that leave the Exchange organization.

  • Параметры кодирования сообщений: в этих параметрах задаются параметры кодирования сообщений, такие как кодировки MIME и не MIME, кодировка сообщений и форматы вложений.Message encoding options: These options specify message encoding options, such as MIME and non-MIME character sets, message encoding, and attachment formats.

Эти параметры преобразования и кодирования не зависят друг от друга. Например, то, разрешено ли отправлять сообщения в формате TNEF за пределы организации Exchange, не связано с параметрами кодирования MIME или кодирования в виде обычного текста для этих сообщений.These conversion and encoding options are independent of one another. For example, whether TNEF messages can leave the Exchange organization isn't related to the MIME encoding settings or plain text encoding settings of those messages.

Вы можете выбрать необходимое преобразование содержимого на различных уровнях организации Exchange, как описано в следующем списке:You can specify the content conversion at various levels of the Exchange organization as described in the following list:

  • Параметры удаленного домена: удаленные домены определяют параметры передачи исходящих сообщений между организацией Exchange и внешними доменами..Remote domain settings: Remote domains define the settings for outgoing message transfers between the Exchange organization and external domains.. Даже если записи удаленного домена не создаются для конкретных доменов, существует предварительно определенный удаленный домен с именем Default, который применяется ко всем удаленным адресным пространствам (*).Even if you don't create remote domain entries for specific domains, there's a predefined remote domain named Default that applies to all remote address spaces (*).

  • Параметры почтового пользователя ипочтового контакта: почтовые пользователи и почтовые контакты похожи на внешние адреса электронной почты и содержат сведения о пользователях за пределами организации Exchange.Mail user and mail contact settings: Mail users and mail contacts are similar because both have external email addresses and contain information about people outside the Exchange organization. Основное отличие состоит в том, что пользователи почты имеют учетные записи, которые можно использовать для входа в домен Active Directory и для доступа к ресурсам в Организации.The main difference is mail users have accounts that can be used to log on to the Active Directory domain and access resources in the organization.

  • Параметры Outlook: в Outlook можно настроить параметры форматирования и кодирования сообщений, описанные в следующем списке:Outlook settings: In Outlook, you can set the message formatting and encoding options described in the following list:

    • Формат сообщения: вы можете задать формат сообщений по умолчанию для всех сообщений.Message format: You can set the default message format for all messages. Формат по умолчанию для всех сообщений можно переопределять при создании конкретного сообщения.You can override the default message format as you compose a specific message.

    • Формат сообщений Интернета: вы можете указать, будут ли сообщения TNEF отправляться удаленным получателям или они сначала преобразуются в более совместимый формат.Internet message format: You can control whether TNEF messages are sent to remote recipients or whether they are first converted to a more compatible format. Можно также задать различные параметры кодирования для сообщений, отправляемых удаленным получателям.You can also specify various message encoding options for messages sent to remote recipients. Эти параметры не применяются к сообщениям, отправляемым получателям в организации Exchange.These settings don't apply to messages sent to recipients in the Exchange organization.

    • Формат сообщений для получателей в Интернете: вы можете указать, отправляются ли сообщения TNEF определенным получателям или они сначала преобразуются в более совместимый формат.Internet recipient message format: You can control whether TNEF messages are sent to specific recipients or whether they are first converted to a more compatible format. Вы можете задать параметры преобразования для определенных контактов в папке "Контакты", а также переопределить параметры преобразования для определенного получателя в полях "Кому", "копия" или "Скрытая копия" по мере создания сообщения.You can set the conversion options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. Эти параметры преобразования недоступны для получателей в организации Exchange.These conversion options aren't available for recipients in the Exchange organization.

    • Параметры кодирования сообщений для получателей через Интернет: вы можете управлять параметрами кодировки MIME или обычного текста для определенных контактов в папке "Контакты", а также можно переопределить параметры преобразования для определенного получателя в полях "Кому", "копия" или "Скрытая копия" составление сообщения.Internet recipient message encoding options: You can control the MIME or plain text encoding options for specific contacts in your Contacts folder, and you can override the conversion options for a specific recipient in the To, Cc, or Bcc fields as you compose a message. Эти параметры преобразования недоступны для получателей в организации Exchange.These conversion options aren't available for recipients in the Exchange organization.

    • Международные параметры: вы можете управлять кодировками, используемыми в сообщениях.International options: You can control the character sets used in messages.

Параметры преобразования TNEFTNEF conversion options

Параметры преобразования TNEF можно указать на следующих уровнях:You can specify the TNEF conversion options at the following levels:

  • Параметры удаленных доменов;Remote domain settings

  • Параметры пользователей почты и почтового контактов.Mail user and mail contact settings

  • Параметры Outlook, в том числе:Outlook settings, including:

    • формат сообщений;Message format

    • формат сообщений Интернета;Internet message format

    • Формат сообщений Интернета для получателейInternet recipient message format

Параметры кодирования сообщенийMessage encoding options

Вы можете указать параметры кодирования сообщений на следующих уровнях:You can specify the message encoding options at the following levels:

  • Параметры удаленных доменов;Remote domain settings

  • Параметры пользователей почты и почтового контактов.Mail user and mail contact settings

  • Параметры Outlook, в том числе:Outlook settings, including:

    • формат сообщений;Message format

    • Сообщение через ИнтернетInternet message

    • Формат сообщений Интернета для получателейInternet recipient message format

    • параметры кодировок.Message character set encoding options

Подробную информацию можно узнать в статье Параметры кодирования сообщений.For detailed information, see Message encoding options.

Понимание структуры сообщений электронной почтыUnderstanding the structure of email messages

Чтобы лучше понимать параметры преобразования содержимого для внешних получателей, необходимо понимать структуру сообщений электронной почты. Для написания и отправки сообщений электронной почты в основании сообщения SMTP обычное текстовое сообщение в 7-разрядной кодировке US-ASCII. Стандартное SMTP-сообщение состоит из описанных ниже элементов.To better understand the content conversion options for external recipients, you need to understand the structure of email messages. An SMTP message is based on plain 7-bit US-ASCII text to compose and send email messages. A standard SMTP message consists of the following elements:

  • Конверт сообщения: конверт сообщения ОПРЕДЕЛЕН в RFC 2821.Message envelope: The message envelope is defined in RFC 2821. Конверт сообщения содержит сведения, необходимые для передачи и доставки сообщения.The message envelope contains information required to transmit and deliver the message. Конверт сообщения никогда не отображается для получателей, так как он создается в процессе передачи сообщения и фактически не является частью самого сообщения.Recipients never see the message envelope, because it's generated by the message transmission process and isn't actually part of the message contents.

  • Содержимое сообщения: содержание сообщения определено в RFC 2822.Message contents: The message contents are defined in RFC 2822. Содержимое сообщения состоит из следующих элементов:The message contents consist of the following elements:

    • Заголовок сообщения: заголовок сообщения представляет собой коллекцию полей заголовков.Message header: The message header is a collection of header fields. Поля заголовка состоят из имени поля, двоеточия (:), тела поля и сочетания знаков возврата каретки и перевода строки (CR/LF).Header fields consist of a field name, followed by a colon (:) character, followed by a field body, and ended by a carriage return/line feed (CR/LF) character combination.

      • Имя поля может включать все печатные текстовые знаки US-ASCII за исключением двоеточия (:). В частности, знаки ASCII с 33 по 57 и с 59 по 126 включительно.A field name must be composed of printable US-ASCII text characters except the colon (:) character. Specifically, ASCII characters that have values from 33 through 57 and 59 through 126 are permitted.

      • Текст поля может включать любые знаки US-ASCII за исключением знаков возврата каретки (CR) и перевода строки (LF).A field body may be composed of any US-ASCII characters, except for the carriage return (CR) character and the line feed (LF) character. Тем не менее в тексте поля может присутствовать сочетание символов возврата каретки и перевода строки, если оно используется для развертывания заголовка.However, a field body may contain the CR/LF character combination when used in header folding. Сворачивание заголовка — это отделение одного основного текста поля заголовка к нескольким строкам, как описано в разделе 2.2.3 из RFC 2822.Header folding is the separation of a single header field body into multiple lines as described in section 2.2.3 of RFC 2822. В разделах 3 и 4 документа RFC 2822 описаны другие требования к синтаксису тела поля.Other field body syntax requirements are described in sections 3 and 4 of RFC 2822.

    • Текст сообщения: текст сообщения представляет собой набор строк символов US-ASCII, который отображается после заголовка сообщения.Message body: The message body is a collection of lines of US-ASCII text characters that appears after the message header. Заголовок и тело сообщения разделяются пустой строкой, которая завершается сочетанием знаков возврата каретки и перевода строки.The message header and the message body are separated by a blank line that ends with the CR/LF character combination. Тело сообщения может отсутствовать.The message body is optional. Ни одна строка текста в теле сообщения не может содержать более 997 знаков.Any line of text in the message body must be less than 998 characters. Знаки возврата каретки и перевода строки отмечают конец строки и могут использоваться только вместе.The CR and LF characters can only appear together to indicate the end of a line.

Если сообщение SMTP содержит элементы, отличные от обычного текста US-ASCII, для сохранения этих элементов необходимо выполнить кодирование сообщения.When SMTP messages contain elements that aren't plain US-ASCII text, the message must be encoded to preserve those elements. Способ кодирования нетекстового содержимого сообщений определен в стандарте MIME.The MIME standard defines a method of encoding content in messages that isn't text. Стандарт MIME позволяет использовать текст, представленный знаками из других кодировок, нетекстовые вложения, составные тексты сообщений и поля заголовка, представленные символами из других кодировок.MIME allows for text in other character sets, attachments without text, multipart message bodies, and header fields in other character sets. MIME определен в стандарте RFC 2045, RFC 2046, RFC 2047, RFC 2048 и RFC 2077.MIME is defined in RFC 2045, RFC 2046, RFC 2047, RFC 2048, and RFC 2077. В стандарте MIME определена совокупность полей заголовка, которые задают дополнительные атрибуты сообщения.MIME defines a collection of header fields that specifies additional message attributes. Некоторые важные поля заголовка MIME описаны в таблице ниже.The following table describes some important MIME header fields.

Важные поля заголовка MIMEImportant MIME header fields

Название поля заголовкаHeader field name Значение по умолчаниюDefault value ОписаниеDescription

MIME-VersionMIME-Version

1.01.0

Это поле заголовка является первым в сообщении, преобразованном в формат MIME.This header field is the first MIME header field that appears in a MIME-formatted message. Это поле заголовка отображается после других стандартных полей заголовка RFC 2822, но перед любыми другими полями заголовка MIME.This header field appears after the other standard RFC 2822 header fields, but before any other MIME header fields. Почтовые клиенты с поддержкой MIME используют это поле заголовка для идентификации сообщений в кодировке MIME.MIME-aware email clients use this header field to identify a MIME-encoded message. Если это поле заголовка отсутствует, почтовые клиенты с поддержкой MIME идентифицируют формат сообщения как обычный текст.When this header field is absent, MIME-aware email clients identify the message as plain text.

Content-TypeContent-Type

text/plaintext/plain

Это поле заголовка определяет тип мультимедиа содержимого сообщения в согласно спецификации RFC 2046.This header field identifies the media type of the message content as described in RFC 2046. Тип мультимедиа включает тип, подтип и один или несколько необязательных параметров, например параметр charset=, который определяет кодировку MIME.A media type consists of a type, a subtype, and one or more optional parameters, such as a charset= parameter that defines the MIME character encoding. Типы, которые начинаются с "x-", являются нестандартными.Types that begin with "x-" aren't standard. Подтипы, начинающиеся с "ВНД. " — это зависящий от поставщика.Subtypes that begin with "vnd." are vendor-specific. Служба Internet Assigned Numbers Authority (IANA) ведет список зарегистрированных типов мультимедиа.The Internet Assigned Numbers Authority (IANA) maintains a list of registered media types. Более подробную информацию можно узнать в статье типы мультимедиа MIME.For more information, see MIME Media Types.

Тип мультимедиа multipart (составной) позволяет использовать в одном сообщении несколько разделов, имеющих разные типы мультимедиа.The multipart media type allows for multiple message parts in the same message by using sections defined by different media types. Поле Content-Type может иметь различные значения, в том числе следующие: text/plain, text/html, multipart/mixed и multipart/alternative.Some Content-Type field values include text/plain, text/html, multipart/mixed, and multipart/alternative.

Content-Transfer-EncodingContent-Transfer-Encoding

7bit7bit

Это поле заголовка может определять следующие характеристики сообщения:This header field can describe the following information about a message:

  • алгоритм кодирования, используемый для преобразования текста, отличного от US-ASCII, или двоичных данных в теле сообщения;The encoding algorithm used to transform any non-US-ASCII text or binary data that exists in the message body.

  • индикатор, описывающий текущее состояние тела сообщения.An indicator that describes the current condition of the message body.

В сообщении MIME может использоваться несколько значений поля заголовка Content-Transfer-Encoding.There can be multiple values of the Content-Transfer-Encoding header field in a MIME message. Когда поле заголовка Content-Transfer-Encoding появляется в заголовке сообщения, оно применяется ко всему тексту сообщения.When the Content-Transfer-Encoding header field appears in the message header, it applies to the whole body of the message. Когда поле заголовка Content-Transfer-Encoding появляется в одной из частей составного сообщения, оно применяется только к этой части сообщения.When the Content-Transfer-Encoding header field appears in one of the parts of a multipart message, it applies only to that part of the message.

Когда алгоритм кодирования применяется к данным текста сообщения, последний преобразуется в обычный текст в кодировке US-ASCII.When an encoding algorithm is applied to the message body data, the message body data is transformed into plain US-ASCII text. Это обеспечивает возможность передачи сообщения через более старые серверы обмена сообщениями SMTP, которые поддерживают только текстовые сообщения в кодировке US-ASCII.This transformation allows the message to travel through older SMTP messaging servers that only support messages in US-ASCII text. Значения поля заголовка Content – Transfer/Encoding, указывающие на алгоритм кодирования, использованный в тексте сообщения, приведены ниже.The values of the Content-Transfer-Encoding header field that indicate an encoding algorithm was used on the message body are as follows:

  • С кавычками — печатаемый   этот алгоритм кодирования использует печатаемые символы US – ASCII для кодирования данных текста сообщения.Quoted-printable   This encoding algorithm uses printable US-ASCII characters to encode the message body data. Если текст исходного сообщения содержит преимущественно знаки US-ASCII, кодирование по алгоритму Quoted Printable позволяет получить компактный текст, относительно пригодный для чтения.If the original message text is mostly US-ASCII text, Quoted-printable encoding gives somewhat readable and compact results. Все печатные текстовые знаки US-ASCII за исключением знака равенства (=) можно представить без кодирования.All printable US-ASCII text characters except the equal sign (=) character can be represented without encoding.

  • Base64   этот алгоритм кодирования в основном основан на стандарте расширенной безопасности почты (PEM), определенном в RFC 1421.Base64   This encoding algorithm is based primarily on the privacy-enhanced mail (PEM) standard defined in RFC 1421. Для кодирования текста сообщения в этом случае используется 64-знаковый алфавит и знаки заполнения вывода, определенные в стандарте PEM.Base64 encoding uses the 64-character alphabet encoding algorithm and output padding characters defined by PEM to encode the message body data. Сообщение, закодированное с использованием алгоритма Base64, обычно примерно на треть больше исходного.A Base64 encoded message is typically 33 percent larger than the original message. Этот алгоритм позволяет спрогнозировать итоговый размер сообщения и лучше всего подходит для кодирования двоичных данных и текста в кодировке, отличной от US-ASCII.Base64 encoding creates a predictable increase in message size and is optimal for binary data and non-US-ASCII text.

Как правило, для кодирования сообщения используется только один алгоритм.Typically, you won't see multiple encoding algorithms used in the same message.

Если для текста сообщения не использовался ни один алгоритм кодирования, поле заголовка Content-Transfer-Encoding просто определяет текущее состояние данных в тексте сообщения.When no encoding algorithm has been used on the message body, the Content-Transfer-Encoding header field merely identifies the current condition of the message body data. Следующие значения поля заголовка Content – Transfer/Encoding указывают на то, что в тексте сообщения не использовались алгоритмы кодирования:The following values of the Content-Transfer-Encoding header field indicate that no encoding algorithms were used on the message body:

  • 7bit   это значение указывает на то, что данные текста сообщения уже имеют формат RFC 2822.7bit   This value indicates that the message body data is already in the RFC 2822 format. Это означает, что должны быть выполнены следующие условия:Specifically, this means that the following conditions must be true:

    • каждая строка текста содержит не более 998 знаков;All lines of text must be less than 998 characters long.

    • все знаки являются текстовыми знаками из кодировки US-ASCII с номерами от 1 до 127 включительно;All characters must be US-ASCII text that have character values from 1 through 127.

    • знаки возврата каретки и перевода строки используются только вместе для обозначения конца строки текста.The CR and LF characters can only be used together to indicate the end of a line of text.

    Текст всего сообщения может быть 7bit, или часть текста сообщения составного сообщения может быть 7bit.The whole message body may be 7bit, or part of the message body in a multipart message may be 7bit. Если составное сообщение содержит части, включающие двоичные данные или текстовые знаки, отличные от знаков в кодировке US-ASCII, эти части должны быть закодированы с помощью алгоритма Quoted Printable или Base64.If the multipart message contains other parts that have any binary data or non-US-ASCII text, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms.

    Сообщения, содержащие тексты 7bit, могут перемещаться между серверами обмена сообщениями SMTP с помощью стандартной команды данных.Messages that have 7bit bodies can travel between SMTP messaging servers by using the standard DATA command.

  • 8bit   это значение указывает на то, что в тексте сообщения содержатся символы, не входящие в набор ASCII.8bit   This value indicates that the message body data contains non-US-ASCII characters. Это означает, что должны быть выполнены следующие условия:Specifically, this means that the following conditions must be true:

    • каждая строка текста содержит не более 998 символов;All lines of text must be less than 998 characters long.

    • в теле сообщения есть хотя бы один знак, имеющий в кодировке номер больше 127;One or more characters in the message body have values larger than 127.

    • символы возврата каретки и перевода строки могут использоваться вместе только для обозначения конца строки текста.The CR and LF characters can only be used together to indicate the end of a line of text.

    Текст всего сообщения может быть 8bit, или часть текста сообщения составного сообщения может быть 8bit.The whole message body may be 8bit, or part of the message body in a multipart message may be 8bit. Если составное сообщение содержит части, включающие двоичные данные или текстовые знаки, отличные от знаков в кодировке US-ASCII, эти части должны быть закодированы с помощью алгоритма Quoted Printable или Base64.If the multipart message contains other parts that have binary data, that part of the message must be encoded using the Quoted-printable or Base64 encoding algorithms.

    Сообщения, содержащие тексты 8bit, могут перемещаться только между серверами обмена сообщениями SMTP, которые поддерживают расширение SMTP 8BITMIME, как определено в RFC 1652, например серверы с Exchange 2000 Server или более поздние версии.Messages that have 8bit bodies can only travel between SMTP messaging servers that support the 8BITMIME SMTP extension as defined in RFC 1652, such as servers running Exchange 2000 Server or newer versions. Это означает, что должны быть выполнены следующие условия:Specifically, this means that the following conditions must be true:

    • в отклике EHLO сервера должно быть объявлено ключевое слово 8BITMIME;The 8BITMIME keyword must be advertised in the server's EHLO response.

    • Сообщения по-прежнему передаются с помощью команды SMTP Standard DATA.Messages are still transferred by using the SMTP standard DATA command. Однако параметр BODY = 8BITMIME необходимо добавить в конец команды MAIL FROM.However, the BODY=8BITMIME parameter must be added to the end of the MAIL FROM command.

  • Двоичное   значение указывает на то, что текст сообщения содержит текст, отличный от US – ASCII, или двоичные данные.Binary   This value indicates that the message body contains non-US-ASCII text or binary data. Это означает, что выполняются следующие условия:Specifically, this means that the following conditions are true:

    • разрешены любые последовательности знаков;Any sequence of characters is allowed.

    • длина строк не ограничена;There is no line length limitation.

    • двоичные элементы сообщения не нуждаются в кодировании.Binary message elements don't require encoding.

    Сообщения, содержащие двоичные тексты, могут перемещаться только между SMTP-серверами обмена сообщениями, которые поддерживают расширение SMTP BINARYMIME, как определено в RFC 3030, например серверы, на которых работает сервер Exchange 2000 или более поздние версии.Messages that have Binary bodies can only travel between SMTP messaging servers that support the BINARYMIME SMTP extension as defined in RFC 3030, such as servers running Exchange 2000 Server or newer versions. Это означает, что должны быть выполнены следующие условия:Specifically, this means that the following conditions must be true:

    • в отклике EHLO сервера должно быть объявлено ключевое слово BINARYMIME;The BINARYMIME keyword must be advertised in the server's EHLO response.

    • SMTP-расширение BINARYMIME можно использовать только с SMTP-расширением CHUNKING.The BINARYMIME SMTP extension can only be used with the CHUNKING SMTP extension. Функция фрагментирования позволяет отправлять сообщения с большими телами в виде нескольких меньших блоков.Chunking enables large message bodies to be sent in multiple, smaller chunks. Понятие функции фрагментирования определено в спецификации RFC 3030.Chunking is also defined in RFC 3030. В отклике EHLO сервера должно быть объявлено ключевое слово CHUNKING.The CHUNKING keyword must also be advertised in the server's EHLO response.

    • Для передачи сообщений используется команда BDAT вместо стандартной команды DATA.Messages are transferred using the BDAT command instead of the standard DATA command.

    • Если у сообщения есть текст сообщения, необходимо добавить параметр BODY=BINARYMIME в конец команды MAIL FROM.The BODY=BINARYMIME parameter must be added to the end of the MAIL FROM command when the message has a message body.

Значения 7bit, 8bit и binary никогда не существуют вместе в одном составном сообщении.The values 7bit, 8bit, and Binary never exist together in the same multipart message. Значения являются взаимоисключающими.The values are mutually exclusive. Значения, поддерживающие распечатку или Base64, могут отображаться в теле 7bit или 8bit составного сообщения, но никогда не в двоичном тексте сообщения.The Quoted-printable or Base64 values may appear in a 7bit or 8bit multipart message body, but never in a Binary message body. Если в теле составного сообщения содержатся различные части, состоящие из контента 7bit и 8bit, то все сообщение классифицируется как 8bit.If a multipart message body contains different parts composed of 7bit and 8bit content, the whole message is classified as 8bit. Если в теле составного сообщения содержатся различные части, состоящие из 7bit, 8bit и двоичного содержимого, то все сообщение классифицируется как двоичное.If a multipart message body contains different parts composed of 7bit, 8bit, and Binary content, the whole message is classified as Binary.

Content-DispositionContent-Disposition

ВложениеAttachment

В этом поле заголовке предписывается почтовые клиенты с поддержкой MIME для отображения вложенного файла и описывается в RFC 2183.This header field instructs a MIME-enabled email client on how it should display an attached file, and is described in RFC 2183. Значение этого поля может быть встроенным или вложенным.The values of this field may be Inline or Attachment. Если значение этого поля является встроенным, то вложение отображается в тексте сообщения.When the value of this field is Inline, the attachment is displayed in the message body. Когда значение этого поля является вложением, вложенный файл отображается как обычное вложение отдельно от текста сообщения.When the value of this field is Attachment, the attached file appears as a regular attachment separate from the message body. Другие параметры доступны, если значение равно "вложение", например "имя файла", "Дата создания" и "размер".Other parameters are available when the value is Attachment, such as Filename, Creation-date, and Size.