如果你的补丁能够照顾到全世界所有人，那当然是好事，全中国的 GNU/linux 用户也会感谢你。
我可以负责任的告诉你：GB18030 是没有问题的
如果你去看看我提交的那个 patch, 你就会发现了，除了 cleaner 之外，没什么差别的，所以原来的可以，现在的肯定没有问题，除非 amarok 其他地方又有了修改
我以后会使用 CVS HEAD 的 amarok 的，如果有问题我会立刻给他们提交 patch的
你的帖子中的中国人口有点问题吧。。。 笔误 ;)
呵呵，你这句话有意思：
＞否则别人如何就凭你的几句话就相信你
我个人觉得，我还是比较有信誉的吧，我好像还不至于去胡搅蛮缠吧？amarok 的开发人员虽然不知道如何写这个 patch ，但是他们看过我提交的 patch 后，1分钟之内 就说看上去没什么问题。他们只问了我一遍，是否这个patch打上之后，问题就解决。而后他们就对我承诺 这个 patch 会被放入 CVS 中，并且包含在下一个 发布版本中
关于我有时候写 英文的问题：你也知道，我是开发 skim 的，平时时常在调试，当我关掉 skim 重启它的时候，所有已经起动起来的程序中都不能输入中文了，我又不想 重启 firefox，因此就写英文了。在不影响交流的情况下，没什么不可以吧...
如果你的补丁能够照顾到全世界所有人，那当然是好事，全中国的 GNU/linux 用户也会感谢你。
我有这样的自信，当时才会去试着提交那个 patch 的。
这样其实不仅满足中文用户，任何使用 非 latin1 字符集的用户都不需要再进行任何额外设置了
把问题讲清楚，这就放心了。 :mrgreen:
liuspider， 你的补丁是比我和kanker写得干净和清晰 （good job）。
我在你的bug report里面重新向鬼老们又解释了一遍补丁的基本原理，希望他们能懂。
还有我想让你知道，UTF-8作为Linux默认的locale是不对的，这是一个既成的事实。
大部分mp3都是在windows下创建的，而windows默认的中文encoding却是GB18030而不是UTF-8, 同时UTF-8本身缺陷很明显（你google一下），在处理中文方面GB18030是现在最好的选择。
好呀！
GB18030的问题是很模糊的。字符集和编码方案是两个完全不同的概念，而中国的标准总是在混淆这两个东西。究竟什么是符合GB18030，这个谁也说不清楚。但就目前的情形来看，只要我的操作系统或者字体中包含了GB18030这个字符集，就是符合GB18030的，至于我采用什么编码，这个跟是否符合标准没有关系。
比较直观的例子就是Windows 2000+。虽然我没有看过Windows的源代码，但我一向认为微软不可能为了中国市场专门对操作系统的内核进行修改，Windows 2000+内部一定是Unicode的，而不是GB编码的。而且以现在字体厂商的精力，他们也不可能在GB18030的编码上有太多作为，大多数字体内部的映射表以及字型的排列顺序都是Unicode的。也就是说，操作系统的字型引擎会对这个映射表映射到GB18030字符集的相应位置。而Windows Server 2003和众多字体，均通过了国家部门的GB18030标准测试。
这样说来，是采用UTF-8还是GB18030作为操作系统的编码方案，是无足轻重的。只要我能够保证系统可以识别、显示、打印GB18030这个字符集中的所有字符，这样就够了。因此，如果补丁采用了fromLocal8bit这样的做法，实际上还是比较dirty的。
liuspider， 你的补丁是比我和kanker写得干净和清晰 （good job）。
我在你的bug report里面重新向鬼老们又解释了一遍补丁的基本原理，希望他们能懂。
还有我想让你知道，UTF-8作为Linux默认的locale是不对的，这是一个既成的事实。
大部分mp3都是在windows下创建的，而windows默认的中文encoding却是GB18030而不是UTF-8, 同时UTF-8本身缺陷很明显（你google一下），在处理中文方面GB18030是现在最好的选择。
多谢 :)
标准不一定都是普遍适用的：正如我已经说过的，由于开发输入法平台，我不能使用中国的 GB* 系列的编码，因此我才用 utf-8 的。如果只考虑中文，对于我来说，GBK也已经足够了。
GB18030的问题是很模糊的。字符集和编码方案是两个完全不同的概念，而中国的标准总是在混淆这两个东西。究竟什么是符合GB18030，这个谁也说不清楚。但就目前的情形来看，只要我的操作系统或者字体中包含了GB18030这个字符集，就是符合GB18030的，至于我采用什么编码，这个跟是否符合标准没有关系。
比较直观的例子就是Windows 2000+。虽然我没有看过Windows的源代码，但我一向认为微软不可能为了中国市场专门对操作系统的内核进行修改，Windows 2000+内部一定是Unicode的，而不是GB编码的。而且以现在字体厂商的精力，他们也不可能在GB18030的编码上有太多作为，大多数字体内部的映射表以及字型的排列顺序都是Unicode的。也就是说，操作系统的字型引擎会对这个映射表映射到GB18030字符集的相应位置。而Windows Server 2003和众多字体，均通过了国家部门的GB18030标准测试。
很同意的说。现在的内核，包括Qt 内部，都是使用的 unicode 的
这样说来，是采用UTF-8还是GB18030作为操作系统的编码方案，是无足轻重的。只要我能够保证系统可以识别、显示、打印GB18030这个字符集中的所有字符，这样就够了。因此，如果补丁采用了fromLocal8bit这样的做法，实际上还是比较dirty的。
是的，我觉得基于 locale 也不是特别好。我会再提交 一个更 dirty 的 patch，来 overwrite locale 的设定 :) 希望我可以说服他们接受...
好像有些人对那个patch 有些看法，我也回了一个 comment，希望让那个 俄国人明白
jackliu9999 at msn.com 是不是 KDE 啊？ 他说的话和 KDE 在这说的一样
to mandrakechina:
不过话又说回来：如果你的 locale 是 utf-8 编码的话，那么
fromUtf8 和 fromLocal8Bit 的效果是完全一样的
to jackey,
你写的那些不仅仅适用于 CJK 用户吧， 你像对于那个 俄国人，也是一样的步骤的啊
哈哈，老毛子让他自己去玩吧。你有KDE的MSN吧？ 叫他给你我的MSN，想问你几个问题关于这个补丁。我手头有cjacker一个超级补丁，可是我看不懂。据说可以从根本上解决QT所有程序的中文问题。
liuspider, 你看样子得找个老婆，不然你的补丁都会很 "dirty" *^_^*