看起来 gstreamer 0.10 再度回到了老路上。据联系过他们的人称，他们明确拒绝支持 ID3v2 里非 UTF-8 的编码。
我这没问题。只是我用的 cvs 版的补丁。
cvs 的补丁？
cvs 的 gstreamer 0.10 支持非 UTF-8 的编码吗？
UTF-8 locale 下使用还是有问题，没有将 GBK 转成 UTF-8 输出。
请阅读一下这个补丁，设置环境变量 GST_ID3_TAG_ENCODING=gbk
已经设置了。Gstreamer版本0.10.8。在打你的补丁之前，GBK locale下，还是有很多mp3文件的tag识别不对；打了补丁之后，大部分文件的tag识别对了。但在UTF-8 locale下，没有一个是对的。
在打好补丁、设好环境变量后，使用这个命令查看效果：
$ gst-launch -t filesrc location=变的坚强.MP3 ! decodebin ! audio/x-raw-int ! fakesink
应该会是只有在支持 UTF-8 的终端中才能看见中文。抱歉我使用全 UTF-8 环境，所以没有在 GB locale 下测过。当然这个补丁本身是不依赖于 locale 的，它有自己的环境变量 GST_ID3_TAG_ENCODING。可以 gbk、gb2312、gb18030 等换着试。
如果命令打下去仍然看不见中文，那估计是你系统的问题了，你可以把该 mp3 传上来，我们大家帮你试试。
补丁打在 g-p-good 0.10.3 上，不是 gstreamer，也不是 g-p-ugly。
在打好补丁、设好环境变量后，使用这个命令查看效果：
$ gst-launch -t filesrc location=变的坚强.MP3 ! decodebin ! audio/x-raw-int ! fakesink
应该会是只有在支持 UTF-8 的终端中才能看见中文。抱歉我使用全 UTF-8 环境，所以没有在 GB locale 下测过。当然这个补丁本身是不依赖于 locale 的，它有自己的环境变量 GST_ID3_TAG_ENCODING。可以 gbk、gb2312、gb18030 等换着试。
如果命令打下去仍然看不见中文，那估计是你系统的问题了，你可以把该 mp3 传上来，我们大家帮你试试。
补丁打在 g-p-good 0.10.3 上，不是 gstreamer，也不是 g-p-ugly。
多谢，已经找到原因了。原先是设置成 GST_TAG_ENCODING=GBK,GB18030,UTF-8 ，我记得在0.8下是可以的。后来查看你的补丁，发现多个编码之间是用 G_SEARCHPATH_SEPARATOR_S 也就是 : 来分隔，改成 GST_TAG_ENCODING=GBK:GB18030:UTF-8 就可以了。还发现 rhythmbox 不会自动更新 tag 信息，打了补丁后，非得删掉重新加入才可以。
建议还是不用 G_SEARCHPATH_SEPARATOR_S 来分隔编码，因为不同系统下这个字符并不一样，比如在 Windows 下是 ; 。
不好意思见笑了，其实这个补丁大部分代码都是gst中现成的，我只是拷贝了一下。包括你说的 G_SEARCHPATH_SEPARATOR_S，实际上我都没怎么看过。鉴于现有的代码就是这样的，我觉得我们还是保持现状吧；）
实际是 linux 中环境变量都用:分隔的，如 PATH, DISPLAY, 主机:端口号。用逗号的太少了。 :-D
实际是 linux 中环境变量都用:分隔的，如 PATH, DISPLAY, 主机:端口号。用逗号的太少了。 :-D
用 , 是比较少，但是考虑万一有一天Gstreamer移植到Windows，G_SEARCHPATH_SEPARATOR_S就变成 ; 号了，所以这个环境变量又会设置不对了。
实在不好意思，不知道怎么安装patch :oops:
如果你用 fc5 的话，我给它打了个包。如果用 magiclinux，仓库里也有。
ubuntu 6.06，不知道怎么打这个布丁啊。。。
我想你需要找个会打包的人帮你。Penguin? 在不在？
我想你需要找个会打包的人帮你。Penguin? 在不在？
您是补丁作者，难道您不能帮我解释下该怎么操作么？麻烦您了
晕.. :neutral:
最近家里网络中断。暂无法提供这些服务。 :neutral:
根据 id3v2.4.0 的标准，tag 里的字符串可以使用 ISO-8859-1、UTF-16、UTF-16BE、UTF-8 四种编码。咱们 id3 tag 用 gb 编码的其实是宣称它用的 ISO-8859-1 的编码，这样的 tag 也就是在中国的电脑上有可能正常显示（只是有可能，也不一定，咱们都是目击证人，呵呵）。如果是遵照人家的标准写的 tag 的话，拿到哪台电脑上都能正常显示，只要有合适的字体就行。
用 千千静听 写的 UTF-16 编码的 id3v2.3.0 tag 就是合乎标准的，可以正常地在 windows 里，在 rhythmbox 里，在 totem 里显示──不用任何补丁和设置的。至于 mp3 随身听，只要是神智健全的产品，都支持标准的。现成的例子就是前面那位兄弟的 iriver，还有 nokia 的手机。
xLoneStar 老兄，不是我泼你的冷水，我觉得与其写一个纵容错误的补丁，不如写程序把现有的 mp3 转一转。毕竟标准本来就是用来遵守的。我自己就写了一个 C 语言程序把我的 mp3 转成 id3v2.4 UTF-16 编码的了。现在在 Linux 下和 千千静听 里都没问题，可是 Windows Media Player 不认──好像它最高就认 3.0 的 tag。难怪 千千静听 写的 tag 是 3.0 而不是 4.0 的。
另外，beep-media-player 写的 tag 是 UTF-8 编码的，但它也没遵守标准。以致于在 rhythmbox 这些遵守标准的播放器里不能显示，在 Windows 里也不能显示……晕……因为 easytag 和 id3v2 这些程序和 bmp 用的一样都是 id3lib 这个库，所以，它们写的 tag 应该也是不标准的。推荐使用 eyeD3 这个程序。
不要用 id3lib 这个库了。我写的那个程序用的是 libid3tag 这个库。另外好像 libtag 库也可以用，不过是 C++ 语言的。
这样的观点我已经反驳过很多次了，其实不太愿意重复，不过还是提一提。
1）起源。使用GB2312字串不是邪恶之举。在整个 Unicode 概念出现之前，改革开放的春风吹拂大地时，（1980年）人们发明GB2312，作为 ASCII 的扩展，目的是使大量西文现成软件，不必进行修改就可直接支持中文。ID3标签问题亦属此列。
2）现状。中国的互联网上有不计其数的mp3（D版之国）。假设其中有一半具有中文标签，再一半是 ID3v2。那么不计其数的 1/4 仍然是不计其数。其中绝大部分用的是 GB2312。
我决不否认 Unicode 方案更先进，但此刻我们不是在进行先进性教育。当这个古老国度的绝大部分人都在使用，并且预计根据惯性仍将持续使用一种不太先进的方案时，我们绝不能称这种现状为“错误”。广泛应用本身就证明着合理性。
落后的方案是落后的，但不意味着我们的软件就无法兼容它。我的方案证明了我们可以两头兼顾。
我十分欣喜地看到你和许多其他人正致力于推进先进的 Unicode 方案。这很好，同时我还十分欣喜地发现我的方案并不会对你们的方案造成阻碍，我们是互补的。
最后，本贴提出的是一个针对mp3标签乱码的解决方案。欢迎就方案本身进行讨论，但我不希望进行关于“是否有必要”的讨论了。对后一个话题感兴趣的朋友请另开新贴，我会欣然前往灌水。