关于为何启用 GB18030 local 的说明

KDE

http://blog.sina.com.cn/u/53f570ed0100035j

qdzhuang

我坚决支持gb18030，但Linux多用在服务器,而有有大部分软件都是外国人在utf8环境开发的，而且也是在这个环境测试的，稳定系数大，有的在gb18030中没法用，在事实面前我只能选择稳定，不然有问题就再向用户赔银子,就像网络的ISO模型一样，大家都知道他是标准，但用的开发最多的是tcp/ip模型，所以tcp/ip成了工业标准。

haulm

utf-8是不利于中国信息存储、快速处理的一种编码，它要用3个字节来表示一个汉字。如果utf-8不是这个最直接的原因，我看任何的国家强制标准都不能被接受。使用哪种编码直接关系到国家、民族的利益，不仅仅是使用习惯和国际通用的问题。

woolzey

如果写程序的人不注意，就算是程序能够使用utf-8，一样可能不支持中文，比如著名的emacs。所以说utf-8并不天然的支持CJK，对中文应用来说它在这上面实在没有特别的优势，不见得就更稳定。

gb18030的优势在于兼容gb2312和gbk，缺点就是编码设计的还是有问题，不如utf-8那么完美，不过这个问题是从gbk开始就有的，也不能怪gb18030。

sejishikong

如果是服务器环境，可以使用utf-8，相对来说可能麻烦小些。不过也不一定。

hohoxu_hao115

不过若xorg或xfree86不打补丁是不支持gb18030的。

qdzhuang

不知道可不可以设置多个locale我看到好像可以用:分割

jiangtao9999

Ubicode/iso10646 越来越成为不可能完成的任务………………

现在的 GB18030 是基于 ucicode 设计，且照顾 GB2312 而设计的。因为新的 unicode 标准和旧的 GB2312 不兼容，（但似乎和 GBK 兼容，但 GBK 已经明显不够用，新版本的却因为 unicode 难产而一再推迟）所以不得不出现 GB18030。

cjacker

红旗将启用utf8的支持，考虑如下：

1，gb18030是强制国家标准，是必须支持的，但是，没有任何强制标准要求必须是gb18030 default的。
2，UTF-8将成为国际Linux的默认Locale，为了减少跟其他Linux操作系统之间的conflict，默认采用utf8还是必要的。
3，编码信息导致乱码的问题仅仅会发生在纯文本中，而且，这种纯文本仅仅限于gb编码文本在Linux下打开。 utf8的纯文本在Windows下并不存在问题。其他如电子邮件、html、Office文档本身就是带格式或带编码表述的文件，并不存在兼容问题。
4，采用utf8交互仅影响存储在linux文件系统的中文文件名，不会影响FAT和NTFS，本地文件系统文件可以通过convmv等简单的工具解决。
5，采用utf8并不会影响samba等基于协议的数据交换。
6，utf8的Locale可以回避社区官方代码很多的bug，比如kio_trash文件名支持问题以及各种程序中的文本显示和处理问题，官方社区会考虑utf8支持并不会考虑GBlocale支持。所以，采用utf8 locale可以减少打补丁的需要。
7，默认采用Utf8可以增强对多语言的支持。

haulm

这样一来，编程也相对简单的多了。

woolzey

我倒是不认为UTF-8有这么妙的功效，采用UTF-8还是GB并不会影响bug的数量和质量，认为采用utf-8可以减少bug的观点可能站不住脚。而且官方社区并不关心这个bug出在utf-8下还是gb下，它如果不重视中文用户的需要，对utf-8下中文环境的bug一样修正的很缓慢。

比如从gnome升级到2.10以后，在UTF-8的locale下，emacs中无法激活中文输入法；而在GBK下是可以的。这个问题好像到现在都没解决。

sejishikong

[quote:fd6bbae356="cjacker"]红旗将启用utf8的支持，考虑如下：

1，gb18030是强制国家标准，是必须支持的，但是，没有任何强制标准要求必须是gb18030 default的。
2，UTF-8将成为国际Linux的默认Locale，为了减少跟其他Linux操作系统之间的conflict，默认采用utf8还是必要的。
3，编码信息导致乱码的问题仅仅会发生在纯文本中，而且，这种纯文本仅仅限于gb编码文本在Linux下打开。 utf8的纯文本在Windows下并不存在问题。其他如电子邮件、html、Office文档本身就是带格式或带编码表述的文件，并不存在兼容问题。
4，采用utf8交互仅影响存储在linux文件系统的中文文件名，不会影响FAT和NTFS，本地文件系统文件可以通过convmv等简单的工具解决。
5，采用utf8并不会影响samba等基于协议的数据交换。
6，utf8的Locale可以回避社区官方代码很多的bug，比如kio_trash文件名支持问题以及各种程序中的文本显示和处理问题，官方社区会考虑utf8支持并不会考虑GBlocale支持。所以，采用utf8 locale可以减少打补丁的需要。
7，默认采用Utf8可以增强对多语言的支持。[/quote]

关键的就在第一条，如果能在utf-8下实现对gb18030的完全支持，当然最好，不过好像不太可能。那如果用utf-8做default，能保证在gb18030下软件都正常么？gb18030虽然不需要default，可是是必须支持的啊。ml还好，反正社区发行，不支持也无所谓，rf如果不支持，就不能往外卖了啊。

haulm

这里的default与否，只要支持GB18030似乎还是有钻空子之嫌，如果发行刊物不支持GB18030就不允许投入市场，如果不是default支持GB18030，那么消费者会直接认为不支持GB18030，麻烦比收益更多。

qdzhuang

我觉得现阶段linux的主要还在服务器的稳定方面下功夫，只要稳定能用，管他18030还是utf8我只在乎实际的应用情况，再华而不实不能解决实际问题要linux也没用，只能成摆设，用户只关心你的linux能不能解决我的实际应用，而不会去管是gb18030还是utf8的无聊问题。稳定，易用，兼容必须是linux的解决的实际问题

cjacker

[quote:8ca694abc8="woolzey"]我倒是不认为UTF-8有这么妙的功效，采用UTF-8还是GB并不会影响bug的数量和质量，认为采用utf-8可以减少bug的观点可能站不住脚。而且官方社区并不关心这个bug出在utf-8下还是gb下，它如果不重视中文用户的需要，对utf-8下中文环境的bug一样修正的很缓慢。

比如从gnome升级到2.10以后，在UTF-8的locale下，emacs中无法激活中文输入法；而在GBK下是可以的。这个问题好像到现在都没解决。[/quote]

如果你仔细看看KDE的所谓中文支持的BUG就知道这个问题是多重要了。

而且，这里有些BUG是没有办法通过正确的方式修改的，比如kmail邮件标题列表中的多语言乱码问题。