Содержание

Биржа контента «Текст Брокер» — Справочник Манимейкера или Народные ссылки

Место встречи копирайтеров и владельцев интернет-ресурсов, которым требуется качественный контент для качественных сайтов. Заработок для авторов (копирайтеров) — контент для оптимизаторов. Дополнительные бесплатные сервисы.

Подробнее о преимуществах сервиса:

  • Мгновенное принятие заказа в работу после размещения заказа
  • Большое количество копирайтеров
  • Быстрое и качественное выполнение заказов
  • Опция оптовая загрузка» позволяет в считанные минуты разместить множество заказов
  • Все проверяются через антиплагиат-фильтр
  • Бесплатная проверкой CopyScape 
  • Уникальная услуга биржи контента это проверка текстов корректором вручную
  • Работа оплачивается автору только после принятия заказа.
  • Прямой контакт с копирайтером посредством системы личных сообщений
  • Возможность копирайтеру прорекламировать себя на главной странице сервиса
  • Партнерская программа как для вебмастеров так и для копирайтеров 25%
  • Программа Double Content Finder для поиска дублированного контента:

 

Если хотется проверить уникальность статьи, наличие её в интернете, известны ли поисковым машинам копии этой статьи, или после размещения статьи на своем сайте по прошествии какого-то времени Вы желаете проверить, сколько веб-мастеров скопировали ваш контент на свои сайты, то эта абсолютно бесплатная программа поможет Вам.

 

 

О работе с программой: ввести проверяемый текст любым способом: добавить текст из буфера обмена, загрузить файл с текстом или указать адрес, где расположена проверяемая статья. Запускаете поиск и в итоге два варианта ответа — текст уникален или текст не уникален. Во 2 случае вы получите список адресов, по которым расположены копии вашей статьи.

 

P.S. Скачать программу абсолютно бесплатно Вы можете также с нашего файлового архива: DCFinder.exe 

Народная ссылка для регистрации:
Биржа контента «Текст Брокер»

   


» Биржа ссылок и статей «Main Link» : Этой бирже предназначено судьбой обеспечивать надежные операции по поиску, покупке и про…
» CentOS: mod_perl, directadmin: Mod_perl — это С модуль Apache, реализующий Perl интерпретатор + набор Perl модулей, предост…

» Directadmin: установка: В данной статье подробно описан порядок установки панели управления Directadmin на сервер. Предваритель…
» Партнерская программа знакомств Love Planet: Love Planet — это международная служба знакомств. Одна из самых древних и испытанных временем партнерок…
» TurboText — удобная биржа копирайтинга, статей, рерайтинга: Данная биржа контента позиционирует себя как площадку для соединения профессиональных навыков…

ТЕКСТ РУ биржа копирайтинга. Проверка текста

Привет Всем! Для всех, кто занимается написанием статей и наполнением сайта контентом, необходимо производить проверку текста статей перед тем как представить его читателям. В статье «ТЕКСТ РУ биржа копирайтинга» я рассказываю как проверить текст онлайн на популярной бирже контента ТЕКСТ РУ бесплатно.

Биржа Копирайтинг ETXT биржа статей. Купить готовую статью

Но в этой программе вы можете заказать проверку текста только на уникальность.

На бирже ТЕКСТ.РУ кроме проверки на уникальность, вам еще будет предложено проверить текст на орфографию, заспамленность и воду. Давайте разберем все эти функции по-порядку.

Содержание страницы

ТЕКСТ РУ биржа копирайтинга. Уникальность статьи

Уникальные — это значит нигде ранее не встречавшиеся видео, фото, статьи, стихи, тексты песен, литературные произведения и другие материалы. Например, вы собираетесь написать статью для сайта, а своих идей у вас нет. Что вы делаете? Правильно. Вы начинаете искать информацию в Интернете.

Просматривая различные материалы по нужной теме и изучая их, вы вдохновляетесь и у вас появляются полезные мысли и идеи. В этом случае все прекрасно, вы пишете своими словами свежую уникальную статью.

В противном случае вы просто тупо копируете чужой материал и публикуете его, выдавая за свой. Это уже вопиющий Плагиат и уникальность такой статьи 0%. Многие делают рерайт, переписывая чужой текст своими словами. Качественный рерайтинг может существенно повысить уникальность материала.

Раньше, чтобы выдать чужой текст за уникальный, достаточно было сделать перестановку слов и предложений, поменять знаки и абзацы, изменить падежи. Сейчас так просто уже не получится «сплагиатить». Все меняется и разработчики все более усовершенствуют поисковых роботов, чтобы они могли распознавать такие подделки.

Сейчас ценится не просто текст. Анализируется поведение пользователя на сайте. Учитывается время, которое читатель проводит на сайте и на разных страницах. Количество переходов и отказов, дочитываний и активности…

То есть, статья оценивается по поведенческим факторам читателя. Уникальность и новизна материала высоко ценится поисковиками. Поэтому очень важно добиваться высокого процента уникальности текста. Программы для проверки уникальности текстов показывают источники рерайтинга и дают подсказки, выделяя неуникальные фразы различными цветами. Это помогает повысить уникальность контента.

Проверка контента на ошибки и орфографию

Проверка текста на орфографические ошибки — это один из важных этапов редактирования статьи. Даже если уровень вашей грамотности очень высокий, вы все равно не застрахованы от разных ошибок. Когда вы быстро строчите свой текст, нередко происходят пропуски букв, а иногда и целых слов. Отвлекаясь во время написания статьи, можно потерять нить, и при возобновлении повествования сойти с темы.

Что уже говорить о тех, для кого грамотное изложение текста выходит за грань возможного. И далеко не все авторы блогов могут похвастаться высоким уровнем грамотности. Поэтому, возможность проверить материал на грамотность является реально необходимостью для любого автора.

Заспамленность и ключевые слова

Заспамленность статьи — это большое количество ключевых слов, которые без конца повторяются и делают информацию неинтересной для читателя. Все хорошо в меру. Перебор с ключевыми словами может способствовать снижению рейтинга сайта. А статья с подобными излишествами может и вовсе забаниться поисковиками.

Материал должен быть полезен и интересен прежде всего людям. Но новичку не всегда понятно, какие слова и фразы особенно влияют на процент заспамленности. Проверить текст на заспамленность, и не допустить удаления опубликованного материала из поиска также поможет программа проверки уникальности статьи ТЕКСТ РУ.

Вода или водность текста

Не лей воду! — так говорят обычно рассказчику, который пытается донести истину, используя много слов и выражений, далеких от нее. Если говорить о тексте, то это бесполезные слова и фразы, которые не несут никакого смысла. Если выкинуть из текста все эти «водные» слова и фразы, то смысл повествования от этого не изменится, но сможет пострадать индивидуальный стиль автора. Поэтому, здесь важно поддерживать баланс. И проверка текста на воду в помощь!

