Opened 3 years ago

Last modified 2 years ago

#16801 new bug

an "é" typed in an email i type with Bemail, ultimately show in Bemail as a "é"

Reported by: AlienSoldier Owned by: nobody
Priority: normal Milestone: R1
Component: Applications/Mail Version: R1/beta2
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

An "é" typed in an email i type with Bemail, ultimately show in Bemail as a "é" if i check it back in my sent email directory. If i check it in my google mail browser interface, the sent email have the right "é" with no "é" to be seen.

Change History (13)

comment:1 by nephele, 3 years ago

Sounds like a UTF-8 file is beeing read as if it was ISO 8859-1 or 8859-15 or so, with what are you viewing the mail?

(Am asking since the mail i've send with Mail never got placed in the send folder, only in my home, but perhaps that is just a bug with imap..)

comment:2 by AlienSoldier, 3 years ago

Viewing the mail with the native Mail app. The only difference is that is was sent. For exemple this notification when i opened it with Mail from my "In" directory showed the "é" fine.

Using SMTP.

comment:3 by AlienSoldier, 2 years ago

Still happen.

Not sure anymore of what i was meaning by this btw "For exemple this notification when i opened it with Mail from my "In" directory showed the "é" fine" :)

Here is some reading of the mail as text:

first is sent from BMail. subject "more é" text "ké":

Subject: more =?iso-8859-15?q?=E9?=

X-Mailer: Mail/Haiku 3.0.3

Date: Sun, 19 Dec 2021 14:35:51 -0500

Message-Id: <5180961017-BeMail@shredder>

Mime-Version: 1.0

Content-Type: text/plain

Content-Transfer-Encoding: quoted-printable

k=C3=A9

second (the one i can read fine) is sent from gmail web interface, subject "more é" text "ké" (so exactly the same thing):

MIME-Version: 1.0

Date: Sun, 19 Dec 2021 13:46:43 -0500

Delivered-To: my email

Message-ID:

Subject: =?UTF-8?Q?more_=C3=A9?=

From: my email

To: my email

Content-Type: text/plain; charset="UTF-8"

Content-Transfer-Encoding: base64

a8OpDQo=

comment:4 by nephele, 2 years ago

The first email is iso8859-15 encoded, Maybe the mailer is trying to open it with utf-8? Can you open the email and then select the encoding directly? Message->Encoding->Iso Latin 9 (ISO-8859-15)

If it then shows correctly the issue is that The mail application opens files as UTF-8 even though they are anotated as not beeing UTF-8.

A second issue is that the mailer apparently sends messages with iso8859-15 per default, even though it should really use UTF-8 (I mean, mailers /should/ deal with encodings... but then the end probably treats everything as utf-8 too depending on the system...)

comment:5 by AlienSoldier, 2 years ago

Seem the body of text was encoded in utf-8 as it show correclty when i select "utf-8". Choosing encoding Iso Latin 9 (ISO-8859-15) make it appear badly again. So right now it open by default in so Latin 9 (ISO-8859-15) for text (subject was always displayed correctly).

One would expect that sending from bemail and receiving from bemail, the text would not change encoding along the trip.

comment:6 by nephele, 2 years ago

Yes. it shouldn't.

But what you wrote confuses me more, the header of your first email sais it is iso8859-15 encoded, but if it is displayed correctly with utf-8 selected that would mean that it when sending originally put the wrong encoding info in the email, and then later uses this to select the wrong encoding.

Maybe this is a problem with sending the email then? Can you verify this? maybe send an email to yourself :D, it should arrive mostly identical except for more headers. See if the send one mentions iso8859-15 but then also displays correctly only with utf-8

comment:7 by nephele, 2 years ago

It looks like the problem is with BeMail not including in the email which encoding it is using for the body, we should probably also include charset="UTF-8"

BeMail: Content-Type: text/plain

Gmail webmailer: Content-Type: text/plain; charset="UTF-8"

comment:8 by nephele, 2 years ago

As an additional note: iOS Mail displays the email correctly even without the encoding specified, we should probably include it regardless.

comment:9 by dsizzle, 2 years ago

The first message isn't iso8859-15 encoded, just the header is. The body is UTF-8 charset in quoted-printable encoding.

iirc iOS mail might assume UTF-8 which is why it displays correctly. But "k=C3=A9" decodes to "ké" with charset of UTF-8, and to "é" with charset of iso8859-15.

I suspect in modern times UTF-8 is a more sensible default than iso8859-15, but it makes sense to include it in the Content-Type MIME header line as Gmail does

Last edited 2 years ago by dsizzle (previous) (diff)

comment:10 by dsizzle, 2 years ago

<deleted>

Last edited 2 years ago by dsizzle (previous) (diff)

comment:11 by nephele, 2 years ago

I can't really reproduce this anymore. I tried sending an email to myself with é as a content Here are the headers:

Subject: Re: test
X-Mailer: Mail/Haiku 3.0.3
Mime-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

é

It looks like the charset is send correctly, and in the code it also looks to cary this info around everywhere and then send it. maybe you are triggering an edge case? the normal case seems to work anymore

I do have utf-8 set in my mail preferences though, maybe this makes it behave nicely. what do you have set to reproduce it?

comment:12 by AlienSoldier, 2 years ago

Humm the message encoding in the drop down menu (in the message area of the tool bar) was not kept after closing bemail. I then looked in preference and there is another encoding setting there. The one there was set to nothing, i mean not "nothing" as a choice but the whole rectangle was empty. I did set it to uft-8 now. Like you i now receive the correct character in the body of the text, but the problem is still there for the email sent before doing that setting manipulation. So it seem that haiku should need to be distributed with uft-8 encoding as default because mine seemed to be in undetermined state (my second computer was also empty setting). Once set to anything, it is not possible to have that option empty again so i guess the only way to trigger that bug is from a fresh install.

comment:13 by dsizzle, 2 years ago

I suspect that's the issue - I think having the setting default to anything (maybe UTF-8) would fix it.

Note: See TracTickets for help on using tickets.