206421 - non-ascii/international characters are not displayed correctly if you view a file-stored email (.eml, message/rfc822) in the browser

Status: RESOLVED DUPLICATE of bug 227360

(SeaMonkey :: UI Design, defect)

Description

[Reinhard]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030507

If you save an german email containing german umlauts as file - after reopening
with mozilla the umlauts are damaged.

Reproducible: Always

Steps to Reproduce:
1.See http://www.8ung.at/quintus/mozilla_probs/moz02.htm
2.
3.

Comment 1

[u63580]

Yup, can see this in 20030512.  Oddly, if I open the message with Outlook
Express, all is fine.  

I find, for example:

Grüße

Is stored as:

Gr=FC=DFe

And re-displayed by Mozilla as:

Grüße

 

Comment 2

[Asa Dotzler [:asa]]

->XP APps.

Comment 3

[OstGote!]

To view saved email messages (EML - text/rfc822 format) correctly with the
browser  you have to switch to UTF-8 as character encoding after load/open
(select View - Character Encoding - Unicode (UTF-8)). The browser window does
not respect the character encoding of the email message. Try it. Similiar is Bug
56908. 

Comment 4

[OstGote!]

(In reply to comment #3)
>The browser window does not respect the character encoding of the email message. 

Correct me: The character encoding is respected (look at view - character
encoding) but in spite of the display is wrong. I guess because there is an
internal UTF-conversion. Example: attachment 128151 [details]. The browser displays that
ISO-8859-15 is used (that is correct, see source) but the umlauts are still
wrong. Now change to UTF-8 and the display is ok.

Please change the summary of the bug to something like "International characters
are not displayed correctly if you view a file-stored email (.eml,
message/rfc822) in the browser". Thanks.

Comment 5

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 6

[WADA:World Anti-bad-Duping Agency]

Explanation by Comment #4 is clear and accurate, and this bug is earlier discovery than Bug 227360. But bug summary and original report(comment #ZERO) of Bug 227360 is clearer than this bug's one, and good test cases are attached to Bug 227360.

Closing as DUP of Bug 227360. If DUPing is wrong, re-open, please.

Comment 7

[WADA:World Anti-bad-Duping Agency]

Forgot DUPing... Confirming and DUPing.