ТЕКСТ РУ биржа копирайтинга. Регистрация

Для проверки текста онлайн, нужна регистрация.

Заходим на сайт биржи ТЕКСТ.РУ и нажимаем «Зарегистрироваться».

В форме регистрации указываем свой адрес электронной почты и жмем «Зарегистрироваться». Видим, что нам предлагают активизировать свою учетную запись и идем в электронную почту для подтверждения адреса.

Пароль можно будет поменять потом в личном кабинете на более запоминаемый.

После активации акаунта, вы автоматически попадаете на главную страницу ТЕКСТ.РУ. Здесь отображается основное окно, куда вставляется проверяемый текст и основные виды проверок — уникальность, орфография и SEO-анализ (заспамленность, вода).

Проверка текста на ТЕКСТ РУ биржа копирайтинга

Проверка на уникальность

Нажимаем «Новый текст«, и вставляем скопированную статью в поле для проверки и жмем «Запустить проверку».

Видим как изменились показатели по основным критериям проверки. Если вы сами написали статью, то уникальность будет либо 100% либо близко к ней, 95 — 97 %. Если процент ниже 90%, вы можете повысить уникальность, следуя подсказкам программы. Это можно сделать, нажав «подробнее». После этого вам будут показаны участки текста, где следует внести исправления и рекомендации для внесения изменений.

В блоке «проверка уникальности» вы можете получить ссылку на проверку, зафиксировать проверку или получить кнопку уникальности. Это платные функции. Позже вы можете воспользоваться ими, пройдя по ссылкам в блоке.

Проверка текста на орфографию

В блоке «Проверка орфографии» аналогично жмем кнопку «Подробнее» и исправляем ошибки, которые программа подсвечивает красным. Чтобы получить подсказку, кликаем по «красным» словам и следуем рекомендациям программы. Таким вот образом и исправляем все ошибки.

На первом скриншоте видно, что указана орфографическая ошибка (просто буква «а» пропущена) и исправленный вариант. Во втором случае оказалась лишней запятая.

SEO-анализ текста на ТЕКСТ РУ

В SEO блоке если мы кликнем по «заспамленность«, то все фиолетовые слова и есть ключевые. Чем темнее цвет, тем чаще данное слово встречается в статье. Считается, что процент заспамленности до 55 допустим. Если больше, то нужно уже редактировать статью, заменяя слишком часто повторяющиеся слова синонимами.

Прокрутив страницу чуть ниже, вы найдете список всех ключевых слов, которые программа нашла в вашей статье и частоту их повторения. И если слишком высок процент заспамленности, вы легко можете это исправить, заменив слова из списка, либо сократив их число.

Все «Водные» слова подсвечиваются голубым. Допустимость воды в тексте примерно 20%. . Если воды в статье слишком много, стоит его подкорректировать и выкинуть лишние слова.

ТЕКСТ РУ биржа копирайтинга. Заключение

В заключение хочу добавить, что не стоит слишком уж заморачиваться и пытаться довести статью до идеала во что бы то ни стало. Даже если вы и пропустите где запятую, либо будет в тексте чуть больше воды — ничего страшного! Главное, чтобы ваша статья была «живой», а не набором бездушных и холодных печатных символов.

Спасибо и всего вам доброго! Удачи и Успехов!

Еще вам может быть полезно прочитать:

  • По ключевым запросам Яндекс Вордстат. Что такое поисковая выдача
  • Как выйти из творческого кризиса
  • Добавляем текст и изображения. Порядок размещения статьи на сайте
  • О редактировании обработке изображений. Бесплатный редактор Paint.NET
  • Оформим статью для публикации. Как вставить картинку в статью
  • Работа над темами статьи для публикаций. 7 способов выбора интересной темы для статьи

Преобразование контента | Microsoft Learn

  • Статья

Преобразование содержимого — это процесс правильного форматирования сообщения для каждого получателя. Решение о преобразовании содержимого сообщения зависит от адресата и формата сообщения. Типы преобразования контента, которые происходят в Exchange 2016 и Exchange 2019.не изменились по сравнению с Exchange 2013:

  • Преобразование сообщений для внешних получателей : этот тип преобразования содержимого включает параметры преобразования в формате Transport Neutral Encapsulation Format (TNEF) и параметры кодирования сообщений для внешних получателей. Сообщения, отправляемые получателям внутри организации Exchange, не требуют такого преобразования содержимого. Этот тип преобразования содержимого обрабатывается классификатором в службе транспорта на сервере почтовых ящиков. Категоризация каждого сообщения происходит после помещения вновь поступившего сообщения в очередь отправки. В дополнение к разрешению получателя и разрешению маршрутизации в сообщении выполняется преобразование содержимого перед помещением сообщения в очередь доставки. Если одно сообщение содержит несколько получателей, классификатор определяет соответствующую кодировку для каждого получателя сообщения.
    Трассировка преобразования контента не фиксирует сбои преобразования контента, с которыми сталкивается классификатор при преобразовании сообщений, отправленных внешним получателям.

  • Преобразование MAPI для внутренних получателей : этот тип преобразования содержимого обрабатывается службой транспорта почтовых ящиков. Служба транспорта почтовых ящиков существует на серверах почтовых ящиков для передачи сообщений между базами данных почтовых ящиков на локальном сервере и службы транспорта на серверах почтовых ящиков. В частности, служба передачи почтовых ящиков передает сообщения из папки «Исходящие» отправителя в службу транспорта на сервере почтовых ящиков. Служба доставки транспорта почтовых ящиков передает сообщения из службы транспорта на сервере почтовых ящиков в папку «Входящие» получателя. Служба отправки транспорта почтовых ящиков преобразует все исходящие сообщения из MAPI, а служба доставки транспорта почтовых ящиков преобразует все входящие сообщения в MAPI.

    Трассировка преобразования содержимого фиксирует эти сбои преобразования MAPI. Дополнительные сведения см. в разделе Управление отслеживанием преобразования контента.

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

В следующем списке описаны основные форматы сообщений, доступные в Exchange и Outlook. не может содержать разные шрифты или другое форматирование текста. Для обычного текстового сообщения можно использовать следующие два формата:

