红旗将启用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可以增强对多语言的支持。
关键的就在第一条，如果能在utf-8下实现对gb18030的完全支持，当然最好，不过好像不太可能。那如果用utf-8做default，能保证在gb18030下软件都正常么？gb18030虽然不需要default，可是是必须支持的啊。ml还好，反正社区发行，不支持也无所谓，rf如果不支持，就不能往外卖了啊。
gb18030当然是要支持的，这是原则，但是没有规定gb18030是default。
windows不是买的挺好吗？
这里的default与否，只要支持GB18030似乎还是有钻空子之嫌，如果发行刊物不支持GB18030就不允许投入市场，如果不是default支持GB18030，那么消费者会直接认为不支持GB18030，麻烦比收益更多。
错，谁能告诉我Windows中文版所谓的default的locale是什么？
支持不支持是实现上的问题，根本跟程序无关。
你一样可以在utf8locale下将某些特定的程序设定为默认locale为gb18030。
Locale并不是唯一的，也不是不可变的，甚至是可以多个locale同时使用的，所以自然也就没有了是不是必须default的概念。
这一点，还是要跟gb18030专家组的同志们多讨论讨论才能清楚。
忘了说了，测试是否支持gb18030是有一套test suite的，只要能够通过就算OK了。
windows对gb18030的支持不错的。如果能实现类似windows的效果，那样最好了。
不过我不知道在utf-8的locale下能实现对gb18030的支持吧，还是说需要换locale才能实现gb18030的支持，我希望是前者，这样会少很多麻烦。
对了，cjacker知道gb18030-2005又加了什么东西么？
有些问题即使用utf-8回避了，一样会引入新的问题。所以我说，整体看，采用什么locale不会太影响bug的数量。
当然我对KDE没有发言权，可能对KDE用户utf-8可以有效的改善中文环境也说不定。但是对其他类型的用户，utf-8可能不是一个好的选择，比如我这种emacs/TeX用户。
我倒是不认为UTF-8有这么妙的功效，采用UTF-8还是GB并不会影响bug的数量和质量，认为采用utf-8可以减少bug的观点可能站不住脚。而且官方社区并不关心这个bug出在utf-8下还是gb下，它如果不重视中文用户的需要，对utf-8下中文环境的bug一样修正的很缓慢。
比如从gnome升级到2.10以后，在UTF-8的locale下，emacs中无法激活中文输入法；而在GBK下是可以的。这个问题好像到现在都没解决。
如果你仔细看看KDE的所谓中文支持的BUG就知道这个问题是多重要了。
而且，这里有些BUG是没有办法通过正确的方式修改的，比如kmail邮件标题列表中的多语言乱码问题。
又及：如果使用多个locale，会对现有的情况有改善么？
用English，没有几个开发的不会english吧
如果 default 是 utf8 ，那么很多软件都需要 patch 。这对于社区版本来说工作量比 default 为 GB18030 更大。
因为系统内部都是以 utf8 进行处理，所有的软件在读取、写入时进行本地 <-> utf8 的转换。
因为 Linux 天生设计不合理，这个转换工作需要从应用程序自己解决。
但如果 locale 是 utf8 ，那么应用软件就 utf8<->utf8 ，类似不转换。但实际系统读取的许多字串编码都是 GB18030 ，这就是导致国外发行版在 utf8 的时候 Win 中文版里所建立的文件全都 ????? 的原因。
而在 Windows 里，这个工作是交给系统底层的。应用程序基本不用管。
至于大家真的想看 Windows 编码混乱的样子，装一套中文版的 Win ，和一套 英文版的 win ，这样他们对 FAT 分区的编码处理就会出现混乱。
winrar 汉化版也会出现文字显示混乱。
真正能解决 locale 的问题，并不是靠统一 utf8 能解决的。
真正的办法是所有读写，都靠同一个库处理，由他自动识别编码＆转换，应用程序做到和编码无关。
企图用 utf8 来解决中文编码的问题，倒不如建议政府废除中文来的干脆。
精辟
如果 default 是 utf8 ，那么很多软件都需要 patch 。这对于社区版本来说工作量比 default 为 GB18030 更大。
因为系统内部都是以 utf8 进行处理，所有的软件在读取、写入时进行本地 <-> utf8 的转换。
因为 Linux 天生设计不合理，这个转换工作需要从应用程序自己解决。
但如果 locale 是 utf8 ，那么应用软件就 utf8<->utf8 ，类似不转换。但实际系统读取的许多字串编码都是 GB18030 ，这就是导致国外发行版在 utf8 的时候 Win 中文版里所建立的文件全都 ????? 的原因。
而在 Windows 里，这个工作是交给系统底层的。应用程序基本不用管。
至于大家真的想看 Windows 编码混乱的样子，装一套中文版的 Win ，和一套 英文版的 win ，这样他们对 FAT 分区的编码处理就会出现混乱。
winrar 汉化版也会出现文字显示混乱。
真正能解决 locale 的问题，并不是靠统一 utf8 能解决的。
真正的办法是所有读写，都靠同一个库处理，由他自动识别编码＆转换，应用程序做到和编码无关。
企图用 utf8 来解决中文编码的问题，倒不如建议政府废除中文来的干脆。
要实际作了才知道。
用了utf8当然是大大减少了Patch量，甚至基本不需要patch，因为内外都是utf8。
上面对文本文档和带格式带编码文档已经做过描述了。
至于你提到的Windows分区问题，我可以告诉你没有任何问题，根本就不会出现?????的问题。
另外对于基于带编码描述的协议的数据传递也不存在类似问题。
一个例外是ftp，他是没有编码描述的。
另一个是nntp，不过协议明确规定，新闻组名必须是latin1或者utf8，任何其他字符都是非法的。
我只需要提几个小小的问题，大家可以尝试在GBlocale下去fix。
1，多语言文本混排问题，最简单的表现就是kmail的邮件标题列表。有没有人能够用正确的方法去fix?
2，kio_trash中文文件名支持问题，这个问题有没有人能够去用正确的方法fix?
if LANG = zh_CN.xxxx
xxxxxxxx
else
xxxxxxxx
这样的方法不叫正确的方法。
理解这个问题，必须清楚的理解各编码之间的关系，目前Linux下存在那些中文支持问题，以及采用不同的方案会导致什么样的结果。而不是仅仅凭猜测。
utf8是不需要任何patch的，除非他的程序写错了才需要patch。
如果是gb18030，那么即使他的程序是正确的，也有很多需要patch的地方。
所以，不要凭猜测来作结论。
当然，这个是自由了，愿意用就用，但是，你确实需要背负更多的ugly hack的patch.
不管是使用UTF-8还是使用GB18030，都不是在解决解决问题，而是在逃避问题。
真正的彻底解决，是尽快把编码自动检测的函数库完善。
不管是使用UTF-8还是使用GB18030，都不是在解决解决问题，而是在逃避问题。
真正的彻底解决，是尽快把编码自动检测的函数库完善。
mission impossible.
越长的文本正确率越高。
越短的文本正确率越低。
永远没有100%的正确。
此外即使你判断正确了又如何？
所有的文本都转换成什么？不是一样是Unicode。
又怎么解决GB locale下的多语言混排问题。
当然，大部分人都不会同时使用多语言，但是总不至于把Japanese的信件标题显示成乱马吧。大家会不会读是一回事，能不能忠实的显示原有内容是另外一回事。
精辟
精辟
wo kao, qu si:D