Closed
Bug 291294
Opened 20 years ago
Closed 20 years ago
mail command line options do not allow multi-byte characters (such as Chinese)
Categories
(SeaMonkey :: Composer, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 208363
People
(Reporter: gaurav.anywhere, Unassigned)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a4) Gecko/20040927 I'm trying to open the mozilla mail composer window directly from the command line, with full parameters, including the To, CC, BCC, Subject, Attachment, and Body fields. The problem arises when I want to send multi-byte encoded text, such as UTF-8 encoded Japanese or Chinese. I have written a sample shell script, which clearly demonstrates the problem. Note that this works correctly on Kmail 1.4.3 (and others) and Evolution 1.2 and 1.4. I tried running similar shell scripts for those other clients (with only the syntax changes, not the encoded text), and they work correctly. But mozilla shows all the encoded text as Junk and actually messes it all up. Reproducible: Always Steps to Reproduce: 1. Run the shell script given in the attachment to this bug, which invokes mozilla mail composer through the command line. 2. Run the shell script for kmail, and compare that kmail works fine, but mozilla doesn't. Actual Results: Mozilla composer window opens up, but with JUNK charactesr, instead of chinese. Kmail composer window opens up, with correct chinese characters. Expected Results: Mozilla mail window should show the chinese characters correctly. I have tried sending the input to mozilla before and after conversion from UTF8 to current locale format, but mozilla does not seem to accept any of those encodings. Also, a note on the criticality of this bug: This bug is highly critical, because it doesnt' only have to do with the "display of text", but of the actual "loss" of encoded text. Once we open the composer window with multi-byte data, that data is no more usable, because mozilla treats it like junk 8-bit bytes, and doesn't know about the encoding.
| Reporter | ||
Comment 1•20 years ago
|
||
Please execute the attached shell script, and you will see the bug getting reproduced as described in the bug report.
| Reporter | ||
Comment 2•20 years ago
|
||
This shell script tells you what's expected from mozilla too.
Comment 3•20 years ago
|
||
dupe of "mozilla -compose cannot interpret UTF-8 String correctly" *** This bug has been marked as a duplicate of 208363 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•