GNOME Bugzilla – Bug 244991
cannot send mail in GB-2312
Last modified: 2003-06-18 18:04:03 UTC
I could not tell if this was a duplicate of bug 224026 but, after reading said bug, it seemed different. I figured it was easier if I just filed another bug report, since marking a bug duplicate is a simple operation. Description of Problem: Outgoing email from evolution appears to always be encoded as UTF-8 Steps to reproduce the problem: 1. Run evolution, in simplified chinese locale in RH9 (I'm using miniChinput-0.0.3-37 for my XIM, but I believe that shouldn't matter) 2. using the menu, open a composer window for a new email message 3. address the mail to some other email account (say your foobar@yahoo.com account) 4. type a subject in (I used english, just in case that affected evolution's behavior) 5. Select "GB2312" as the character encoding 6. type an email body in Chinese 7. Send Actual Results: Open the email in yahoo mail, and select "GB2312" as the character encoding -- the characters are rendered incorrectly. However, if you select the "UTF-8" encoding, the characters are rendered properly. Expected Results: Vice versa -- in other words, the characters should render correctly with GB2312 selected in the browser and incorrectly with UTF-8 selected. How often does this happen? Every Time.
Currently, to work around this bug, I am not using evolution to send mail but rather yahoo mail.
this means that your typed text does not fit inside GB2312.
Jeff, let me make my step #6 more precise, as I believe the clarified version will provide a counterexample to your theory. 6. type the following email body: ÄãºÃÂð (I hope that bugzilla stores that as GB2312. I will attach the data in a file if it does not) These characters happen to all be in the GB2312 character set. Their hex values are as follows: 0xc4e3, 0xbac3, 0xc2f0 > echo -n 'ÄãºÃÂð' | od -t x1 0000000 c4 e3 ba c3 c2 f0 I can look up their GB2312 table numbers if you think that would be useful. This is actually the message body that I typed, so the rest of the bug report remains the same under this clarification.
Luckily bugzilla stored the data verbatim. If you switch your browser to GB2312 and have the correct fonts installed, you should see the characters.
aha, seems Linux libiconv does not support the charset alias GB-2312, it wants GB2312 instead and so it is failing to convert UTF-8 to GB2312, thus falling back to UTF-8
n/m, even after I fixed it to use the code that uses the appropriate charset alias, I still get: (evolution-1.4:16110): camel-WARNING **: Cannot convert from 'gb2312' to 'UTF-8': Invalid or incomplete multibyte or wide character sorry, but the text you gave me will not fit into GB2312 according to the system libiconv. I will commit my other fix tho...
wait, n/m, it works afterall. silly me.
Created attachment 42544 [details] [review] 44991.patch
patch applied to CVS