Почему в некоторых случаях электронное письмо, отправленное с помощью idSMTP, не переходит должным образом на новую строку?

Я отправляю только текстовое электронное письмо, используя TIdMessage и TIdSMTP.

Для Body я использую простую объединенную строку, например

Body := SomeText + #13#10 +
          SomeOtherText + #13#10 +
          SomeMoreText + #13#10 +
          FinalText;

В любом случае в сгенерированном электронном письме некоторые из «#13#10» не игнорируются. Я регистрирую переменную Body и вижу, что текст переходит на новую строку, во всяком случае в письме этого не происходит. Странно то, что это происходит не на каждой строке, а только на некоторых строках.

У вас есть идея, почему это происходит? Не подскажете, что проверить? Возможен ли конфликт между #13#10 и текстом электронного письма при некоторых условиях?

ОБНОВЛЕНИЕ

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

Это тело письма, открытого в NotePad++ (я открыл файл msg, сохраненный из Outlook), где я также показываю разрывы строк (вы можете видеть # 13 # 10 как CR LF. Я выделил красным и зеленым 2 разрыва строк, которые проблематично в Outlook (но вы можете видеть, что в NP++ они выглядят так же, как и все остальные разрывы строки):

Электронная почта в Outlook выглядит так (обратите внимание, Outlook говорит, что в сообщении есть лишние разрывы строк и что они были удалены, но предлагает возможность их восстановить: Электронная почта в Outlook плохо отображается]

После выбора этой опции электронная почта в порядке: введите описание изображения здесь

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


person LaBracca    schedule 17.01.2012    source источник
comment
Вы используете последнюю версию Indy (10.5.8)?   -  person mjn    schedule 17.01.2012
comment
вы можете использовать IdMessage.ContentType := 'text/html' и заменить #13#10 на <br>.   -  person kobik    schedule 17.01.2012
comment
@mjn хорошая мысль. Я был уверен, что у меня 10.5.8, но на машине для сборки у меня все еще есть та, которая поставляется с Delphi 2009. Сейчас я обновлю и попробую еще раз.   -  person LaBracca    schedule 17.01.2012
comment
Пожалуйста, покажите фактическое сгенерированное электронное письмо и укажите, что вы считаете неправильным.   -  person Remy Lebeau    schedule 18.01.2012
comment
Подтверждаю проблема есть и с 10.5.8. Я обновил свое сообщение, пожалуйста, посмотрите последнюю часть и посмотрите, может ли это помочь.   -  person LaBracca    schedule 18.01.2012
comment
Мне нужно было бы видеть необработанные данные электронной почты, которые Indy генерирует/отправляет, а не данные, которые Outlook интерпретирует/сохраняет. Используйте анализатор пакетов, такой как Wireshark, или подключите один из компонентов Indy TIdLog... к TIdSMTP для сбора этих данных. То, что вы описали, похоже на проблему с Outlook, а не с Indy.   -  person Remy Lebeau    schedule 21.01.2012


Ответы (2)


Вы можете попробовать использовать IdMessage.NoEncode := True, чтобы тело не было RCF 821 закодировано.

Или лучше использовать современную кодировку IdMessage.ContentType := 'text/html' и заменить #13#10 на <br>

EDIT: Это проблема Outlook Express.

Посмотрите здесь и Здесь. Обходной путь — добавить 2 пустых символа в начало каждой строки текста, чтобы Outlook не удалял разрывы.


Обратите внимание, что служба поддержки Microsoft также предлагает использовать формат HTML в качестве возможного обходного пути с Outlook Express:

Способ 2. Использовать формат HTML или Rich Text При создании новых элементов можно использовать форматы HTML или Rich Text. Или вы можете изменить существующие сообщения на эти форматы.

person kobik    schedule 17.01.2012
comment
Этот ответ предлагает некоторые обходные пути, но не отвечает на вопрос, в котором спрашивалось, почему строки отправляются неправильно в первую очередь. - person Rob Kennedy; 17.01.2012
comment
Я хорошо знаю этого Роба. Это может быть Indy, это может быть почтовый клиент. Я предложил альтернативу :) - person kobik; 17.01.2012
comment
Если возможно, мне нравится использовать #13#10, потому что я хочу отображать сообщение и на TMemo, поэтому меня интересует вариант NoEncode. Не могли бы вы сказать мне, какие преимущества / недостатки и какая кодировка будет в этом случае? - person LaBracca; 18.01.2012
comment
нет проблем с отображением его в TMemo. просто назначьте Memo.Text переменной S и измените #13#10 на <br> и отправьте ее. - person kobik; 18.01.2012
comment
Спасибо, Кобиб, да, я сначала пойду на трюк с двумя пустыми символами, так как я близок к выпуску, и чем меньше изменений, тем лучше, а затем я воспользуюсь вашим предложением <br> + переменная идея в следующем выпуске. - person LaBracca; 18.01.2012
comment
Свойства TIdMessage.Body и TIdText.Body являются объектами TStrings, поэтому не имеет значения, какие разрывы строк вы используете в коде. Присвоение свойству TStrings.Text автоматически разделит строки. Затем Indy будет отправлять каждую строку отдельно с CRLF в конце в соответствии с требованиями RFC. Вы можете Assign() любой TStrings объект использовать в свойстве TMemo.Lines, не беспокоясь о том, какие разрывы строк используются. - person Remy Lebeau; 21.01.2012

Это может быть почтовый клиент, удаляющий некоторые разрывы строк, если ваш ContentType представляет собой обычный текст.

person Sam M    schedule 17.01.2012
comment
Вы имеете в виду, что почтовый клиент неправильно читает мою электронную почту, неправильно интерпретируя разрывы строк? - person LaBracca; 18.01.2012
comment
Да, я подтверждаю, см. мое последнее обновление вопроса. Но почему? - person LaBracca; 18.01.2012
comment
См. http://support.microsoft.com/kb/287816 для получения информации об Outlook и перерывы. Похоже, в Outlook есть опция, которая установлена ​​по умолчанию. Я не пробовал использовать форматированный текст, как предлагает Microsoft. В конце концов я переключился на почтовые сообщения в формате html, но это создает свой собственный набор проблем при работе с клиентами Outlook и фильтрами нежелательной почты. - person Sam M; 18.01.2012
comment
Большое спасибо, 95% моих клиентов используют Outlook, поэтому я не могу сказать им, чтобы изменить почтовый клиент, поэтому мне нужно решить проблему. Спасибо, я выбираю это как ответ, так как это ответ на вопрос (так что это может помочь другим пользователям переполнения стека), но я буду использовать идею kobib для решения проблемы. - person LaBracca; 18.01.2012
comment
этот запрос в службу поддержки не объясняет, ПОЧЕМУ Outlook решает удалить разрывы строк. Особенно для обычных текстовых сообщений. - person Remy Lebeau; 21.01.2012
comment
@Remy Из того, что я читал на разных сайтах, MS сделала это, чтобы сделать текстовые электронные письма более плавными, если они написаны в текстовых редакторах, которые добавляют CR / LF для переноса строк. - person Sam M; 23.01.2012