851488 - Wrong display of special characters (GE)

Status: RESOLVED DUPLICATE of bug 594646

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Bernd Richardt]

Attachment: Problem mail and message source code

User Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16.2
Build ID: 20130310201055

Steps to reproduce:

Seamonkey displays certain incoming e-mails with wrong german characters (ä,ö,ü,ß), f.e. the word "Grüße" is displayed as "GrÃ1/4ße".
This behaviour is observed since Dec 2012, on Vista x64 and Win 7 x64 system each, always with latest versions of SM-en. A trial installation of  SM-ge showed same results.
Changing the character encoding in "Preferences" or "View" between UTF-8, ISO 8859-1, -15, or Win 1252 has no positive effect.



Actual results:

Thunderbird (current version 17.0.4) displays the original messages fine; forwarding a problem mail from TB to SM corrects the problem.
Affected seem mails originating from Windows Live Mail, Incredimail, TB 17.0.0, sometimes Iphone, Outlook Express Version 6.00.2900.5931 only. Not affected other Outlook, TB before 17.0.0 and after 17.0.4, SM, Telekom products. All mails from GE sources, since US sources for obvious reasons don't use the characters in question.
Viewing a problem mail directly on the server of the provider displays the mail correctly.
Forwarding or editing a problem mail "as new" changes the characters automatically back to normal as well in the edit mode as in the then send/received mail.
Composing and sending mails with GE Characters from SM to SM or TB works correctly.
I have attached a problem mail (Happy Birthday.eml) and the message source code (Happy Birthday source.txt) from Incredimail as a zip.file


Expected results:

Since TB can display all mails correctly, SM should be capable of doing the same!

Comment 1

[Philip Chee]

This is probably Bug 845833 (Wrong character visualization of messages with Cyrillic encoding windows-1251 in SeaMonkey mail after update to 2.16) which in turn is a DUPlicate of Bug 594646.

Comment 2

[GP]

It happens also under XP SP3.
In my case only  , if code of this kind was inside:

      <meta name=3D"ProgId" content=3D"Word.Document">
      <meta name=3D"Generator" content=3D"Microsoft Word 14">
      <meta name=3D"Originator" content=3D"Microsoft Word 14">
<meta name=3D"ProgId" content=3D"Word.Document">
      <meta name=3D"Generator" content=3D"Microsoft Word 14">
      <meta name=3D"Originator" content=3D"Microsoft Word 14">

Comment 3

[GP]

In same cases special characters are shown correct after switching to view
cimplified HTML......

Comment 4

[Tony Mechelynck [:tonymec]]

(In reply to GP from comment #3)
> In same cases special characters are shown correct after switching to view
> cimplified HTML......

Yeah, "View → Message Body As… → Simple HTML" is one known workaround of bug 594646. Not very pretty, but better than nothing.

=3D is the quoted-printable representation of 0x3D, the equal sign. What you should look for is something similar (after dequotedprintablizing) to this:

<meta content="text/html; charset=iso-8859-15" http-equiv="Content-Type">

If the content= attribute (with any charset specified in it) comes before the http-equiv= attribute, we have an instance of bug 594646.