奇怪的现象：GNOME下文件名正常，KDE下乱码

voodoomaster

fc3的系统，gnome用的自带的2.8版本，kde是自己下源码编的，版本号3.5.4。使用中 gnome和kde其他地方中文显示、输入都很正常，但是硬盘上某个fat32分区，有几个文件名里含有日文的mp3音乐文件(文件名编码不详，但是应该只可能是utf8、cp936中文gbk、cp932日文这三种之一，id3标签是v1还是v2，编码如何也不清楚)，对这几个文件，无论是

a) LC_CTYPE设定成zh_CN.UTF-8，相应的LC_ALL=en_US.UTF-8，mount时用参数iocharset=utf8

还是

b) LC_CTYPE设定成zh_CN.GBK，此时LC_ALL=en_US，mount参数用的是iocharset=cp936

在a、b两种情况下，gnome都能正常显示文件名，而kde就是有几个字符乱码，具体表现为方块。而LC_CTYPE=zh_CN.GBK时，xmms也可以正常显示文件的id3标签，UTF-8时也乱码。

字体用的是simsun，已经成功安装好，可以正常显示。另外G_BROKEN_FILENAMES=1的环境变量一直设定为有效。

非常有趣的现象是，当LC_CTYPE=zh_CN.GBK时，在kde环境下启动xmms，虽然konqueror和任务栏上面文件名是乱码，但是在xmms的播放列表和打开文件对话框内，文件名却能正常显示。也就是说凡是基于gtk的程序都能正常显示文件名，但是基于qt的程序却不能。

xmms在utf8下的乱码问题暂时不管，因为已经放弃utf8了。现在想求教如何在LC_CTYPE=zh_CN.GBK时让kde正常显示文件名。

voodoomaster

顺带说一下，qt版本是3.3.6，自己下源码编译的。花了一个多小时........这是我编译过的软件中耗时最长的了。我机子还将就，编译一个内核就15－20分钟，kdelibs也只要40分钟左右，没编译过mozilla、openoffice这些BT级的软件。

wildfire

qt 3.3.6 有 bug，还是用 3.3.5 试试吧。

voodoomaster

Post by wildfire
qt 3.3.6 有 bug，还是用 3.3.5 试试吧。

楼上的确认？编译一个qt可不是一般的慢啊....

voodoomaster

还想问个问题，今天我又发现ark打开内有中文文件名的7z压缩包时，里面又是乱码，解压出来也跟着乱码，在gnome下无此问题。有可能是我用的gbk的locale，但是那个中文是utf8的。这个和上面的问题是不是都可以尝试用qt3.3.5解决一下？

老是感觉如果同一个目录下面，如果同时有utf8和gbk的文件名，那么gnome无论locale设成utf8还是gbk，都能正常显示，而且在copy时还可以自动把编码转换成当前的locale，同理windows也可以，而kde就不行。明天试试编译一个qt3.3.5，看看能解决不。

fallen

因为gtk有pango的支持,
kde没有...

hooey

别用 bitstream+替换字体的方法，直接选个有日文字符的中文字体，simsun 之类的都可以的吧

voodoomaster

xlsfonts |grep simsun  和 fc-list |grep SimSun 都显示正常，simsun是出现在了字体列表中的。这个总能说明我的字体安装是没问题的吧。另外我也说了，在kde环境下，用xmms时是能够完美现实文件名和id3的，如果字体设置有问题，怎么能完美显示？

另外楼上说的bitstream+替换字体的方法什么？小弟实在不明白。以前用过一段时间文泉驿的点阵字体，但是它只有utf8的，现在要用gbk，只好换回simsun来了。好像是改过fonts.conf文件，但是既然xmms和gnome显示都正常，那就说明字体设置是没有问题的了吧？

PS:想起来了，在~/.fonts.conf里面好像是用了alias来替换bitstream、monspace等几个常用字体的,但是都是先英文的,后中文的,会是这个问题么?我先试试把~/.fonts.conf删了看能解决不.

小楼东风

好像gnome默认的编码是utf8，如果locale不一样就会出事。

fallen

都说是正常情况啦，
pango可以在同一个界面中，同不同的字体显示需要的文字
比如中文+日文的歌曲名，pango可以用日文的字体显示中文字体中不包括的部分
kde没有pango的支持，所以显示不了某些字体不能显示的字符，所以就变成方块了
kde4会有一个类似的字体匹配机制