GNOME Bugzilla – Bug 223988
Some Korean messages not decoded correctly
Last modified: 2004-09-29 20:42:40 UTC
Some messages with base64 encoded Korean texts show garbled characters. I will attach a mail source which will cause this problem. This could be some decoding problem? I've found that it shows Korean characters correctly when I replace encoded contents part with another encoded text. Thanks. ================================================= Korean GNOME Community - http://gnome.or.kr
Created attachment 41173 [details] Mail source
does this render okay in any other mailer? unfortunately since I don't have my system setup to be able to read korean (not that I could even if my system *was* setup... ;-) could you attach a screenshot of what this message *should* look like and what it looks like in evolution? according to libc: "Invalid or incomplete multibyte or wide character" since we can't convert from the given charset to UTF-8, we leave it as raw text which is probably why it's appearing as corrupted. Anyways, I'm tempted to say NOTABUG since the text is clearly NOT correctly formed ks_c_whatever text. libc says so. :-)
Mozilla Mail renders contents part correctly but header is still garbled. I've found the recent version of Evolution does not encode Korean characters in mail header correctly for which I'll file another bug report. Evolution fails to render both part of the message, but I suppose it shouldn't be a major problem since the message itself is already garbled in the header.
I investigated this further, I believe the sending agent is at fault. The body of the message infact, totally rubbish. It consists of the following parts: Ç㼺¹Î ÀÔ´Ï´Ù eye@xelpa.com ----- Original Message ----- From: "Xavier Cho" <fender@infoware.co.kr> Above is all ok, it is in euc-kr format. (ks_c* is a stupid ms only name, that apparently can be changed in the registry? see http://www-2.cs.cmu.edu/afs/andrew/usr/doh/Hangul/hangul1.html) To: "채명??" <alego@infoware.co.kr>; "?„호??" <goopy@infoware.co.kr>; "?´ì?ê·?" <greentee@infoware.co.kr>; "?´ì„±?€" <olive@infoware.co.kr>; "ë¥˜ì •ê¸?" <sapeter@infoware.co.kr>; "?�ìƒ�ì§?" <sangjin21@infoware.co.kr>; "강나??" <nalover@info-plaza.co.kr>; "?©ì„¸??" <redkal@infoware.co.kr>; "ì¡°í™�준" <chj@infoware.co.kr>; "?´í•˜??" <harrison@infoware.co.kr>; "?�삼??" <ssson@infoware.co.kr>; "?�ë?ì£?" <hmj@infoware.co.kr>; "?�í�¬??" <linus@infoware.co.kr>; "채í�¬??" <chae20@infoware.co.kr>; "?„현??" <lim@infoware.co.kr>; "?¤ë³‘??" <PR@infoware.co.kr>; "?¡ì£¼??" <totorook@infoware.co.kr>; "ê¹€?€??" <i88u88@infoware.co.kr>; "ê¹€? 호" <ksh@infoware.co.kr>; "ê¹€?�겸" <longtaec@infoware.co.kr>; "?´ì£¼??" <nova@infoware.co.kr>; "?œìš©??" <jeenp@infoware.co.kr>; "?©ìš´ë°?" <hwb@infoware.co.kr>; "ê¹€?™ì˜�" <knys@infoware.co.kr>; "?°í˜•ê¶?" <paladin@infoware.co.kr>; "?ˆì„±ë¯?" <eye@infoware.co.kr>; "?„성ì§?" <chuns@infoware.co.kr>; "?´ì˜�??" <lyh@infoware.co.kr>; "ê¹€?•í›ˆ" <four@infoware.co.kr>; "ë°•ë???" <ledzpl77@infoware.co.kr> Sent: Saturday, April 27, 2002 1:42 PM Subject: ?¹ë©”??ê³„ì • ? ì²??주세?? All of these headers contain garbage. At least, they are not in utf8, and they are definetly not part of euc-kr. > ¾ÕÀ¸·Î http://mail.xelpa.com¿¡¼ À¥¸ÞÀÏ »çÀÌÆ®¸¦ ¿î¿µÇÕ´Ï´Ù. > ¸ÕÀú »ç³»¿¡¼ »ç¿ëÇغ¸°í À¥¾Øºñ¿¡µµ °èÁ¤À» ÁÙ °Å¶ó°í Çϴ±º¿ä. > > °èÁ¤Àº ¾Æ¿ô·è°ú °°Àº ÀÏ¹Ý ¸ÞÀÏ ÇÁ·Î±×·¥À¸·Îµµ ¾µ ¼ö ÀÖ½À´Ï´Ù. > > »ç¿ëÇÏ½Ç °èÁ¤°ú ºñ¹Ð¹øÈ£¸¦ ´äÀåÀ¸·Î º¸³»ÁÖ½Ã¸é °ð °èÁ¤À» > ¿¾îµå¸®°Ú½À´Ï´Ù. > > - ¸ÞÀϼ¹ö : mail.xelpa.com > - ÇüÅ : POP/IMAP > - ¸ÞÀÏ ÁÖ¼Ò : xxx@xelpa.com > > ±×·³... > All of the rest of the content is valid. So it looks like whatever replied to the message didn't know how to decode the headers and just put the rubbish in the message of the body anyway, and sent junk. Also, the content of the text in the Subject: line of the actual message is also invalid euc-kr content, so it has been improperly labelled as euc-kr by the sending agent, even though it isn't in any way valid !?. Outlook express, there's a surprise. BTW jeff, it might be worthwhile getting Ximian to purchase this for somebody, or something similar. Although I dont know how important Ximian thinks this issue is, I think its pretty important. http://www.oreilly.com/catalog/cjkvinfo/ I am going to close this bug as NOTXIMIAN. We're given a bunch of rubbish we can't deal with. Perhaps we could try to work with the 'good' data more, but i'm not sure how we could do that because iconv's interfaces are so painful in this case.
closing as above