After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 446783 - gb18030 encoding should be used to override gb2312 & gbk encoding
gb18030 encoding should be used to override gb2312 & gbk encoding
Status: RESOLVED DUPLICATE of bug 666896
Product: evolution
Classification: Applications
Component: general
2.10.x (obsolete)
Other All
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2007-06-12 16:06 UTC by rockallite.wulf
Modified: 2012-01-03 16:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.17/2.18



Description rockallite.wulf 2007-06-12 16:06:32 UTC
gb18030 encoding should be used to override gb2312 & gbk encoding

This is used to handle some non-standard emails, which contain extra set of characters in gb18030 encoding but are tagged with gb2312 or gbk encoding (email written in Chinese from Gmail, for example). gb18030 is a super set of gbk & gb2312, so it's safe to used it instead of the latter two.


Distribution: Ubuntu 7.04 (feisty)
Gnome Release: 2.18.1 2007-04-10 (Ubuntu)
BugBuddy Version: 2.18.1
Comment 1 André Klapper 2007-06-12 19:31:42 UTC
is this about the composer or the viewer?
Comment 2 rockallite.wulf 2007-06-13 14:58:08 UTC
(In reply to comment #1)
> is this about the composer or the viewer?
> 

It's about the viewer. Mozilla Thunderbird has provided this compatibility enhancement feature in order to display emails in Simplified Chinese properly.

BTW, the relationship between gb18030, gbk and gb2312 is:

gb18030 --(superset_of)--> gbk --(superset_of)--> gb2312
Comment 3 steven.mccoy 2007-11-01 06:49:14 UTC
Reasonable logic combined with your encoding relationship proves this case to be bogus.  With email the envelope heading indicates the encoding of the content, and RFC1522 determines the header encodings.  This means the bug is on the client side, either Gmail, the clients browser or operating system.

Gmail use what the browser tells it unless explicitly set to Unicode:

http://mail.google.com/support/bin/answer.py?answer=22841

That means either Gmail is incorrectly forwards the encoding or the browser is indicating the wrong encoding.

The browser (MSIE) picks up the encoding from the operating system (Windows).  Windows is generally Unicode friendly (UTF-16) with older applications using a specified character set.

This means either MSIE is guessing the wrong encoding or the operating system is telling the browser the wrong encoding or locale setting.

I would suggest as a workaround to explicitly set the encoding in the Gmail interface to Unicode (UTF-8)
Comment 4 steven.mccoy 2007-11-01 07:28:32 UTC
Windows 95, 98, Me, Windows NT4 and Internet Explorer 5.x do not support GB18030.  Windows 2000 and XP sold outside of PRC require an addon:

http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx

Therefore it might be considered foolish to stamp everything GB18030 even though support is "officially mandated" in the PRC, as many users have older machines running copies of these older platforms.
Comment 5 steven.mccoy 2007-11-01 08:45:47 UTC
Gmail understands GB18030 going in, replies are in BIG5 with default encoding, and UTF-8 with unicode configured.
Comment 6 rockallite.wulf 2007-11-12 12:37:15 UTC
(In reply to comment #4)
> Windows 95, 98, Me, Windows NT4 and Internet Explorer 5.x do not support
> GB18030.  Windows 2000 and XP sold outside of PRC require an addon:
> 
> http://www.microsoft.com/globaldev/DrIntl/columns/015/default.mspx
> 
> Therefore it might be considered foolish to stamp everything GB18030 even
> though support is "officially mandated" in the PRC, as many users have older
> machines running copies of these older platforms.
> 

It's nothing political. It's all about usability. As long as my emails are displayed properly in other clients like Thunderbird, while Evolution occasionally shows unreadable characters, I will not recommend other people to use it.

On the other hand, I don't know why Evolution developers should throw their energies into ancient OSes like Win95/98/ME/NT4. There are plenty of better (and free-of-charge) email clients on Windows which handle CJK characters properly. And don't misunderstand me, I don't say that they support GB18030. The GBK encoding, which is originally developed by Microsoft, plays very well in most cases.

Development of Evolution should focus on GNU/Linux and similar platforms, which have great encoding support, including GB18030. What I suggested is that emails which is tagged as GB2312 or GBK encoding should be encoded in GB18030 in Evolution if possible, so that no crappy characters will be shown. For ancient platforms like Win95/98/ME/NT4, it should fall back to GBK encoding instead. The point is, never use the obsolete GB2312 to encode anything, even if it says so. (Emails in Chinese fetched from Gmail, like I said.) Lack of GB18030 support in ancient OSes which Microsoft has thrown away years ago is not a reason.

I'm sorry to see that situation remains the same in Evolution released with Ubuntu Gutsy. I wish I could have made a patch for this, however I'm lack of ability of C programming. So I can only make suggestions.
Comment 7 André Klapper 2012-01-03 16:15:03 UTC
Marking as duplicate of bug 666896 as there is a patch.

*** This bug has been marked as a duplicate of bug 666896 ***