Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
(possible) bug with TIdMessageBuilderHtml
#1
First of all, thanks for the new forum. It is unclear whether the community.embarcardero.com is a replacement for forums.embarcardero.com but all I see is that community is working and forums is not. Anyway, onto the possible bug.

In the example:

Quote:with TIdMessageBuilderHtml.Create do
try
PlainText.Text := 'plain text goes here';
FillMessage(IdMessage1);
finally
Free;
end;

It says that if PlainTextCharset and PlainTextContentTransfer are not specified it uses default values. The above generates:

Quote:Content-Type: text/plain; charset=us-ascii

plain text goes here

Good so far.

If I add some Unicode stuff:

Quote:with TIdMessageBuilderHtml.Create do
try
PlainText.Text := 'äüø';
FillMessage(IdMessage1);
finally
Free;
end;

Generates:

Quote:Content-Type: text/plain; charset=utf-8

äüø

It seems to use 8bit encoding - which is good... except... Content-Transfer-Encoding: 8bit (or maybe binary) is missing as it is using 8bit content in this case.

I can fix the problem by adding PlainTextContentTransfer := '8bit' or specifying PlainTextContentTransfer := 'quoted-printable' but the problem may be the default behavior of TIdMessageBuilderHtml which should specify this automatically, yet it doesn't. I noticed though that it does so for multipart messages but not for plain-text ones.

Based on the documentation (http://www.indyproject.org/Sockets/Blogs...16.EN.aspx), it should by default use quoted-printable if nothing is specified. And that does work for multipart messages.

I also tried to set the PlainTextCharset explicitly to utf-8 and not set PlainTextContentTransfer and same problem happens and causes an issue with some servers. It is probably the best to always specify the Content-Transfer-Encoding

RFC2046 -Note that if the specified character set includes 8-bit characters and such characters are used in the body, a Content-Transfer-Encoding header field and a corresponding encoding on the data are required in order to transmit the body via some mail transfer protocols, such as SMTP [RFC-821].
Reply
#2
(04-30-2018, 09:43 AM)johnmay Wrote: First of all, thanks for the new forum. It is unclear whether the community.embarcardero.com is a replacement for forums.embarcardero.com but all I see is that community is working and forums is not.

EMBT management thinks it is. But I've never found a single person outside of EMBT management who things the community site is a good thing. Last I looked it didnt even have threading.
Reply
#3
(04-30-2018, 09:43 AM)johnmay Wrote: First of all, thanks for the new forum. It is unclear whether the community.embarcardero.com is a replacement for forums.embarcardero.com but all I see is that community is working and forums is not.

Embarcadero WANTS the community forums to replace the old forums site, but the community forums have been online for 4 years now and still SUCK big time. Nobody likes them, and Embarcadero can't even make them work right (major bugs/headaches with it).  So, unless Embarcadero finally decides to just pull the plug on the old forums site (which many users have been very vocal against), I doubt it will EVER be replaced with the community forums, at least not anytime soon. (UPDATE: they finally pulled the plug!  Sad  Confused  Angry )

That being said, the old forums site does break down every so often, and it usually takes Embarcadero several days to fix it.

(04-30-2018, 09:43 AM)johnmay Wrote: It says that if PlainTextCharset and PlainTextContentTransfer are not specified it uses default values.

If you are referring to my blog article about the TIdMessageBuilder classes, what it actually says is:

Quote:- PlainTextCharset: the character set that the PlainText will be encoded in (UTF-8, etc).  If not specified, Indy's default charset will be used.

- PlainTextContentTransfer: the transfer encoding that the charset-encoded PlainText will be encoded in (base64, quoted-printable, etc).  If not specified, 'quoted-printable' will be used.

'text/plain' is the default media type used by TIdMessageClient when encoding a TIdText object.  When TIdText.Charset is not specified, Indy's default charset is US-ASCII, unless specified otherwise via the global GIdDefaultTextEncoding variable in the IdGlobal unit.

'quoted-printable' is the default transfer encoding used by TIdMessageClient when encoding a TIdText object, when its ContentTransfer is not specified.

(04-30-2018, 09:43 AM)johnmay Wrote: The above generates:

Quote:Content-Type: text/plain; charset=us-ascii

plain text goes here

Good so far.

The code you have presented does not assign any attachments or HTML to the builder, so the builder won't generate any TIdText objects.  The PlainText will be assigned to the TIdMessage.Body property instead, and 'text/plain' will be assigned to the TIdMessage.ContentType property.  That property has a setter method which assigns 'us-ascii' as the default charset for 'text/...' data if no charset is specified.

That is different when TIdText objects are used, because the TIdMessagePart.ContentType property setter does not generate a default 'charset' attribute, like the TIdMessage.ContentType property setter does.

(04-30-2018, 09:43 AM)johnmay Wrote: If I add some Unicode stuff:
...
Generates:

Quote:Content-Type: text/plain; charset=utf-8

äüø

Actually, it doesn't.  Indy doesn't look at the content of the assigned Text to decide which charset to use.  It will NEVER auto-generate a 'charset=utf-8' attribute, like you claim.  When I try the code you showed, it generates 'charset=us-ascii' instead, as expected.

The ONLY way the 'charset' attribute could ever be 'utf-8' is if you set the builder's PlainTextCharSet property to 'utf-8', or you manually set the TIdMessage.CharSet or TIdText.CharSet properties after the builder has populated the TIdMessage.

(04-30-2018, 09:43 AM)johnmay Wrote: It seems to use 8bit encoding - which is good... except... Content-Transfer-Encoding: 8bit (or maybe binary) is missing as it is using 8bit content in this case.

In your examples, the TIdMessage.ContentTransferEncoding property is being left blank, and TIdMessage does not generate a default value for that property.  The builder has its own PlainTextContentTransfer property, which you are not populating.  Indy is not going to try to guess which transfer encoding to use based on which charset is used.  If you want to use a charset that requires 8-bit encoding, it is your responsibility to populate the builder's PlainTextCharSet and PlainTextContentTransfer properties accordingly.

(04-30-2018, 09:43 AM)johnmay Wrote: I can fix the problem by adding PlainTextContentTransfer := '8bit' or specifying PlainTextContentTransfer := 'quoted-printable' but the problem may be the default behavior of TIdMessageBuilderHtml which should specify this automatically, yet it doesn't. I noticed though that it does so for multipart messages but not for plain-text ones.

Indeed, PlainTextContentTransfer is not behaving the way I wrote in my article in the case where the PlainText ends up in the TIdMessage.Body instead of a TIdText object in the TIdMessage.MessageParts.  I have fixed that now.  I have also made 'utf-8' be the default charset when using a Unicode version of Delphi or FreePascal.

(04-30-2018, 09:43 AM)johnmay Wrote: Based on the documentation (http://www.indyproject.org/Sockets/Blogs...16.EN.aspx), it should by default use quoted-printable if nothing is specified. And that does work for multipart messages.

That is because TIdMessageClient has a lot more logic in place when handling the TIdMessage.MessageParts collection than it has when handling the TIdMessage.Body property.

Reply
#4
Thanks for the reply and default PlainTextContentTransfer := 'quoted-printable' if not populated. Like I wrote, it was a minor issue, but I wanted to point that up as it was not filling it up automatically as described for plain text only messages (not multipart/alternative that is). Also good that UTF-8 is the default now, I see no benefit of using US-ASCII nowadays.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)