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

charset lost during save email as html

RESOLVED DUPLICATE of bug 153401

Status

SeaMonkey
MailNews: Message Display
--
major
RESOLVED DUPLICATE of bug 153401
10 years ago
8 years ago

People

(Reporter: Igor Velkov, Unassigned)

Tracking

Trunk
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008051302 SeaMonkey/2.0a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9pre) Gecko/2008051302 SeaMonkey/2.0a1pre

I have a letter with some non-ASCII characters; letter contain "charset" property to correctly display this characters to me.
When I save a letter via "file->save as", a got HTML without any charset information.

Reproducible: Always

Steps to Reproduce:
1. got any email with non-ASCII characters 
2. save it to HTML file via menu "file->save as", choose HTML as target type
3. Try to open result HTML file in browser, or look inside HTML text
Actual Results:  
There no information about text encoding to display text properly

Expected Results:  
all parts of text must have encoding information, maybe, different, as different parts of multi-part mail message.
(Reporter)

Updated

10 years ago
Version: unspecified → Trunk

Comment 1

9 years ago
Please, Igor insert test mail via "Add an attachment".
(Reporter)

Comment 2

9 years ago
Created attachment 325778 [details]
email exported as .eml
Looks like it was converted to utf-8 during upload, but originally it koi-8r encoding.
(Reporter)

Comment 3

9 years ago
Created attachment 325779 [details]
same email exported to html

look into html and see no any charset info
(Reporter)

Updated

9 years ago
Attachment #325778 - Attachment description: email exported as .eml → email exported as .eml Looks like it was converted to utf-8 during upload, but originally it koi-8r encoding.

Comment 4

9 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; cs; rv:1.9.0.1pre) Gecko/2008062408 SeaMonkey/2.0a1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9
Thunderbird version 3.0a2pre (2008062403)

Confirming this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 5

9 years ago
Dupe of Bug 153401?
(In reply to comment #2)
> email exported as .eml
(In reply to comment #3)
> same email exported to html

1. Add KOI8-R to View/Character Encoding list via Cutomize List (Seamonkey).
   Auto Detect = Universal
2. Display .eml by Seamonkey, View/Source => KIO8-R is selected
   Content-Type: text/plain; charset=KOI8-R; format=flowed
2-1. Display html by Seamonkey, View/Source => UTF-8 is selected
     No <meta ... charset=xxx> in HTML source.
2-2. Change View/Character Encoding of Source view to KOIR-8
     => characters in the HTML is displayed as expected.

If user enables auto-detect, problem usually doesn't occur. However, auto-detect unfortunately detects charset of the HTML written in koir-8 as UTF-8. Unless koir-8 only byte codes exist in HTML source, it's impossible to detect as koir-8.  
So <meta ... charset=koir-8> is required in your case. 

Yes, Dupe of Bug 153401.
> auto-detect unfortunately detects charset of the HTML written in koir-8 as UTF-8.

It was wrong. I completely forgot about next. Sorry for my confusion.
  B.M.O automatically sends "Content-Type: text/html; charset=UTF-8"
  when MIME type of attachment is set to text/html.

In your HTML file case, auto-detect can detect the HTML as koir-8.
So, next doens't produce wrong display problem in many cases.
> Actual Results:  
> There no information about text encoding to display text properly
"There no information about text encoding" is apparently DUP of Bug 153401 though.

Closing as DUP of Bug 153401.
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 153401
You need to log in before you can comment on or make changes to this bug.