Closed Bug 15766 Opened 25 years ago Closed 25 years ago

Non-ascii in plain text attachment body are garbled

Categories

(MailNews Core :: Internationalization, defect, P3)

Product:
MailNews Core
Component:
Internationalization
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: marina, Assigned: nhottanscp)

Details

Attachments

(1 file)

this is a plain text file a used
913 bytes, text/plain
Details 
When receiving a message with plain text attachment that contains non-ascii in
the body they are garbled.It looks right in 4.x and this is what we have in Page
source:
Content-Type: text/plain;
 name="plain.txt"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline;
 filename="plain.txt"
I remember that : inline was causing problems before.
Steps to reproduce:
-open new mail;
-click Attach icon, attach a plain text file (see an exemple in the
attachments);
-send message to both 4.x and 5.0;
-open message in 4.x and 5.0;
//note: in 4.x mail body has a correct display of the 8-bit chars opposite to
the wrong display in 5.0

    
  
Summary: Non-ascii in plain text attachment body are garbled → Non-ascii in plain text attachment body are garbled

    
    

    
  
The problem starting with today's build?
How about the main body with 8 bit chars (4.x can send it by setting a pref)?

    
    

    
  
Could you check the charset for the first part?
If the first pasrt is US-ASCII, can we actually
view 8-bit Latin 1 data in the 2nd part of multupart?
Could this possibly be charset menu not working in
this case? --> known problem.

    
    

    
  
It turns out that 5.0 can display the same plain text file
when it is sent from 4.7. Note the structural difference:

--------------------- Sent from 4.7 --------------------

This is a multi-part message in MIME format.
--------------2FAA5FFF6A8E5638C8852496
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
T&eacute;l&eacute;chargez Netscape</html>

--------------2FAA5FFF6A8E5638C8852496
Content-Type: text/plain; charset=iso-8859-1;
 name="frhome.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline;
 filename="frhome.txt
----------------------------------------------------

Compare this to the one sent from 5.0 via polyglot as SMTP server:

--------------- Sent from 5.0 via polyglot --------------

This is a multi-part message in MIME format.
--------------040409010406090707090205
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


--------------040409010406090707090205
Content-Type: text/plain;
 name="frhome.txt"
Content-Disposition: inline;
 filename="frhome.txt"
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by netscape.com id LAA23987

-------------------------------------------------------------

Note that nsmail-2 does not do QP-conversion but polyglot does.
In any case, 5.0 has difficulty displaying Latin 1 characters
in the latter (sent from 5.0) but not the former (sent from 4.7).

The only significant difference I see here is the lack of the charset
parameter in the latter.

    
    

    
  
My point is that whether or not the attachment
contains raw 8-bit does not seem to be the controlling
factor for this problem. 5.0 has the same problem with
the QP data when the multipart does not have a charset
parameter.

Is this then a duplicate of "charset menu not effective for the
body" bug?

    
    

    
  
BTW,

1. Main Body in 8 bit from 4.7 -- display OK in 5.0.
2. Won't be able to check if this is a regresion from M10
   because of Bug 15577 in M10.

    
    

    
  
1.plain text body sent from 5.0 comes blank (bug#15313)
2.plain text settings in prefs.js are ignored (bug#15238), you still get an html
window
3.if your settings are html, true, your attachment will hang apprunner upon send
The conclusion of testing is:
-View is OK (Plain text sent from 4.x is displayed correctly);
-charset for the first part is us-ascii (but the text can not be seen because of
bug#15313);

    
  
Status: NEW → ASSIGNED

    
    

    
  
If the attachment does not have charset label, the main body charset is used. We
do not label attachment charset unless it has a label (html META charset). So
the behavior described in this bug is an expected result.
The problem is resolved by the auto charset detection (e.g. Japanese) but it is
default to off and no detection for Latin1.
How about changing the fallback a little bit to use Latin1 if the attachment is
not labeled and the main body is us-ascii? Rich, what do you think?

    
  
Target Milestone: M11

    
  
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED

    
    

    
  
I checked in a fix yesterday. Using today's build (my locale), I can see a plain
text French text which had the problem before the fix.

    
  
Status: RESOLVED → REOPENED

    
    

    
  
in the today build 1999-10-18-09 M11 i can reproduce the problem so reopening

    
  
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago

    
    

    
  
If the charset detection is on the fall back I added is not used.
Verification should be done without charset detection.

    
  
Status: RESOLVED → VERIFIED

    
    

    
  
without charset detection (auto-detect= off) it is working, so verifying as
fixed.

    
  
QA Contact: momoi → marina
Product: MailNews → Core
Product: Core → MailNews Core

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: