kde在处理非unicode时有缺陷？

我测试了kde3和kde4.
具体情况：
将全局locale设置为zh_CN.GBK，进入kde，然后用ntfs-3g挂载本地ntfs分区，发现无论是在konqueror还是dolphin中，中文文件名显示为乱码。在konsole中执行ls命令，中文文件名同样是乱码，不过将菜单栏中“语言编码”改为utf8后，可以显示一半汉字，接着执行LC_ALL=zh_CN.UTF-8 ls,就可以完全显示中文文件名。

同时还测试了gtk程序，pcmanfm,rox-filer，发现它们两个在locale=zh_CN.GBK下能正确显示ntfs分区中的中文文件名。

我也说明了：gtk程序(thunar,pcmanfm,rox)在gbk环境中也能正确处理中文。这个如何解释？kde项目不太注意国际化？gnome更注重细节？

其实对于linux而言，处理多国语言的能力是glibc所提供的。我们常说的locale就是由glibc中的一个程序生成的。只要以glibc作为基本c库的开源软件在处理多国语言的问题上已经没有技术上的障碍。

没有测试的情况下，能工作的程序也就是因为碰巧而已，很显然，国外程序员是绝对不可能测试自己程序在GBK编码下的表现的。

如果你认真测试，在gnome项目中找出编码有问题的程序也并不难。不过，不要忘记gnome2是2002年发布的，至今已经有7年时间，而kde4是2008年1月发布的，至今仅一年时间。论测试的完备程度来看， 他们不是一个层次的。

glibc确实提供了函数，但是这并不是唯一的方法，多编码集支持所涉及的环节非常多。而每个程序可能用不同的方法去实现，所以就造成了不同程序有很多不同。

至于你说“kde项目不太注重国际化”，这基本又回到本原性的问题上来了。不论是kde项目，还是gnome项目，都没办法被一个整体所代表，他们由来自世界各地的程序员贡献代码，程序自然写得千奇百怪，有些程序员不考虑utf-8之外的编码集这有什么可奇怪的呢？难道就代表了项目整体的倾向？

大项目中最能够被集中代表的恐怕只是linux，因为linus本人全职的做所有的代码审核与归并工作。其它的大多数项目并不存在linus这样的“中央集权”，他们是松散的，任何人都可以提交代码，所以并不能以个别程序的风格代表整个项目。

GTK有pango的支持，用来处理多国语言文字。