兼容大多数用户的文件才可以.所以我赞成KDE的意见.
背景知识
这篇文章
http://www.linuxforum.net/doc/i18n-new.html
觉得还不错，虽然有些过时了。
我感觉公社的人尽量些学生，而像我的社会青年不多
我就是学生。 社会青年有何高见？
其实我的观点和你大致接近，少部分看法有些不同而已。UTF-8确实是一个很优秀的编码方案，对有经验的用户来说是个很好的选择。
我只是不能同意把gb 18030妖魔化。虽然它因为历史遗留问题，设计的很拙劣，但是仍然是一种Unicode的编码方案。这点上和UTF-8没有本质区别，甚至国外有人称其为UTF-GB。所以论及字符集的覆盖、多语言支持这些方面，说UTF-8有优势可能不太正确。
至于说UTF-8比gb 18030大，这点我之前也是非常同意。不过昨天读utf-8的定义，突然发现各个标准已经悄然的把UTF-8限制在4字节了。比如RFC 3629和The Unicode Standard, Version 4.0(第3.9节)。Linux现在的libiconv还采用老的RFC 2279，所以支持6字节，不知道以后会怎么发展。所以现在谁大谁小就仍然可以争论了，呵呵。虽然UTF-8可以扩充到6个字节，不过我相信如果有这一天，到时候头疼的不止是gb 18030。因为UTF-16也只能编码到U+10FFFF，而这个是目前各大软件商常用的内部表示方法，包括微软。
亲爱的同志们：
为了这个问题，大家非斗个你死我活不行？
我来总结一下：
1，Magic要用GB18030，我不反对。
2，红旗可能要用UTF8，我也不反对。
3，我反对GB18030需要更少的patch，因为事实证明Utf8需要更少的patch。
4，用Utf8并没有大家想象的那么多的数据交换问题，只不过可以节省很多作dirty patch的时间。出现问题的可能是纯文本文件和包封装内部的文件名，比如压缩包以及无编码描述的协议。
5，用Utf8不代表不能使用gb18030了。
6，GB18030和Utf8都不能解决全部的中文字，至少是现在。
7，Utf8比GB18030多，这个也不用争论。
8，用Utf8一个很好的地方是可以同时支持多语言。
9，Utf8并不是仅仅为西文而设计的。
10，Utf8或者说Unicode现在存在一些中文问题并不是说Unicode本身有什么缺陷，而是由于我们国人不努力造成的。
11，你在任何时间都可以将你的系统修改成gb的locale
大家都休息休息吧，不要让我们把坛子的气氛搞坏了。
背景知识
这篇文章
http://www.linuxforum.net/doc/i18n-new.html
觉得还不错，虽然有些过时了。
多谢多谢！
回 jiangtao9999 说的
纯文本：
Windows 的记事本支持 UTF-8 编码
Linux 下 kate 、 kwrite 支持指定编码
gedit 、 gvim 之类会自动判断编码
文档：
没有编码问题
Linux 分区文件名：
KDE 下的 konq-toutf8 会给 konqueror 加上右键菜单判断和修改文件名
Windows 分区文件名：
挂载参数里改 gbk 为 utf8
回 woolzey：
看看 unicode4.1
跑下题，
woolzey， 你觉得 Qt 内部用UTF-16 ，以后会怎么办
在Unicode的一个文档（http://www.unicode.org/notes/tn12/）里可以看到，很多软件内部都使用了UTF-16。除了KDE/Qt以外，还包括微软的所有产品，Mac OS X，还有Java，.NET，Python。
我不知道这个列表的准确性如何，不过如果属实，那么UTF-16的未来就不用我们操心了，那些大软件公司会想办法保证延续性的。
事实上，以前ISO 10646的编码范围是31比特，后来由于软件公司需要延续Unicode 1.0，现在才限制到了U+10FFFF。
就我个人看，UTF-16和GB 18030都能支持到U+10FFFF，可预见的将来是够用的了。估计Unicode出到版本10也不会超出这个范围。
跑下题，
woolzey， 你觉得 Qt 内部用UTF-16 ，以后会怎么办
这里我可以反问你一个问题：你在gb环境下又是怎么读utf8纯文本的？
我根本就没有 utf8 编码的文本文件。
因为像我这种普通用户，根本就不需要用 utf8 。
我只要保证我机器里所有编码都是 GB ，而且别人要求的也都是 GB 编码（比如税务局，民政局，别人的机器）。
我可以不可以认为：RF 默认 utf8 ，之后根据需要默认打开某些软件的 gb -> utf8 编码功能？
但这样如果我安装一个原版的、基于 locale 识别的软件会有什么结果？
不是我不看前面的帖子，是前面的帖子影响了我的问题。（公社跑题严重是众所周知的）
我在开始就是在质疑 RF 使用 utf8 会导致 utf8 和 GB 混乱，因为毕竟在中国 GB18030 还是常用的。
PS：kuye 也不能理解我的意思。
你的机器上肯定是要有utf8文件的，比如各种Desktop文件。
我的机器上很少存在gb的纯文本文件，大部分是带格式的data format，有一些文本文件的临时笔记也是英文的，当然不排除存在gb文件的可能。
现在的问题是，随着Linux版本使用utf8locale的越来越多，你在跟Linux系统交互的时候会遇到越来越多的问题。
比如，如果一个ftp用fedora建站，最后这个ftp上的文件很可能都是utf8的文件名。
所以，你现在没有办法要求其他人的机器是什么样的locale，因此我们要寻找一个正确的解决问题的方式。
如果你是gb，你要承受一些无法修正的问题。
如果你是utf8，那么你仍然可能遇到乱码，但是这些问题都是可以通过正确的方式修复的。
普通用户用纯文本传递信息的时候已经越来越少，基本上你能收到的全部是带格式的data format。
至于需要特定locale的软件，到目前为止，很少。
如果有，那么这个软件应该是要自行进行判断的，如果在软件设计的时候少了这一步，那么这个软件的设计是有缺陷的。
比如很多Oracle Forms，我遇到的情况是，在Linux下进行开发时，如果需要特定locale，那么，一般情况这个程序都会提供一个脚本作wrapper.
因为他实在不能保证你的系统到底是什么locale。
同时，我们也应该想到，基于RedHat开发的软件实在太多了。
其实我的观点和你大致接近，少部分看法有些不同而已。UTF-8确实是一个很优秀的编码方案，对有经验的用户来说是个很好的选择。
我只是不能同意把gb 18030妖魔化。虽然它因为历史遗留问题，设计的很拙劣，但是仍然是一种Unicode的编码方案。这点上和UTF-8没有本质区别，甚至国外有人称其为UTF-GB。所以论及字符集的覆盖、多语言支持这些方面，说UTF-8有优势可能不太正确。
至于说UTF-8比gb 18030大，这点我之前也是非常同意。不过昨天读utf-8的定义，突然发现各个标准已经悄然的把UTF-8限制在4字节了。比如RFC 3629和The Unicode Standard, Version 4.0(第3.9节)。Linux现在的libiconv还采用老的RFC 2279，所以支持6字节，不知道以后会怎么发展。所以现在谁大谁小就仍然可以争论了，呵呵。虽然UTF-8可以扩充到6个字节，不过我相信如果有这一天，到时候头疼的不止是gb 18030。因为UTF-16也只能编码到U+10FFFF，而这个是目前各大软件商常用的内部表示方法，包括微软。
亲爱的同志们：
为了这个问题，大家非斗个你死我活不行？
我来总结一下：
1，Magic要用GB18030，我不反对。
2，红旗可能要用UTF8，我也不反对。
3，我反对GB18030需要更少的patch，因为事实证明Utf8需要更少的patch。
4，用Utf8并没有大家想象的那么多的数据交换问题，只不过可以节省很多作dirty patch的时间。出现问题的可能是纯文本文件和包封装内部的文件名，比如压缩包以及无编码描述的协议。
5，用Utf8不代表不能使用gb18030了。
6，GB18030和Utf8都不能解决全部的中文字，至少是现在。
7，Utf8比GB18030多，这个也不用争论。
8，用Utf8一个很好的地方是可以同时支持多语言。
9，Utf8并不是仅仅为西文而设计的。
10，Utf8或者说Unicode现在存在一些中文问题并不是说Unicode本身有什么缺陷，而是由于我们国人不努力造成的。
11，你在任何时间都可以将你的系统修改成gb的locale
大家都休息休息吧，不要让我们把坛子的气氛搞坏了。
utf8一定是要比gb18030大的，你都不需要用文档来解决问题:-D
如果gb18030比utf8大或者相等。
将一个日文文件转成utf8，那么这个结果一定能转成gb18030.
将一个汉文文件转成utf8，那么这个结果也一定能转成gb18030。
将一个繁体文件转成utf8，那么这个结果同样应该能转成gb18030。
那gb18030岂不成了万能编码了。
你说的这3个论断都成立。你为什么认为不能呢？
gb18030和utf-8一样，确实都是“万能编码”。
utf8一定是要比gb18030大的，你都不需要用文档来解决问题:-D
如果gb18030比utf8大或者相等。
将一个日文文件转成utf8，那么这个结果一定能转成gb18030.
将一个汉文文件转成utf8，那么这个结果也一定能转成gb18030。
将一个繁体文件转成utf8，那么这个结果同样应该能转成gb18030。
那gb18030岂不成了万能编码了。
你说的这3个论断都成立。你为什么认为不能呢？
gb18030和utf-8一样，确实都是“万能编码”。
utf8一定是要比gb18030大的，你都不需要用文档来解决问题:-D
如果gb18030比utf8大或者相等。
将一个日文文件转成utf8，那么这个结果一定能转成gb18030.
将一个汉文文件转成utf8，那么这个结果也一定能转成gb18030。
将一个繁体文件转成utf8，那么这个结果同样应该能转成gb18030。
那gb18030岂不成了万能编码了。
再回去好好试，不要在gb locale下仅仅写几个平假名，片假名就行了。
你给我个utf-8的测试文件，我试试看。
或者你给一个unicode码，我去查查看gb 18030里面有没有。
再回去好好试，不要在gb locale下仅仅写几个平假名，片假名就行了。
你给我个utf-8的测试文件，我试试看。
或者你给一个unicode码，我去查查看gb 18030里面有没有。
再回去好好试，不要在gb locale下仅仅写几个平假名，片假名就行了。
你去yahoo.co.jp拷贝一堆日文，然后把他转换成gb18030看看。
在简单不过的道理了，如果如你所言，iconv -f anything -t gb18030都是可以的。
我随便挑了一个页面
http://streaming.yahoo.co.jp/p/y/mic/10024/
从里面复制出来，用gedit保存成utf-8，然后用iconv转没有问题。
因为yahoo并不是utf-8编码的，所以我担心复制过程中的损失，又测试了
http://ja.wikipedia.org
这个是utf-8的网页。直接用mozilla保存成文本文件，然后用iconv转，也没问题。
这些网页可能不够生僻，所以有测试专用的utf-8文件最好了。
你给我个utf-8的测试文件，我试试看。
或者你给一个unicode码，我去查查看gb 18030里面有没有。
再回去好好试，不要在gb locale下仅仅写几个平假名，片假名就行了。
你去yahoo.co.jp拷贝一堆日文，然后把他转换成gb18030看看。
在简单不过的道理了，如果如你所言，iconv -f anything -t gb18030都是可以的。