fcitx4.0最新版
我在GB18030、GBK、UTF-8不同的locale下的登录，比较了文件名乱码问题（文件内容没问题，如原来utf-8编码的openoffice文件不受影响）
在GB18030 locale下，windows下的文件（GB2312编码）（包括下载的）在“文件管理器”内当然能够识别文件名，但是在控制台下：乱码，还是只能显示utf-8编码。QFTP软件远程GBK文件正常显示了，本地utf-8文件乱码，GBK字符正常，audacious也是这样。还是BMP比较好，什么编码都能显示正常。
然而，在gftp中远程站点仍然乱码，看来这软件比较顽固，只支持utf-8。
在UTF-8 locale下就不用说了，刚好相反，肯定是utf-8的能显示，所有GBK编码的乱码，网络上GBK编码的文件下载过来名字就花了。
GBK当然与GB18030差不多。
鱼与熊掌如何兼得啊。在编码问题上，要是ubuntu能象xp一样就好了。
好像还有一个问题，utf-8 locale时，系统速度快一些，但是GB18030 locale时速度就慢了，影响明显，是不是locale造成的，有待进一步考证。
我感觉，GB18030登录，只是支持显示，什么意思呢？即使GB18030编码的文字能正常显示，但是如果你建立新文件用输入命名时，依然是UTF-8编码，这是致命的。也就是说，能显示GB18030的环境，却不能创建一个完全GB18030的世界，。
最后由 quantumfang 编辑于 2006-12-20 9:18，总共编辑了 1 次
作者: quantumfang 发布时间: 2006-12-14
作者: leec0621 发布时间: 2006-12-14
作者: SCerZZ 发布时间: 2006-12-26
作者: hyfx 发布时间: 2007-11-07
作者: eexpress 发布时间: 2007-11-07
作者: wizardyhnr 发布时间: 2007-11-14
实际中没有什么感觉
作者: zhlk1001 发布时间: 2007-11-17
作者: huhu2k 发布时间: 2007-11-22
作者: ljj_jjl2008 发布时间: 2007-11-22
问题不是这么简单的，
GB18030是国家强制标准，向下兼容gbk ，gb2312，收录了所有Unicode3.1中的字符，包括中国少数民族字符，韩文，日文，繁体，偏旁部首等等，也可以说是世界大多民族的文字符号都被收录在内。GB18030编码是变长编码，有单字节、双字节和四字节三种方式，共计1611668个码位，远远超过Unicode 17个平面的1114112个码位，编码空间巨大。GB 18030-2005收录了70244个汉字——不论是从现在状态对比，还是将来发展来看，其对象形文字的支持都明显会比utf-8好。
而且，很多较早的机器、软件都是gb2312 gbk的，这些日常最常见的是很久以前编辑的文档，但这些都还是小的，更重要的、并且可能产生大问题的存在是科学、军工等特殊领域。
当然，普通使用没必要那么多字，使用utf-8，gbk甚至gb2312就够了。
对我个人来说，我一般两个全开，同时还开繁体的utf-8和big5
作者: jobinson99 发布时间: 2009-05-06
问题不是这么简单的，
GB18030是国家强制标准，向下兼容gbk ，gb2312，收录了所有Unicode3.1中的字符，包括中国少数民族字符，韩文，日文，繁体，偏旁部首等等，也可以说是世界大多民族的文字符号都被收录在内。GB18030编码是变长编码，有单字节、双字节和四字节三种方式，共计1611668个码位，远远超过Unicode 17个平面的1114112个码位，编码空间巨大。GB 18030-2005收录了70244个汉字——不论是从现在状态对比，还是将来发展来看，其对象形文字的支持都明显会比utf-8好。
而且，很多较早的机器、软件都是gb2312 gbk的，这些日常最常见的是很久以前编辑的文档，但这些都还是小的，更重要的、并且可能产生大问题的存在是科学、军工等特殊领域。
当然，普通使用没必要那么多字，使用utf-8，gbk甚至gb2312就够了。
对我个人来说，我一般两个全开，同时还开繁体的utf-8和big5
作者: huhu2k 发布时间: 2010-08-27
作者: cece 发布时间: 2010-08-27