为什么在某些情况下使用 idSMTP 发送的电子邮件无法正确转至新行?
我使用 TIdMessage
和 TIdSMTP
发送纯文本电子邮件。
对于 Body
,我使用一个简单的串联字符串,例如
Body := SomeText + #13#10 +
SomeOtherText + #13#10 +
SomeMoreText + #13#10 +
FinalText;
生成的电子邮件中的 Anywhere,其中一些“#13#10
”不会被忽略。我记录了 Body
变量,我可以看到文本转到新行,无论如何在电子邮件中这不会发生。奇怪的是,这种情况并不是在每条线上都发生,而是只在某些线上发生。
您知道为什么会发生这种情况吗?您能建议检查一下吗?在某些情况下,#13#10
和文本电子邮件正文之间是否可能存在冲突?
更新
经过更多调查(感谢您的评论),我意识到这是一个 Outlook 可视化问题,无论如何,这个问题对我来说仍然不清楚。
这是在 NotePad++ 中打开的电子邮件正文(我打开了从 Outlook 保存的 msg 文件),其中还显示了换行符(您可以将 #13#10 视为 CR LF。我用红色和绿色突出显示了 2 个换行符,它们是Outlook 中存在问题(但您可以看到在 NP++ 中它们看起来像所有其他换行符):
Outlook 中的电子邮件如下所示(请注意,outlook 表示该邮件有额外的换行符,并且它们已被删除,但他提供了恢复它们的选项:
选择该选项后,电子邮件正常:
我不明白为什么这种情况只发生在某些换行符上。这是否有助于您更好地理解问题?
I am sending a text only email using TIdMessage
and TIdSMTP
.
For the Body
I use a simple concatenated string like
Body := SomeText + #13#10 +
SomeOtherText + #13#10 +
SomeMoreText + #13#10 +
FinalText;
Anyway in the generated email some of the "#13#10
" aren't ignored. I log the Body
variable and I can see that the text goes to new line, anyway in the email this doesn't happen. The strange thing is that doesn't happen on every line but only on some lines.
Do you have an idea on why this happens? Can you suggest something to check for? Is there some possible confict between #13#10
and an text email body in some conditions?
UPDATE
After more investigation (thanks to your comments) I realized it is an Outlook visualization problem, anyway the problem is still not clear to me.
This is the body of the email opened in NotePad++ (I opened the msg file saved from outlook) where I show also line breaks (you can see #13#10 as CR LF. I highlighted in red and green the 2 line breaks that are problematic in outlook (but you can see that in NP++ they look like all the other linebreaks):
The email in Outlook looks like this (please note that outlook says that the message has extra line breaks and that they hahve been removed, but he offers an option to restore them:
After choosing that option the email is ok:
I don't understand why this happens only on some line breaks. Does this help you to understand the problem better?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以尝试使用
IdMessage.NoEncode := True
以便正文不会 RCF 821 编码。或者更好地使用现代编码
IdMessage.ContentType := 'text/html'
并将#13#10
替换为编辑:
这是 Outlook Express 问题。
请查看此处和此处。
解决方法是在每行文本的开头添加 2 个空字符,以使 Outlook 不会删除分隔符。
请注意,Microsoft 支持人员还建议使用 HTML 格式作为 Outlook Express 的可能解决方法:
You could try using
IdMessage.NoEncode := True
so that the Body will not be RCF 821 encoded.Or better use modern encoding
IdMessage.ContentType := 'text/html'
and replace#13#10
with<br>
EDIT:
This is an Outlook Express issue.
Look Here and Here.
A workaround would be to add 2 empty characters to the beginning of each line of text in order to make Outlook not remove the breaks.
Note that Microsoft support also suggests using HTML format as a possible workaround with Outlook Express:
如果您的 ContentType 是纯文本,则可能是电子邮件客户端删除了一些换行符。
It might be the email client stripping out some line breaks, if your ContentType is plain text.