kde在处理非unicode时有缺陷？

pxbfeiniao

我测试了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分区中的中文文件名。

poet

大多数缺陷的解决，来源于测试。

大多数KDE开发者／测试者不是中国人，他们不可能在非unicode模式下进行测试。为了全世界的程序员能够交流，因此所有开源软件的注释均为英语，为了全世界都能够用，所以所有开源软件都会把utf-8编码支持搞好。utf-8几乎是国际性的开源软件协作开发的一种基础。脱离了这个基础，开源软件的开发无法进行。

这就是虽然各个国家对自己的语言编码进行了限定，但Linux世界却仍然是utf-8一统天下的原因。

而这个原因注定了，当你使用非unicode编码时将面临许多的问题，对这些问题你只能是有心无力。你一个人能够跟全世界的开源软件开发团队匹敌么？如果绝大多数开源软件都不考虑GBK的locale，你怎么可能安心的用好这个locale呢？你自己一人能解决成百上千个软件中的问题么？

pxbfeiniao

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

pxbfeiniao

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

poet

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

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

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

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

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

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

jarryson

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