mplayer with a gtk2 gui
如题，最新的svn，不过对中文目录的支持不是很好 :lol: ，totem-xine也存在中文目录支持的问题，kaffeine没有问题。totem-gst 也没有问题，gxine对中文目录支持良好，所以我将来如果打包gnome 214会考虑gxine 和 totem-gst totem-xine 需要设置一个变量, 好像叫 G_BROKEN_FILENAME 吧? G_FILENAME_ENCODING=GBK 这个好像也行. 反正我的 gentoo 的 totem 在设置变量后很好.而 mplayer 的 gtk2 frontend , 有一个中文补丁, 也要 G_FILENAME_ENCODING=GBK
http://wall_john.blogeden.cn/post/140172/4592 这就是使用非UTF-8 Locale带来的问题，GTK2是根据G_FILENAME_ENCODING、G_BROKEN_FILEENCODING(deprecated)和locale来确定文件名的编码的。
GBK编码的补丁
这是我之前改的针对GBK编码的补丁，最新版本的可能要略微改一下。补丁这里：
http://wall_john.blogeden.cn/get/140172/mplayer-1.0.20060415-cjk.patch
图片这里：
http://www.blogeden.cn/resserver.php?blogId=140172&resource=1234-mplayer.jpg 满漂亮的 这就是使用非UTF-8 Locale带来的问题，GTK2是根据G_FILENAME_ENCODING、G_BROKEN_FILEENCODING(deprecated)和locale来确定文件名的编码的。
现在 windows 还是 GB 编码的天下，使用 utf-8 那才叫麻烦大呢，win 分区乱码怎么办？你总不能把 win 分区里所有的文件名、目录名改成 utf-8 吧？我们主要考虑的还是 win 兼容问题。 GB 编码使用这么多年，你难道能说历史上作出过巨大贡献的东西是错误的么？ 抛开中文问题不说，单论媒体播放，目前totem-xine要比totem-gst要好。xine到底是久经考验的东西，对一些问题影片，或者有错误的影片，处理起来比较好，某些方面甚至比mplayer要好。当然gstreamer是将来的趋势，不过现在的可用度并不见得就能超过libxine。 发现现在都快忘了mplayer的说。 几乎都用kaffine。 我还是用自己编译的mplayer,速度爽啊！放hdrip不错 我用 kaffeine 调用 mplayer . 这就是使用非UTF-8 Locale带来的问题，GTK2是根据G_FILENAME_ENCODING、G_BROKEN_FILEENCODING(deprecated)和locale来确定文件名的编码的。
现在 windows 还是 GB 编码的天下，使用 utf-8 那才叫麻烦大呢，win 分区乱码怎么办？你总不能把 win 分区里所有的文件名、目录名改成 utf-8 吧？我们主要考虑的还是 win 兼容问题。
大哥，Windows中的文件名是GB编码的？你弄错了，它们都是Unicode编码的，只是你在Windows上使用API读取出来的时候，会转化成GB编码；而在Linux上，根本就没有用到Windows API,所以读取出来的还是Unicode,而用户都不使用Unicode，所以在mount的时候，会要指定编码。
你所说的乱码，那是因为你使用了错误的mount参数。比方说，在UTF-8的Locale下使用GBK编码来mount；当然，即使你使用GBK的locale,你如果使用UTF-8编码来mount的话，同样也会出现乱码。我使用UTF-8编码好些年了，都没有出现FAT文件名乱码的事情。所以，文件名是否乱码，跟locale无关。
我现在遇到比较麻烦的事情，就是做FTP server时，Windows的ftp client会想当然地认为服务器端的文件名编码跟本地一样（其实这也是ftp协议的问题，新的ftp协议好像已经修正，但是很少有服务器和客户端支持，Filezilla好像就支持），从而这里可能会造成问题，当然也有解决办法，只是不够graceful。另外，就是rar打包的中文文件名，也是不好解决的一个问题。 怎么说呢，用utf-8是不错。但是现在用utf-8会有个别的中文问题，但就是这种小问题会引起的麻烦远大于用gbk引起的麻烦。
比如我开个ftp服务器，比如我用latex创建中文文档，比如直接telnet bbs.
让人头疼的很。
这就是使用非UTF-8 Locale带来的问题，GTK2是根据G_FILENAME_ENCODING、G_BROKEN_FILEENCODING(deprecated)和locale来确定文件名的编码的。
现在 windows 还是 GB 编码的天下，使用 utf-8 那才叫麻烦大呢，win 分区乱码怎么办？你总不能把 win 分区里所有的文件名、目录名改成 utf-8 吧？我们主要考虑的还是 win 兼容问题。
大哥，Windows中的文件名是GB编码的？你弄错了，它们都是Unicode编码的，只是你在Windows上使用API读取出来的时候，会转化成GB编码；而在Linux上，根本就没有用到Windows API,所以读取出来的还是Unicode,而用户都不使用Unicode，所以在mount的时候，会要指定编码。
你所说的乱码，那是因为你使用了错误的mount参数。比方说，在UTF-8的Locale下使用GBK编码来mount；当然，即使你使用GBK的locale,你如果使用UTF-8编码来mount的话，同样也会出现乱码。我使用UTF-8编码好些年了，都没有出现FAT文件名乱码的事情。所以，文件名是否乱码，跟locale无关。
我现在遇到比较麻烦的事情，就是做FTP server时，Windows的ftp client会想当然地认为服务器端的文件名编码跟本地一样（其实这也是ftp协议的问题，新的ftp协议好像已经修正，但是很少有服务器和客户端支持，Filezilla好像就支持），从而这里可能会造成问题，当然也有解决办法，只是不够graceful。另外，就是rar打包的中文文件名，也是不好解决的一个问题。 pupilzeng 兄自己搞错了吧。UTF8码和GBK码都能显示中文（P话），问题是80%以上的文档资料是GBK编码时，你是否愿意花费精力去转换它。首先我不懂 pupilzeng 在说什么，Linux上编程本身使用的就是UTF8编码，这和locale无关，WIN上编程使用UNICODE也同样和locale无关，但中文WIN上默认绝对不存在unicode编码的文件名，别把编程和存储混为一谈。
长期以来服务器的数据都是以GB码存储的，你们看到有多少中文WEB页是UTF8码的？转换使用UTF8码，所有的WEB页为了唯护时正常显示（非WEB浏览）需要全部转码，数据库文件为了能和WEB页一致也要转换，这些是系统唯护员、程序员爱干的事？目前我所知批量转文件名的指令是convmv，BS一下，ML2没有这个东西，批量转换文件的只好自己写脚本了。
最难改变的是习惯和历史积留问题。
建议下个版本集成这个东西：http://j3e.de/linux/convmv/ pupilzeng 兄自己搞错了吧。UTF8码和GBK码都能显示中文（P话），问题是80%以上的文档资料是GBK编码时，你是否愿意花费精力去转换它。首先我不懂 pupilzeng 在说什么，Linux上编程本身使用的就是UTF8编码，这和locale无关，WIN上编程使用UNICODE也同样和locale无关，但中文WIN上默认绝对不存在unicode编码的文件名，别把编程和存储混为一谈。
长期以来服务器的数据都是以GB码存储的，你们看到有多少中文WEB页是UTF8码的？转换使用UTF8码，所有的WEB页为了唯护时正常显示（非WEB浏览）需要全部转码，数据库文件为了能和WEB页一致也要转换，这些是系统唯护员、程序员爱干的事？目前我所知批量转文件名的指令是convmv，BS一下，ML2没有这个东西，批量转换文件的只好自己写脚本了。
最难改变的是习惯和历史积留问题。
建议下个版本集成这个东西：http://j3e.de/linux/convmv/
用户以后必须面临混乱，这种混乱不是由用户造成的，而是由系统造成的。
国外的版本基本上都采用utf8了，大家也都知道，中国人向来都是国外的月亮比国内圆(这也是为什么那么多人为ubuntu服务)，所以，肯定仍然是绝大多数人用国外的版本。
这时候网络中就可能会出现utf8的ftp，utf8的文本，等等。
现在缺少的，也可以说是mission impossible的是一个能100%正确的charset detector。
页:
[1]
2