We are using the chilkat mail ActiveX component to render email for customers. We are seeing an issue with Turkish characters. The transfer encoding on their email is set to 8bit and charset is set to utf-8 but the characters are garbled when rendered. We saw that chilkat was assigning 'quoted-printable' to the transfer type despite the mime showing 8bit So to that end, I decided to create a blank Email Chilkat object and add the turkish characters to the body. I would set to the transfer encoding to 8bit but even when I do this., it is defaulting to quoted printable.
No matter what I do to change the transfer encoding to 8bit, chilkat defaults to quoted printable. Can anyone tell me where I am going wrong?
Private Sub Form_Load() Dim Message As New ChilkatEmail Dim RenderedContent As String Dim MimeOutput As String RenderedContent = "Test çir çöz süçök gür igüöç" Call Message.AddHeaderField("content-transfer-encoding", "8bit") Message.body = RenderedContent Message.Charset = "utf-8" MimeOutput = Message.GetMime Debug.Print MimeOutput End Sub
Output in console is:
MIME-Version: 1.0 Date: Fri, 06 Oct 2017 11:27:29 +0100 Message-ID: D15388282CA759B1915588ED1CA31DC62B52BEF0@SPDEV32WIN10 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal)
Test =C3=A7ir =C3=A7=C3=B6z s=C3=BC=C3=A7=C3=B6k g=C3=BCr ig=C3=BC=C3=B6=C3= =A7
I understand the problem now..
If Chilkat is asked to return the MIME as a string, then it is forced to "safeguard" the MIME bodies. For example, if there are binary attachments, such as JPG images, PDF files, etc., then these cannot returned in the 8bit encoding if MIME is to be returned as a string. Safeguarding these bodies means changing the content-transfer-encoding to base64. (If, however, the email is just sent via SendEmail, you'll find that the bodies are in fact sent using "8bit" for the content-transfer-encoding.)
But what about text bodies? Why would they need to be safeguarded? If the text body contains only 7bit us-ascii chars, then there's no need. 8bit is fine. If, however, the text body contains 8bit chars (non-us-ascii chars), then it must be safeguarded. The reason is that if the body is not safeguarded, you could end up with a byte representation of the email that does not match the charset specified in the MIME header.
In your code snippet above, imagine if Chilkat maintained the "8bit" encoding, and you save MimeOutput to a file. You'd likely be saving the MimeOutput string using the ANSI (windows-1252) character encoding, where each of the accented chars is a single byte. However, the MIME header claims that you have utf-8. Therefore, a program that reads the MIME would be trying to interpret the bytes of the text body as utf-8, and thus the characters would be garbled or lost. Forcing the content-transfer-encoding to "quoted-printable" safeguards from this situation occurring.
The act of calling GetMime (i.e. the request to return the MIME as a string) is what triggers the safeguarding of the bodies. You can do this test: Instead of calling GetMime, save the email to a file by calling SaveEml. You should see that the 8bit encoding is maintained.
In summary: Getting the MIME as a string forces the safeguarding of the MIME bodies. If you avoid getting the MIME as a string, you'll find that sending the email (i.e. the SendEmail method), or saving to a file (SaveEml), or methods that return the email in a BinData or byte array, maintain the 8bit encoding.
Thanks Nick, I'm having a look...
Great! Thanks :)
This makes a lot of sense and was very useful.
I see from our code that we are referencing the Mime text from a string variable, which would explain why the content is being shown as quoted printable.
Once I ran the Message source text through a function to convert it to UTF- byte by byte, it rendered the turkish characters
Thanks a lot for your speedy reply and assistance!