Closed
Bug 5660
Opened 26 years ago
Closed 25 years ago
Unable to process Non-MIME 8-bit headers properly
Categories
(MailNews Core :: MIME, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M8
People
(Reporter: momoi, Assigned: nhottanscp)
References
Details
** Observed with 4/28/99 Win32 build **
For the thread pane Subject display, we are now decoding and
displaying MIME-encoded 8-bit and CJK headers. But sometimes
the Subject may contain raw 8-bit characters.
For these cases, I either see XML parser errors or
weird character substitutions (e.g. A Korean character for a
French 8-bit character.)
I understand that these are not going to be handled until M6.
This bug is filed then as a reminder to check on this type of
headers.
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M6
Assignee | ||
Comment 1•26 years ago
|
||
Accepting bug, set to M6.
Assignee | ||
Comment 2•25 years ago
|
||
Adding rhp@netscape.com to cc.
This is going be controlled by the charset menu. See the related bug 5938.
Assignee | ||
Comment 3•25 years ago
|
||
I realize that the thread pane subject view is a separate issue that I am doing
with Rich. I'll take a look and see what we should change.
Assignee | ||
Comment 4•25 years ago
|
||
This is related to the folder charset (set through charset menu UI), #3966.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M6 → M7
Assignee | ||
Comment 5•25 years ago
|
||
Moving to M7, MIME decoder needs to get mail folder charset (see #3966).
Regarding the original report, there are two parts. The thread pane display is
the one which is going to be fixed in M7. The second problem of XML parser error
is a part of #5938.
By the way, I can see Latin1 Non-MIME 8-bit headers (prorbably Latin1
converter is used as the default). But I think that's only for Latin1.
Assignee | ||
Comment 6•25 years ago
|
||
Just for my memo, I should enable the code for this bug.
Index: mailnews/mime/src/comi18n.h
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/comi18n.h,v
retrieving revision 1.11
diff -c -r1.11 comi18n.h
*** comi18n.h 1999/06/03 01:08:23 1.11
--- comi18n.h 1999/06/11 00:57:56
***************
*** 39,45 ****
*
*
* @param header [IN] A header to decode.
! * @param charset [OUT] Charset name (in C string) from a MIME header is
set.
* Caller should allocate at least 65 bytes (kMAX_CSNAME +
1) for a charset name.
* @return Decoded buffer (in C string) or return NULL if the
header is not MIME encoded.
*/
--- 39,46 ----
*
*
* @param header [IN] A header to decode.
! * @param charset [IN/OUT] Input default charset or empty string to be
used for non MIME labeled header,
! * After the decode charset name (in C string) from a MIME
header is set.
* Caller should allocate at least 65 bytes (kMAX_CSNAME +
1) for a charset name.
* @return Decoded buffer (in C string) or return NULL if the
header is not MIME encoded.
*/
Index: mailnews/mime/src/comi18n.cpp
===================================================================
RCS file: /cvsroot/mozilla/mailnews/mime/src/comi18n.cpp,v
retrieving revision 1.28
diff -c -r1.28 comi18n.cpp
*** comi18n.cpp 1999/06/03 03:12:07 1.28
--- comi18n.cpp 1999/06/11 00:57:56
***************
*** 1729,1735 ****
--- 1729,1742 ----
// No MIME encoded, duplicate the input and put us-ascii as a charset
if (*header == '\0' || !intlmime_is_mime_part2_header(header)) {
result = PL_strdup(header);
+ #if 1
PL_strcpy(charset, "us-ascii");
+ #else
+ // Put us-ascii as a charset if the default charset is not specified.
+ if (*charset == '\0') {
+ PL_strcpy(charset, "us-ascii");
+ }
+ #endif
}
else {
char *header_copy = PL_strdup(header); // avoid to modify the original
string
Assignee | ||
Updated•25 years ago
|
Target Milestone: M7 → M8
Assignee | ||
Comment 7•25 years ago
|
||
3966 got fixed last night, I updated the tree and apply my changes but the
testing failed. I think I have one more place to change (nsMimeConverter.cpp).
Regarding the fix of 3966, I saw the folder charset is passed down to MIME
decoder so I can say that it's fixed. But for this bug, I need more time to
change the code and to test. Currently, all Non MIME 8 bit headers are
interpreted as Latin1 (so we can see Latin1 Non MIME and Non MIME Japanese is
very rare).
Moving target to M8.
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 8•25 years ago
|
||
Fix checed in mime/src/comi18n.cpp rev=1.30, mime/src/nsMimeConverter.cpp
rev=1.6.
Note for verification:
Charset menu change does not cause reload thread pane (8206). To see the change,
click other folder then click back.
Because Latin1 has been working, something other charset should also be tested.
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 9•25 years ago
|
||
** Checked with 6/25/99 Win32 M8 build **
I looked at some Latin msg headers which contain 8-bit characters without MIME-encoding.
They all failed to display correctly in the message viewing window thougg they displayed OK
in the thread pane. I tried switching to some other folder and come back to the msgs I wanted to
display but this did not work, either. Maybe it's not easy to reset the folder encoding?
The error message was something like: "XML Error in file 'file://c:/temp/tempMessage.eml?header=only', Line Number: 5,
Col Number: 739, Description: mismatched tag"
I'm re-opening this bug for now ...
Reporter | ||
Updated•25 years ago
|
Resolution: FIXED → ---
Reporter | ||
Comment 10•25 years ago
|
||
Correction:
I was looking at only Latin 1 examples. That's not going to really
reveal the fix. So I tried Latin 2 non-MIME headers.
By changing the encoding to Latin 2 and higlighting another
folder and then back, I was able to display Latin 2 characters
OK which were not displayed correctly initially in the thread pane.
However, the message viewing window's subject header displays
incorrectly. Unlike the case of Latin 1 headers, I didn't get
XML parser error but still it displays incorrectly.
My initial bug report was about not being able to deal with non-MIME
8-bit headers correctly, and it implicitly referred to both thread pane and
message window problems -- note my mention of XML parser error
in such cases which you get in the message viewing window.
So, even though the thread pane display now correctly reflects
the folder charset as in this Latin 2 message, the viewing window
problem needs to be resolved.
Assignee | ||
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 11•25 years ago
|
||
Message view pane problem has been filed separately (5938 - charset override).
That bug should apply for both header and body. Can we mark this FIXED and add
comments to 5938?
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 12•25 years ago
|
||
Thanks fo reminding me of that bug.
Let me now mark the fix here verified.
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•