Closed Bug 7430 Opened 25 years ago Closed 25 years ago

Latin 1 characters under 8859-1 and UTF-8 are sent incorrectly: header & body

Categories

(MailNews Core :: Internationalization, defect, P3)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: momoi, Assigned: rickg)

References

Details

** Observed with 6/1/99 Win32 build **

We seem to have a wide-spread falures in send:

Latin 1:

  1. Header is not going out in MIME-encoded format though the
     prefs50.js setting is for strict MIME header.
  2. Body seems to lose 8-bit input and replaces them with
     with a dot.

Japanese:

  1. Here you cannot the see the input correctly because of the font
     problem mentioned in Bug 7424, but body goes out correctly in
     iso-2022-jp.

UTF-8:

  1. Header is encoded in UTF-8/B but display is wrong. The Body
     uses QP but it seems that wrong conversion might be talking
     place. See these headers and body:

--------------------------------------------------------
     Subject: UTF8: =?UTF-8?B?RnLtl5R0cmU=?=
     Content-Type: text/plain; charset=UTF-8
     Content-Transfer-Encoding: quoted-printable

     Fr=ED=97=94tre
--------------------------------------------------------

Note that the word is supposed to be "Frêtre" in the header and
body.
I'm updating the summary line based on Naoki's suggestions.

In this bug, Latin 1 accented characters are mishandled for sending mail under ISO-8859-1 or UTF-8 charset.
To update the UTF-8 condition,

UTF-8:

  1. Header is encoded in UTF-8/B but display is wrong. The Body
     uses QP but it seems that wrong conversion might be talking
     place.  This problem applies to Latin 1 accented character
     input. Japanese input seem to be handle correctly. See these headers
     and body for Latin 1 input: .....
Summary: non-Latin 1 message header/body send is broken → Latin 1 characters under 8859-1 and UTF-8 are sent incorrectly: header & body
Assignee: nhotta → rickg
Reassigning to rickg@netscape.com.
It's still happening today's build.
But my local build with a change below does not have the problem.
It is likely that the char vs unsigned char causes the problem.

void CopyChars1To2(char* aDest,PRInt32 anDestOffset,const char* aSource,PRUint32
anOffset,PRUint32 aCount) {

  PRUnichar* theDest=(PRUnichar*)aDest;
  PRUnichar* to   = theDest+anDestOffset;
  const char* first= aSource+anOffset;
  const char* last = first+aCount;

  //now loop over characters, shifting them left...
  while(first<last) {
#if 0
    *to=kIsoLatin1ToUCS2[*first];
#else
    *to=kIsoLatin1ToUCS2[(unsigned char)*first];
#endif
    to++;
    first++;
  }
}
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This bug should now be fixed because I eliminated the kIsoLatin1ToUCS2 table
lookup and did a direct 1-to-2 byte conversion.
Status: RESOLVED → REOPENED
** Checked with 6/4/99 Win32 - the 2nd build **

Unfortunately the Latin 1 high-bit characters problem
for sending mail under ISO-8859-1 and UTF-8 encopdings are
still there with this new build.

Re-opening...
Depends on: 7479
We need to get 7479 resolved to see this bug fixed. I'm marking the dependency here.
Resolution: FIXED → ---
Blocks: 7228
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
This seems to be working now.
I'll mark it resolved (due to 7479) and get it on my
plate to verify.
Status: RESOLVED → VERIFIED
** Checked with 6/11/99 Win 32 build **

I looked at both Latin1 and UTF-8 mail send with
Latin 1 high-bit range data in the header and body.
None of these headers and bodies show the problems mentioned
in the original and subsequent reports.

MIME encodings are also correctly done.
Marking the fix verified.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.