.

  • Заголовки и тело сообщения состоят из текста US-ASCII. Вложения должны быть закодированы с использованием Uuencode . Uuencode представляет кодировку Unix-to-Unix и определяет алгоритм кодирования для хранения двоичных вложений в теле сообщения электронной почты с использованием текстовых символов US-ASCII.

  • Сообщение закодировано в формате MIME со значением

    Content-Type text/plain и значением Content-Transfer-Encoding 7bit для текстовых частей составного сообщения. Любые вложения сообщения кодируются с использованием кодировки Quoted-printable или Base64. По умолчанию, когда вы создаете и отправляете обычное текстовое сообщение в Outlook, сообщение кодируется MIME с кодом 9.0019 Content-Type значение text/plain .

  • HTML : HTML-сообщение поддерживает форматирование текста, фоновые изображения, таблицы, маркеры и другие графические элементы. По определению, сообщение в формате HTML должно быть закодировано в формате MIME, чтобы сохранить эти элементы форматирования.

  • Расширенный текстовый формат (RTF) : RTF поддерживает форматирование текста и другие графические элементы. RTF является синонимом TNEF (TNEF и RTF могут использоваться взаимозаменяемо). Формат расширенного текстового сообщения полностью отличается от форматированного текстового документа, доступного в Word.

  • TNEF : Транспортно-нейтральный формат инкапсуляции — это специальный формат Microsoft для инкапсуляции свойств сообщений MAPI.

    Сообщение TNEF содержит текстовую версию сообщения и вложение, которое упаковывает исходную отформатированную версию сообщения. Обычно это вложение называется Winmail.dat. Вложение Winmail.dat содержит следующую информацию:

    .
    • Исходная отформатированная версия сообщения (например, шрифты, размеры и цвета текста)
    • Объекты OLE (например, встроенные изображения или встроенные документы Office)
    • Специальные функции Outlook (например, настраиваемые формы, кнопки голосования или приглашения на собрания)
    • Вложения обычного сообщения, которые были в исходном сообщении

    Полученное текстовое сообщение может быть представлено в следующих форматах:

    • Сообщение, совместимое с RFC 5322, состоящее только из текста US-ASCII с вложением Winmail.dat, закодированным в Uuencode
    • Составное сообщение в кодировке MIME с вложением Winmail.dat

    Outlook и другие почтовые клиенты, которые полностью понимают TNEF, обрабатывают вложение Winmail. dat и отображают исходное содержимое сообщения, даже не отображая вложение Winmail.dat. Почтовые клиенты, которые не понимают TNEF, могут представлять сообщения TNEF одним из следующих способов:

    • Отображается обычная текстовая версия сообщения, и сообщение содержит вложение с именем Winmail.dat, Win.dat или другим общим именем, например Att
      nnnnn       .dat или Att nnnnn .eml, где заполнитель nnnnn представляет собой случайное число.
    • Отображается текстовая версия сообщения. Вложение TNEF игнорируется или удаляется. Результатом является обычное текстовое сообщение.
    • Серверы обмена сообщениями, понимающие TNEF, можно настроить на удаление вложений TNEF из входящих сообщений. Результатом является обычное текстовое сообщение. Более того, некоторые почтовые клиенты могут не понимать TNEF, но распознавать и игнорировать вложения TNEF. Результатом является обычное текстовое сообщение.

    Существуют сторонние утилиты, которые могут помочь преобразовать вложения Winmail. dat.

    TNEF понимается всеми версиями Exchange, начиная с версии Exchange Server 5.5.

  • Общий формат транспортной нейтральной инкапсуляции (STNEF) : STNEF эквивалентен TNEF. Однако сообщения STNEF кодируются иначе, чем сообщения TNEF. В частности, сообщения STNEF всегда имеют кодировку MIME и всегда имеют значение Content-Transfer-Encoding 9.0051 Двоичный . Таким образом, нет простого текстового представления сообщения и нет отдельного вложения Winmail.dat, содержащегося в теле сообщения. Все сообщение представляется с использованием только двоичных данных. Сообщения со значением Content-Transfer-Encoding Binary могут передаваться только между серверами обмена сообщениями, которые поддерживают и рекламируют расширения SMTP BINARYMIME и CHUNKING , как определено в RFC 3030. Сообщения всегда передаются между обменом сообщениями. сервера с помощью 9Команда 0019 BDAT вместо стандартной команды DATA .

    STNEF понимается всеми версиями Exchange, начиная с Exchange 2000. STNEF автоматически используется для всех сообщений, передаваемых между серверами Exchange в организации, начиная с Exchange Server 2003 в основном режиме.

    Exchange никогда не отправляет сообщения STNEF внешним получателям. Только сообщения TNEF могут быть отправлены получателям за пределами организации Exchange.

    • Варианты преобразования контента для внешних получателей

    Параметры преобразования содержимого, которые можно установить в организации Exchange для внешних получателей, можно описать в следующих категориях:

    • Параметры преобразования TNEF : Эти параметры преобразования указывают, следует ли сохранять или удалять формат TNEF из сообщений, которые покидают Организация обмена.
    • Параметры кодирования сообщений : Эти параметры определяют параметры кодирования сообщений, такие как наборы символов MIME и не-MIME, кодирование сообщений и форматы вложений.

    Эти параметры преобразования и кодирования не зависят друг от друга. Например, то, могут ли сообщения TNEF покидать организацию Exchange, не связано с параметрами кодирования MIME или параметрами кодирования обычного текста этих сообщений.

    Вы можете указать преобразование контента на различных уровнях организации Exchange, как описано в следующем списке:

    • Параметры удаленного домена : Удаленные домены определяют параметры передачи исходящих сообщений между организацией Exchange и внешними доменами. Даже если вы не создаете записи удаленного домена для определенных доменов, существует предопределенный удаленный домен с именем Default, который применяется ко всем удаленным адресным пространствам (*). Дополнительные сведения об удаленных доменах см. в разделе Удаленные домены.

    • Настройки пользователя почты и почтовых контактов : Почтовые пользователи и почтовые контакты похожи, поскольку оба имеют внешние адреса электронной почты и содержат информацию о людях за пределами организации Exchange. Основное отличие состоит в том, что у пользователей почты есть учетные записи, которые они могут использовать для входа в Active Directory и доступа к ресурсам в организации. Дополнительные сведения см. в разделе Получатели.

    • Настройки Outlook : Вы можете установить следующие параметры форматирования и кодирования сообщений в Outlook:

      • Формат сообщения : Вы можете установить формат сообщения по умолчанию для всех сообщений. Вы можете переопределить формат сообщения по умолчанию при составлении конкретного сообщения.
      • Формат интернет-сообщений : Вы можете контролировать, будут ли сообщения TNEF отправляться удаленным получателям или они сначала будут преобразованы в более совместимый формат. Вы также можете указать различные параметры кодирования сообщений для сообщений, отправляемых удаленным получателям. Эти параметры не применяются к сообщениям, отправляемым получателям в организации Exchange.
      • Формат сообщения получателя в Интернете (Outlook 2010 или более ранняя версия) : вы можете указать, будут ли сообщения TNEF отправляться определенным контактам в папке «Контакты». Эти параметры преобразования недоступны для получателей в организации Exchange.
      • Параметры кодирования сообщений получателя в Интернете (Outlook 2010 или более ранней версии) : вы можете управлять параметрами кодирования MIME или простого текста для определенных контактов в папке «Контакты». Эти параметры преобразования недоступны для получателей в организации Exchange.
      • Международные параметры : Вы можете управлять наборами символов, используемыми в сообщениях.

      Дополнительные сведения об этих параметрах см. в разделах Параметры преобразования TNEF и Параметры кодирования сообщений в Exchange Server.

    Чтобы лучше понять параметры преобразования содержимого для внешних получателей, необходимо понимать структуру сообщений электронной почты. Сообщение SMTP основано на простом 7-битном тексте US-ASCII для составления и отправки сообщений электронной почты. Стандартное SMTP-сообщение состоит из следующих элементов:

    • Конверт сообщения : Конверт сообщения определен в RFC 5321. Конверт сообщения содержит информацию, необходимую для передачи и доставки сообщения. Получатели никогда не увидят конверт сообщения, потому что он создается в процессе передачи сообщения и фактически не является частью содержимого сообщения.

    • Содержимое сообщения : Содержимое сообщения определено в RFC 5322. Содержимое сообщения состоит из следующих элементов:

      • Заголовок сообщения : Заголовок сообщения представляет собой набор полей заголовка. Поля заголовка состоят из имени поля, за которым следует символ двоеточия (:), за которым следует тело поля, и заканчиваются комбинацией символов возврата каретки/перевода строки (CR/LF).

        Имя поля должно состоять из печатных текстовых символов US-ASCII, за исключением символа двоеточия (:). В частности, разрешены символы ASCII со значениями от 33 до 57 и от 59 до 126.

        Тело поля может состоять из любых символов US-ASCII, за исключением символа возврата каретки (CR) и символа перевода строки (LF). Однако тело поля может содержать комбинацию символов CR/LF при использовании в сворачивании заголовка . Сворачивание заголовка — это разделение тела одного поля заголовка на несколько строк, как описано в разделе 2.2.3 RFC 5322. Другие требования к синтаксису тела поля описаны в разделах 3 и 4 RFC 5322.

      • Тело сообщения : Тело сообщения представляет собой набор строк текстовых символов US-ASCII, которые появляются после заголовка сообщения. Заголовок сообщения и тело сообщения разделены пустой строкой, которая заканчивается комбинацией символов CR/LF. Тело сообщения является необязательным. Длина любой строки текста в теле сообщения не должна превышать 998 символов. Символы CR и LF могут появляться только вместе, чтобы указать конец строки.

    Если сообщения SMTP содержат элементы, отличные от обычного текста US-ASCII, сообщение должно быть закодировано, чтобы сохранить эти элементы. Стандарт MIME определяет метод кодирования содержимого сообщений, не являющегося текстом. MIME допускает текст в других наборах символов, вложения без текста, составные тела сообщений и поля заголовков в других наборах символов. MIME определен в RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289.и RFC 2049. MIME определяет набор полей заголовков, которые определяют дополнительные атрибуты сообщения. В следующих разделах описаны некоторые важные поля заголовка MIME.

    Значение по умолчанию : 1.0

    Это поле заголовка является первым полем заголовка MIME, которое появляется в сообщении в формате MIME. Это поле заголовка появляется после других стандартных полей заголовка RFC 5322, но перед любыми другими полями заголовка MIME. Почтовые клиенты с поддержкой MIME используют это поле заголовка для идентификации сообщения, закодированного в MIME. Когда это поле заголовка отсутствует, почтовые клиенты с поддержкой MIME идентифицируют сообщение как обычный текст.

    Поле заголовка Content-Type

    Значение по умолчанию : text/plain

    Это поле заголовка определяет тип носителя содержимого сообщения, как описано в RFC 2046. Тип носителя состоит из:

    • 90 012 А тип :

      • Типы, начинающиеся с x-, не являются стандартными. Управление по присвоению номеров в Интернете (IANA) ведет список зарегистрированных типов носителей. Дополнительные сведения см. в разделе Типы носителей MIME.

      • Тип мультимедиа multipart позволяет использовать несколько частей сообщения в одном сообщении, используя разделы, определенные разными типами мультимедиа. Некоторые значения поля Content-Type включают text/plain , text/html , multipart/mixed и multipart/alternative .

    • Подтип A : Подтипы, начинающиеся с vnd. зависят от поставщика.

    • Один или несколько необязательных параметров : Например, параметр charset=, который определяет кодировку символов MIME.

    Поле заголовка Content-Transfer-Encoding

    Значение по умолчанию : 7 бит

    Это поле заголовка может содержать следующую информацию о сообщении:

    • Алгоритм кодирования, используемый для преобразования любого текста, отличного от US-ASCII или двоичные данные, существующие в теле сообщения.
    • Индикатор, описывающий текущее состояние тела сообщения.

    В сообщении MIME может быть несколько значений поля заголовка Content-Transfer-Encoding . Когда поле заголовка Content-Transfer-Encoding появляется в заголовке сообщения, оно применяется ко всему тексту сообщения. Когда поле заголовка Content-Transfer-Encoding появляется в одной из частей составного сообщения, оно применяется только к этой части сообщения.

    Когда алгоритм кодирования применяется к данным тела сообщения, данные тела сообщения преобразуются в обычный текст US-ASCII. Это преобразование позволяет сообщению проходить через старые серверы обмена сообщениями, которые поддерживают сообщения только в тексте US-ASCII. 9Значения поля заголовка 0019 Content-Transfer-Encoding , указывающие на то, что алгоритм кодирования использовался в теле сообщения:

    • Quoted-printable : Использует печатные символы US-ASCII для кодирования данных тела сообщения. Если исходный текст сообщения в основном представляет собой текст US-ASCII, кодирование с возможностью печати в кавычках дает более читаемые и компактные результаты. Все печатаемые текстовые символы US-ASCII, кроме символа равенства (=), могут быть представлены без кодирования.

    • Base64 : В основном основан на стандарте электронной почты с повышенной конфиденциальностью (PEM), определенном в RFC 4648. Кодирование Base64 использует алгоритм кодирования 64-символьного алфавита и выходные символы заполнения, определенные PEM для кодирования данных тела сообщения. Сообщение в кодировке Base64 обычно на 33% больше, чем исходное сообщение. Кодировка Base64 приводит к предсказуемому увеличению размера сообщения и оптимальна для двоичных данных и текста, отличного от US-ASCII.

    Как правило, в одном сообщении не используется несколько алгоритмов кодирования.

    Если в теле сообщения не использовался алгоритм кодирования, поле заголовка Content-Transfer-Encoding просто идентифицирует текущее состояние данных тела сообщения. Значения поля заголовка Content-Transfer-Encoding , указывающие на то, что в теле сообщения не использовались алгоритмы кодирования:

    • 7 бит : указывает, что данные тела сообщения уже представлены в формате RFC 5322. В частности, это означает, что должны выполняться следующие условия:

      • Длина всех строк текста не должна превышать 998 символов.

      • Все символы должны быть текстом US-ASCII со значениями символов от 1 до 127.

      • Символы CR и LF могут использоваться только вместе для обозначения конца строки текста.

        Все тело сообщения может быть 7-битным, или часть тела сообщения в составном сообщении может быть 7-битным. Если составное сообщение содержит другие части, содержащие какие-либо двоичные данные или текст, отличный от US-ASCII, эта часть сообщения должна быть закодирована с использованием алгоритмов кодирования Quoted-printable или Base64.

        Сообщения с 7-битным телом могут перемещаться между серверами обмена сообщениями с помощью стандартной команды DATA.

    • 8 бит : Указывает, что данные тела сообщения содержат символы, отличные от US-ASCII. В частности, это означает, что должны выполняться следующие условия:

      • Длина всех строк текста не должна превышать 998 символов.

      • Один или несколько символов в теле сообщения имеют значения больше 127.

      • Символы CR и LF могут использоваться только вместе для обозначения конца строки текста.

        Все тело сообщения может быть 8-битным, или часть тела сообщения в составном сообщении может быть 8-битным. Если составное сообщение содержит другие части, содержащие двоичные данные, эта часть сообщения должна быть закодирована с использованием алгоритмов кодирования Quoted-printable или Base64.

        Сообщения с 8-битным телом могут передаваться только между серверами обмена сообщениями, которые поддерживают 8BITMIME Расширение SMTP, как определено в RFC 6152, например, для Exchange 2000 Server или более поздней версии. В частности, это означает, что должны выполняться следующие условия:

      • Ключевое слово 8BITMIME должно быть объявлено в ответе сервера EHLO.

      • Сообщения по-прежнему передаются с помощью стандартной команды SMTP DATA . Однако параметр BODY=8BITMIME необходимо добавить в конец команды MAIL FROM .

    • Двоичный : Указывает, что тело сообщения содержит текст, отличный от US-ASCII, или двоичные данные. В частности, это означает, что выполняются следующие условия:

      • Допускается любая последовательность символов.

      • Длина строки не ограничена.

      • Двоичные элементы сообщения не требуют кодирования.

        Сообщения с двоичными телами могут передаваться только между серверами обмена сообщениями, которые поддерживают BINARYMIME Расширение SMTP, определенное в RFC 3030, например, для Exchange 2000 Server или более поздней версии. В частности, это означает, что должны выполняться следующие условия:

      • Ключевое слово BINARYMIME должно быть объявлено в ответе сервера EHLO.

      • Расширение SMTP BINARYMIME можно использовать только с расширением SMTP CHUNKING . Разделение на фрагменты позволяет отправлять большие тела сообщений несколькими меньшими фрагментами. Разделение также определено в RFC 3030. Ключевое слово CHUNKING также должно быть объявлено в ответе сервера EHLO.

      • Сообщения передаются с помощью команды BDAT вместо стандартной команды DATA .

      • Параметр BODY=BINARYMIME необходимо добавить в конец команды MAIL FROM , если сообщение имеет тело сообщения.

    Значения 7бит , 8бит и Двоичные числа никогда не существуют вместе в одном составном сообщении (значения взаимоисключающие). Значения Quoted-printable или Base64 могут появляться в 7-битном или 8-битном составном теле сообщения, но никогда в двоичном теле сообщения. Если составное тело сообщения содержит разные части, состоящие из 7-битного и 8-битного содержимого, все сообщение классифицируется как 8-битное. Если составное тело сообщения содержит различные части, состоящие из 7-битного, 8-битного и двоичного содержимого, все сообщение классифицируется как двоичное.

    Поле заголовка Content-Disposition

    Значение по умолчанию : Приложение

    Это поле заголовка указывает почтовому клиенту с поддержкой MIME, как он должен отображать вложенный файл, и описано в RFC 2183. Допустимые значения:

    • Встроенный : Вложение отображается в теле сообщения.

    • Вложение : Вложенный файл отображается как обычное вложение отдельно от тела сообщения. Другие параметры тоже с этими значениями (например, Имя файла , Дата создания и Размер ).

    Преобразование содержимого: справка по Exchange 2013

    Твиттер LinkedIn Фейсбук Электронная почта

    • Статья

    Применяется к: Exchange Server 2013

    Преобразование содержимого — это процесс правильного форматирования сообщения для каждого получателя. Решение о преобразовании содержимого сообщения зависит от адресата и формата обрабатываемого сообщения. В Microsoft Exchange Server 2013 существует два различных типа преобразования контента:

    • Преобразование сообщений для внешних получателей : Этот тип преобразования содержимого включает параметры преобразования в формате Transport Neutral Encapsulation Format (TNEF) и параметры кодирования сообщений для внешних получателей. Сообщения, отправляемые получателям внутри организации Exchange, не требуют такого преобразования содержимого. Этот тип преобразования контента обрабатывается классификатором в службе транспорта на сервере почтовых ящиков. Категоризация каждого сообщения происходит после помещения вновь поступившего сообщения в очередь отправки. В дополнение к разрешению получателя и разрешению маршрутизации в сообщении выполняется преобразование содержимого перед помещением сообщения в очередь доставки. Если одно сообщение содержит несколько получателей, классификатор определяет соответствующую кодировку для каждого получателя сообщения. Трассировка преобразования контента не фиксирует сбои преобразования контента, с которыми сталкивается классификатор при преобразовании сообщений, отправленных внешним получателям.

    • Преобразование MAPI для внутренних получателей : этот тип преобразования содержимого обрабатывается службой транспорта почтовых ящиков. Служба транспорта почтовых ящиков существует на серверах почтовых ящиков для передачи сообщений между базами данных почтовых ящиков на локальном сервере и службы транспорта на серверах почтовых ящиков. В частности, служба передачи почтовых ящиков передает сообщения из папки «Исходящие» отправителя в службу транспорта на сервере почтовых ящиков. Служба доставки транспорта почтовых ящиков передает сообщения из службы транспорта на сервере почтовых ящиков в папку «Входящие» получателя. Служба отправки транспорта почтовых ящиков преобразует все исходящие сообщения из MAPI, а служба доставки транспорта почтовых ящиков преобразует все входящие сообщения в MAPI. Трассировка преобразования содержимого фиксирует эти сбои преобразования MAPI. Дополнительные сведения см. в разделе Отслеживание конверсии контента.

    В этом разделе объясняются параметры преобразования сообщений для внешних получателей.

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

    В следующем списке описаны основные форматы сообщений, доступные в Exchange и Microsoft Outlook. сообщение не может содержать разные шрифты или другое форматирование текста. Для простого текстового сообщения можно использовать следующие два формата:

    • Заголовки и тело сообщения состоят из текста US-ASCII. Вложения должны быть закодированы с использованием Uuencode . Uuencode представляет кодировку Unix-to-Unix и определяет алгоритм кодирования для хранения двоичных вложений в теле сообщения электронной почты с использованием текстовых символов US-ASCII.

    • Сообщение закодировано в формате MIME со значением Content-Type, равным text/plain, и значением Content-Transfer-Encoding, равным 7 битам, для текстовых частей составного сообщения. Любые вложения сообщения кодируются с использованием кодировки Quoted-printable или Base64. По умолчанию при составлении и отправке обычного текстового сообщения в Outlook сообщение кодируется в формате MIME со значением Content-Type text/plain.

  • HTML : HTML-сообщение поддерживает форматирование текста, фоновые изображения, таблицы, маркеры и другие графические элементы. По определению, сообщение в формате HTML должно быть закодировано в формате MIME, чтобы сохранить эти элементы форматирования.

  • Расширенный текстовый формат (RTF) : RTF поддерживает форматирование текста и другие графические элементы. RTF является синонимом TNEF. TNEF и RTF могут использоваться взаимозаменяемо. Формат расширенного текстового сообщения полностью отличается от форматированного текстового документа, доступного в Microsoft Word.

    Только Outlook и несколько других почтовых клиентов MAPI понимают сообщения RTF.

  • TNEF : Транспортно-нейтральный формат инкапсуляции — это специальный формат Microsoft для инкапсуляции свойств сообщений MAPI. Сообщение TNEF содержит текстовую версию сообщения и вложение, которое упаковывает исходную отформатированную версию сообщения. Обычно это вложение называется Winmail.dat. Вложение Winmail.dat содержит следующую информацию:

    • Исходная отформатированная версия сообщения, включая, например, шрифты, размеры текста и цвета текста

    • OLE-объекты, включая, например, встроенные изображения или встроенные документы Microsoft Office

    • Специальные функции Outlook, включая, например, настраиваемые формы, кнопки голосования или приглашения на собрания

    • Вложения обычного сообщения, которые были в исходном сообщении

      Результирующее текстовое сообщение может быть представлено в следующих форматах:

    • Сообщение, совместимое с RFC 2822, состоящее только из текста US-ASCII с вложением Winmail. dat, закодированным в Uuencode

    • Составное сообщение в кодировке MIME с вложением Winmail.dat

      MAPI-совместимый почтовый клиент, который полностью понимает TNEF, например Outlook, обрабатывает вложение Winmail.dat и отображает исходное содержимое сообщения, даже не отображая вложение Winmail.dat. Почтовый клиент, который не понимает TNEF, может представить сообщение TNEF одним из следующих способов:

    • Отображается текстовая версия сообщения, и сообщение содержит вложение с именем Winmail.dat, Win.dat или другим общим именем, например Att_nnnnn_.dat или Att_nnnnn_.eml, где заполнитель nnnnn представляет собой случайное число.

    • Отображается текстовая версия сообщения. Вложение TNEF игнорируется или удаляется. Результатом является обычное текстовое сообщение.

    • Серверы обмена сообщениями, поддерживающие формат TNEF, можно настроить для удаления вложений TNEF из входящих сообщений. Результатом является обычное текстовое сообщение. Более того, некоторые почтовые клиенты, такие как Microsoft Outlook Express, могут не понимать TNEF, но распознавать и игнорировать вложения TNEF. Результатом является обычное текстовое сообщение.

      Существуют сторонние утилиты, которые могут помочь преобразовать вложения Winmail.dat.

      TNEF понимается всеми версиями Exchange, начиная с версии Exchange Server 5.5.

  • Общий формат транспортной нейтральной инкапсуляции (STNEF) : STNEF эквивалентен TNEF. Однако сообщения STNEF кодируются иначе, чем сообщения TNEF. В частности, сообщения STNEF всегда имеют кодировку MIME и всегда имеют значение Content-Transfer-Encoding, равное Binary. Таким образом, нет простого текстового представления сообщения и нет отдельного вложения Winmail.dat, содержащегося в теле сообщения. Все сообщение представляется с использованием только двоичных данных. Сообщения со значением Binary для Content-Transfer-Encoding могут передаваться только между серверами обмена сообщениями SMTP, которые поддерживают и рекламируют расширения SMTP BINARYMIME и CHUNKING, как определено в RFC 3030. Сообщения всегда передаются между обменом сообщениями SMTP с помощью команды BDAT, вместо стандартной команды DATA.

    STNEF понимается всеми версиями Exchange, начиная с Exchange 2000. STNEF автоматически используется для всех сообщений, передаваемых между серверами Exchange в организации, начиная с Exchange Server 2003 в основном режиме.

    Exchange никогда не отправляет сообщения STNEF внешним получателям. Только сообщения TNEF могут быть отправлены получателям за пределами организации Exchange.

    • Параметры преобразования содержимого для внешних получателей

    Параметры преобразования содержимого, которые можно задать в организации Exchange для внешних получателей, можно описать в следующих категориях:

    • Параметры преобразования TNEF : Эти параметры преобразования указывают, следует ли сохранять или удалять формат TNEF из сообщений, покидающих организацию Exchange.

    • Параметры кодирования сообщений : Эти параметры определяют параметры кодирования сообщений, такие как наборы символов MIME и не MIME, кодирование сообщений и форматы вложений.

    Эти параметры преобразования и кодирования не зависят друг от друга. Например, то, могут ли сообщения TNEF покидать организацию Exchange, не связано с параметрами кодирования MIME или параметрами кодирования обычного текста этих сообщений.

    Можно указать преобразование содержимого на различных уровнях организации Exchange, как описано в следующем списке:

    • Параметры удаленного домена : Удаленные домены определяют параметры передачи исходящих сообщений между организацией Exchange и внешними доменами. Даже если вы не создаете записи удаленного домена для определенных доменов, существует предопределенный удаленный домен с именем Default, который применяется ко всем удаленным адресным пространствам (*).

    • Настройки пользователя почты и почтовых контактов : Пользователи почты и почтовые контакты похожи, поскольку оба имеют внешние адреса электронной почты и содержат информацию о людях за пределами организации Exchange. Основное отличие заключается в том, что у пользователей почты есть учетные записи, которые можно использовать для входа в домен Active Directory и доступа к ресурсам в организации.

    • Настройки Outlook : В Outlook можно установить параметры форматирования и кодирования сообщений, описанные в следующем списке:

      • Формат сообщения : Вы можете установить формат сообщения по умолчанию для всех сообщений. Вы можете переопределить формат сообщения по умолчанию при составлении конкретного сообщения.

      • Формат интернет-сообщений : Вы можете контролировать, будут ли сообщения TNEF отправляться удаленным получателям или они сначала будут преобразованы в более совместимый формат. Вы также можете указать различные параметры кодирования сообщений для сообщений, отправляемых удаленным получателям. Эти параметры не применяются к сообщениям, отправляемым получателям в организации Exchange.

      • Формат сообщения получателя в Интернете : можно указать, будут ли сообщения TNEF отправляться определенным получателям или они сначала будут преобразованы в более совместимый формат. Вы можете установить параметры преобразования для определенных контактов в папке «Контакты» и переопределить параметры преобразования для определенного получателя в полях «Кому», «Копия» или «СК» при составлении сообщения. Эти параметры преобразования недоступны для получателей в организации Exchange.

      • Параметры кодирования сообщений получателя в Интернете : вы можете управлять параметрами кодирования MIME или обычного текста для определенных контактов в папке «Контакты», а также переопределять параметры преобразования для определенного получателя в полях «Кому», «Копия» или «СК» по мере необходимости. составить сообщение. Эти параметры преобразования недоступны для получателей в организации Exchange.

      • Международные параметры : Вы можете управлять наборами символов, используемыми в сообщениях.

    Параметры преобразования TNEF

    Вы можете указать параметры преобразования TNEF на следующих уровнях:

    • Настройки удаленного домена
    • Настройки пользователя почты и почтового контакта
    • настройки Outlook, в том числе:
      • Формат сообщения
      • Формат интернет-сообщения
      • Формат сообщения интернет-получателя

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

    Вы можете указать параметры кодирования сообщений на следующих уровнях:

    • Настройки удаленного домена
    • Настройки пользователя почты и почтового контакта
    • настройки Outlook, в том числе:
      • Формат сообщения
      • Интернет-сообщение
      • Формат сообщения интернет-получателя
      • Параметры кодирования набора символов сообщения

    Подробную информацию см. в разделе Параметры кодирования сообщений.

    Чтобы лучше понять параметры преобразования содержимого для внешних получателей, необходимо понимать структуру сообщений электронной почты. Сообщение SMTP основано на простом 7-битном тексте US-ASCII для составления и отправки сообщений электронной почты. Стандартное SMTP-сообщение состоит из следующих элементов:

    • Конверт сообщения : Конверт сообщения определен в RFC 2821. Конверт сообщения содержит информацию, необходимую для передачи и доставки сообщения. Получатели никогда не увидят конверт сообщения, потому что он создается в процессе передачи сообщения и фактически не является частью содержимого сообщения.

    • Содержимое сообщения : Содержимое сообщения определено в RFC 2822. Содержимое сообщения состоит из следующих элементов:

      • Заголовок сообщения : Заголовок сообщения представляет собой набор полей заголовка. Поля заголовка состоят из имени поля, за которым следует символ двоеточия (:), за которым следует тело поля, и заканчиваются комбинацией символов возврата каретки/перевода строки (CR/LF).

        • Имя поля должно состоять из печатных текстовых символов US-ASCII, за исключением символа двоеточия (:). В частности, разрешены символы ASCII со значениями от 33 до 57 и от 59 до 126.

        • Тело поля может состоять из любых символов US-ASCII, за исключением символа возврата каретки (CR) и символа перевода строки (LF). Однако тело поля может содержать комбинацию символов CR/LF при использовании в сворачивании заголовка . Свертывание заголовка — это разделение тела одного поля заголовка на несколько строк, как описано в разделе 2.2.3 RFC 2822. Другие требования к синтаксису тела поля описаны в разделах 3 и 4 RFC 2822.

      • Тело сообщения : Тело сообщения представляет собой набор строк текстовых символов US-ASCII, которые появляются после заголовка сообщения. Заголовок сообщения и тело сообщения разделены пустой строкой, которая заканчивается комбинацией символов CR/LF. Тело сообщения является необязательным. Длина любой строки текста в теле сообщения не должна превышать 998 символов. Символы CR и LF могут появляться только вместе, чтобы указать конец строки.

    Если сообщения SMTP содержат элементы, отличные от простого текста US-ASCII, сообщение должно быть закодировано, чтобы сохранить эти элементы. Стандарт MIME определяет метод кодирования содержимого сообщений, не являющегося текстом. MIME допускает текст в других наборах символов, вложения без текста, составные тела сообщений и поля заголовков в других наборах символов. MIME определен в RFC 2045, RFC 2046, RFC 2047, RFC 2048 и RFC 2077. MIME определяет набор полей заголовков, которые определяют дополнительные атрибуты сообщения. В следующей таблице описаны некоторые важные поля заголовка MIME.

    Имя поля заголовка Значение по умолчанию Описание
    MIME-версия 1,0 Это поле заголовка является первым полем заголовка MIME, которое появляется в сообщении в формате MIME. Это поле заголовка появляется после других стандартных полей заголовка RFC 2822, но перед любыми другими полями заголовка MIME. Почтовые клиенты с поддержкой MIME используют это поле заголовка для идентификации сообщения, закодированного в MIME. Когда это поле заголовка отсутствует, почтовые клиенты с поддержкой MIME идентифицируют сообщение как обычный текст. 908:50
    Тип содержимого текстовый/обычный Это поле заголовка идентифицирует тип носителя содержимого сообщения, как описано в RFC 2046. Тип носителя состоит из типа, подтипа и одного или нескольких необязательных параметров, таких как параметр charset=, определяющий кодировку символов MIME. . Типы, начинающиеся с «x-«, не являются стандартными. Подтипы, начинающиеся с «vnd.» зависят от поставщика. Управление по присвоению номеров в Интернете (IANA) ведет список зарегистрированных типов носителей. Дополнительные сведения см. в разделе Типы носителей MIME.

    Тип мультимедиа multipart позволяет использовать несколько частей сообщения в одном сообщении, используя разделы, определенные для разных типов мультимедиа. Некоторые значения поля Content-Type включают text/plain, text/html, multipart/mixed и multipart/alternative.

    Контент-Передача-Кодирование 7 бит Это поле заголовка может содержать следующую информацию о сообщении:
    • Алгоритм кодирования, используемый для преобразования любых текстовых или двоичных данных, отличных от US-ASCII, которые существуют в теле сообщения.
    • Индикатор, описывающий текущее состояние тела сообщения.

    В сообщении MIME может быть несколько значений поля заголовка Content-Transfer-Encoding. Когда поле заголовка Content-Transfer-Encoding появляется в заголовке сообщения, оно применяется ко всему тексту сообщения. Когда поле заголовка Content-Transfer-Encoding появляется в одной из частей составного сообщения, оно применяется только к этой части сообщения.

    Когда алгоритм кодирования применяется к данным тела сообщения, данные тела сообщения преобразуются в обычный текст US-ASCII. Это преобразование позволяет сообщению проходить через старые серверы обмена сообщениями SMTP, которые поддерживают сообщения только в тексте US-ASCII. Значения поля заголовка Content-Transfer-Encoding, указывающие на то, что в теле сообщения использовался алгоритм кодирования, следующие:

    • Quoted-printable : Этот алгоритм кодирования использует печатные символы US-ASCII для кодирования данных тела сообщения. Если исходный текст сообщения в основном представляет собой текст US-ASCII, кодирование с возможностью печати в кавычках дает более читаемые и компактные результаты. Все печатаемые текстовые символы US-ASCII, кроме символа равенства (=), могут быть представлены без кодирования.
    • Base64 : Этот алгоритм кодирования основан главным образом на стандарте электронной почты с повышенной конфиденциальностью (PEM), определенном в RFC 1421. Кодирование Base64 использует алгоритм кодирования 64-символьного алфавита и выходные символы заполнения, определенные PEM для кодирования данных тела сообщения. . Сообщение в кодировке Base64 обычно на 33% больше, чем исходное сообщение. Кодировка Base64 приводит к предсказуемому увеличению размера сообщения и оптимальна для двоичных данных и текста, отличного от US-ASCII.

    Как правило, в одном сообщении не используется несколько алгоритмов кодирования.

    Если в теле сообщения не использовался алгоритм кодирования, поле заголовка Content-Transfer-Encoding просто идентифицирует текущее состояние данных тела сообщения. Следующие значения поля заголовка Content-Transfer-Encoding указывают на то, что в теле сообщения не использовались алгоритмы кодирования:

    • 7 бит : это значение указывает, что данные тела сообщения уже представлены в формате RFC 2822. В частности, это означает, что должны выполняться следующие условия:
      • Длина всех строк текста не должна превышать 998 символов.
      • Все символы должны быть текстом US-ASCII со значениями от 1 до 127.
      • Символы CR и LF могут использоваться только вместе для обозначения конца строки текста.

      Все тело сообщения может быть 7-битным, или часть тела сообщения в составном сообщении может быть 7-битным. Если составное сообщение содержит другие части, содержащие какие-либо двоичные данные или текст, отличный от US-ASCII, эта часть сообщения должна быть закодирована с использованием алгоритмов кодирования Quoted-printable или Base64.

      Сообщения с 7-битным телом могут перемещаться между серверами обмена сообщениями SMTP с помощью стандартной команды DATA.

    • 8 бит : это значение указывает, что данные тела сообщения содержат символы, отличные от US-ASCII. В частности, это означает, что должны выполняться следующие условия:
      • Длина всех строк текста не должна превышать 998 символов.
      • Один или несколько символов в теле сообщения имеют значения больше 127.
      • Символы CR и LF могут использоваться только вместе для обозначения конца строки текста.

      Все тело сообщения может быть 8-битным, или часть тела сообщения в составном сообщении может быть 8-битным. Если составное сообщение содержит другие части, содержащие двоичные данные, эта часть сообщения должна быть закодирована с использованием алгоритмов кодирования Quoted-printable или Base64.

      Сообщения с 8-битным телом могут передаваться только между серверами обмена сообщениями SMTP, которые поддерживают расширение 8BITMIME SMTP, как определено в RFC 1652, например, серверы, на которых работает Exchange 2000 Server или более поздние версии. В частности, это означает, что должны выполняться следующие условия:

      • Ключевое слово 8BITMIME должно быть объявлено в ответе сервера EHLO.
      • Сообщения по-прежнему передаются с помощью стандартной команды DATA SMTP. Однако в конец команды MAIL FROM необходимо добавить параметр BODY=8BITMIME.
    • Двоичный : Это значение указывает, что тело сообщения содержит текст или двоичные данные, отличные от US-ASCII. В частности, это означает, что выполняются следующие условия:
      • Допускается любая последовательность символов.
      • Длина строки не ограничена.
      • Двоичные элементы сообщения не требуют кодирования.

      Сообщения с двоичными телами могут передаваться только между серверами обмена сообщениями SMTP, которые поддерживают расширение SMTP BINARYMIME, как определено в RFC 3030, например, серверы, на которых работает Exchange 2000 Server или более поздние версии. В частности, это означает, что должны выполняться следующие условия:

      • Ключевое слово BINARYMIME должно быть объявлено в ответе сервера EHLO.
      • Расширение SMTP BINARYMIME можно использовать только с расширением SMTP CHUNKING. Разделение на фрагменты позволяет отправлять большие тела сообщений несколькими меньшими фрагментами. Фрагментирование также определено в RFC 3030. Ключевое слово CHUNKING также должно быть объявлено в ответе сервера EHLO.
      • Сообщения передаются с помощью команды BDAT вместо стандартной команды DATA.
      • Параметр BODY=BINARYMIME необходимо добавить в конец команды MAIL FROM, если сообщение имеет тело сообщения.

    Значения 7bit, 8bit и Binary никогда не существуют вместе в одном составном сообщении. Значения взаимоисключающие. Значения Quoted-printable или Base64 могут появляться в 7-битном или 8-битном составном теле сообщения, но никогда в двоичном теле сообщения. Если составное тело сообщения содержит разные части, состоящие из 7-битного и 8-битного содержимого, все сообщение классифицируется как 8-битное. Если составное тело сообщения содержит различные части, состоящие из 7-битного, 8-битного и двоичного содержимого, все сообщение классифицируется как двоичное.

    Контент-Расположение Приложение Это поле заголовка указывает почтовому клиенту с поддержкой MIME, как он должен отображать вложенный файл, и описано в RFC 2183. Значения этого поля могут быть встроенными или вложенными. Если значение этого поля равно Inline, вложение отображается в теле сообщения. Если значением этого поля является Вложение, вложенный файл отображается как обычное вложение, отдельное от тела сообщения.


    Добавить комментарий

    Ваш адрес email не будет опубликован. Обязательные поля помечены *