If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

UTF8 utf-8 characters rendered incorectly (as: <?> <?> <?>) in most windows from in example ISO-8859-2 emails

RESOLVED INVALID

Status

Thunderbird
General
--
major
RESOLVED INVALID
12 years ago
12 years ago

People

(Reporter: Rafa&#322; Maj, Assigned: Scott MacGregor)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1)

My settings are all to UTF-8.
UTF8 is default encoding of the mail box, all fonts in configruation (to all regions: Central Europe, and so on) are set to UTF8 encoding (and font is typical, like Serif)

When i hav email encoded in in example iso-8859-2 then the special characters (and all text after first special character) in all headers are incorectly decoded. 

I will attach a screenshot ilustrating the problem.

Example email:


From - Wed Jan 11 10:25:28 2006
X-Account-Key: account9
X-UIDL: 0134563102bbda1d
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: from yan.interia.pl ([217.74.66.8]:44261 "EHLO taj.interia.pl")
	by kps8.test.onet.pl with ESMTP id <S1180324AbWAKJBs>;
	Wed, 11 Jan 2006 10:01:48 +0100
Received: from pup.interia.pl (pup.interia.pl [217.74.66.37])
	by mx-out.strefa.interia.pl (Postfix) with SMTP id 82EB833F17F;
	Wed, 11 Jan 2006 10:01:47 +0100 (CET)
To:	foo@bar.invalid
Subject: Zamówienie zegarków na kwotê xxx
From:	potwierdzenie <potwierdzenie@foo.bar.invalid>
User-Agent: script
X-Accept-Language: en-us, en, de, pl, it
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
[...]

List wys³any z sklepu Zegarki Chrono Online
List wys³any na ¿yczenie:
[...]

Reproducible: Always

Steps to Reproduce:
1. get email with UTF8 characters
2. follow my setup/configuration
3. look

Actual Results:  
Text in mailbox view (columns subjects, From) as well as in message view are renderd/decoded incorrectly: all characters from the first non ASCII character (including it) are replaced by a character that looks like a small question mark on a turned around rectangle, sort of like: <?>

Also attachments file names are broken.
Also attachments while Save As are broken, so it is impossible to save with a correct file extension, one have like: 
  Rafa??????????
instead of:
  Rafa³ Test.doc
and so on.


Expected Results:  
Correctly render the characters
(Reporter)

Comment 1

12 years ago
Created attachment 208462 [details]
utf8 setting: non-utf8 characters wrongly decoded/displayed

Characters from iso-8859-2 email are encoded wrongly almost  everywhere
(Reporter)

Comment 2

12 years ago
I was a bit incorrect, the bug is when one recives NON UTF8 email (and the settings are to default to try to use UTF8 encoding)
The screenshot doesn't show whether you have "Apply the default character encoding to all incoming messages" checked. If you do, it would explain this bug. Leaving it unchecked will apply UTF-8 to messages with no encoding specified, but allow messages that specify another encoding, like the one shown in the screenshot, to display correctly.

Comment 4

12 years ago
> Content-Type: text/plain; charset=ISO-8859-2
> Content-Transfer-Encoding: 7bit

In addition to what Simon mentioned, there's a small possibility that 'C-T-E: 7bit' tricked TB to misinterpret the message. However, it's not likely. 

Anyway, it's a BAD idea to set the default encoding for *incoming* emails to UTF-8 because it's very rare that UTF-8 encoded messages come without the correct label while it's still common for non-UTF-8 messages to be unlabelled (or mislabelled.)

 
 
(Reporter)

Comment 5

12 years ago
For now, I think that perhaps just my settings where a bit messed up, and after all it do work correctly.

Sorry for trouble, Im closing this bug report then
Status: UNCONFIRMED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.