一个现在还没有解决的gnome中文问题。

linusware

""我所关心的是,gnome中的nautilus什么时候才能解决在过程对话框和nuatilus里的,尤其是samba/cd-burner 的时候..........非utf-8文件名的显示问题?和绝对是因为这个原因----nautilus无法识别和判断非utf-8文件名---而导致的nautilus在进行文件操作时的频繁的崩溃??!!"''

=========
"我的Mandrak Offical 10 gnome 2.4 里繁体中文的文件/文件夹的名字的显示还是"无效的 unicode 字符",在gnome 里,文件复制或者粘贴的进度窗口里的中文名还都是乱码".
=======================
解决文件复制/移动 进程对话框中，显示“无效的unicode代码”而导致一复制大一点或者多一点的文件nautilus就崩溃的问题？有没有解决samba中无效的unicode代码的问题？

说到底，有没有解决中文非utf-8编码的自动显示转换问题？我的nautilus崩溃100%是因为这个原因。
郁闷啊。自己打补丁太麻烦，郁闷啊。

===================
===============
上面我说的都是一个问题---一个非常普遍和烦人的问题-----设置了
G_BROKEN_FILENAMES ，只是解决了像gqview等gtk2程序的中文文件夹显示问题，对于nautilus复制中文文件名文件的崩溃，也没有用。
在拷贝/移动文件进度对话框中，不能正常显示当前编码文件名，而是仅仅标一个“无效的 Unicode”字样，然后马上nautilus崩溃了。
只要文件稍微一多，超过5个左右，必然如此。一个两个的还能应付。
在要复制/粘贴/移动的文件数量多的情况下，发生的概率：100%

-------------------------------
现在有这样的一个补丁：
(介绍)http://www.linuxfans.org/nuke/mo ... pic&t=41573


补丁下载地址：
http://www.linuxfans.org/nuke/modules.php?name=Forums&file=download&id=7359
=================

我自己编译老是不成功，希望大家有办法从根本上解决。

sunmoon1997

try this patch.

xLoneStar

唉，这些个补丁不就是我当年搞过的么。这样的补法也实在没意思，补完 nautilus 还会要补 rhythmbox，还要再补 gthumb，还要再补 beep，看不见有补完的那一天。

这不是解决问题的正确方法……

hzhr

没有碰到过，try UTF-8 locale.

linusware

[quote:f371fdaf9b="xLoneStar"]唉，这些个补丁不就是我当年搞过的么。这样的补法也实在没意思，补完 nautilus 还会要补 rhythmbox，还要再补 gthumb，还要再补 beep，看不见有补完的那一天。

这不是解决问题的正确方法……[/quote]

就是你当年那些啊。

非常有同感！！！！！
欲哭无泪。中国政府还搞什么aisalinux，这样的问题都解决不了，谈什么啊---utf-8标准的问题。

linusware

UTF-8 locale  也有很多的问题。非本地的数据呢？比如ftp上的？samba--nautilus？

xLoneStar

文件名的问题上，状况是这样的：

1) 采用 Unicode 的必要性：地区编码的文件名，使你能使用的字符局限于当前 locale。每当切换了 locale，文件名都变成乱码。

采用 Unicode 文件名的操作系统，比如 Windows 系列，就没有这个问题。你往软驱里插入一张比如说，来自日本的软盘，里面的文件名会显示得和它在日本时完全一样，不会乱码。

2) 全 utf-8 编码方案的不足：

和传统的应用程序完全不兼容，比如 Mozilla, 比如终端里的文件名自动补齐

和现有广泛流行的应用不兼容，比如 ftp 等协议，传递 utf-8 编码文件名上去后别人都看不懂。比如把 utf-8 编码文件名打包进 zip 或者 tar，传给 Windows 用户后人家无法复原。

可见，在文件名问题上，右倾的纯地区编码方案太局限，左倾的纯 unicode 方案抛弃传统又太激进。要让 Unicode 方案普及，必须有一条平滑的迁移之路，这条路必须兼顾传统应用和 unicode-aware 应用。

因此现在需要寻找的是这样一个方案，同一个文件名，必须有办法同时呈现 unicode 和非 unicode 两个面目。当 unicode 程序去访问时，应该读到 unicode，而非 unicode 程序则将读到它的地区编码版本。两个版本代表着同一个文件，互相关联。当这样的方案出台后，我们才有机会真正开始 unicode 的迁移。

amplifier

[quote:e2f370f73a="xLoneStar"]文件名的问题上，状况是这样的：

1) 采用 Unicode 的必要性：地区编码的文件名，使你能使用的字符局限于当前 locale。每当切换了 locale，文件名都变成乱码。

采用 Unicode 文件名的操作系统，比如 Windows 系列，就没有这个问题。你往软驱里插入一张比如说，来自日本的软盘，里面的文件名会显示得和它在日本时完全一样，不会乱码。

2) 全 utf-8 编码方案的不足：

和传统的应用程序完全不兼容，比如 Mozilla, 比如终端里的文件名自动补齐

和现有广泛流行的应用不兼容，比如 ftp 等协议，传递 utf-8 编码文件名上去后别人都看不懂。比如把 utf-8 编码文件名打包进 zip 或者 tar，传给 Windows 用户后人家无法复原。

可见，在文件名问题上，右倾的纯地区编码方案太局限，左倾的纯 unicode 方案抛弃传统又太激进。要让 Unicode 方案普及，必须有一条平滑的迁移之路，这条路必须兼顾传统应用和 unicode-aware 应用。

因此现在需要寻找的是这样一个方案，同一个文件名，必须有办法同时呈现 unicode 和非 unicode 两个面目。当 unicode 程序去访问时，应该读到 unicode，而非 unicode 程序则将读到它的地区编码版本。两个版本代表着同一个文件，互相关联。当这样的方案出台后，我们才有机会真正开始 unicode 的迁移。[/quote]

看来看去看不懂啊，呵呵。你究竟说Windows是Unicode还是本地编码呢？utf-8不就是Unicode的一种表示方式吗？既然Windows是Unicode，为什么会看不到utf-8的文件名呢？

xLoneStar

1.Windows 是 Unicode (UCS2) 的
2.UTF-8 是 Unicode 的一种
3.Windows 下的部分软件，比如 Winzip 和 WinRAR，他们是将文件名的地区编码版本存进了.zip或.rar 文件中。如果你做出一个.zip/rar 里面的文件名是 UTF-8 码的，它们识别不了，解压后就是乱码。

同样的情形也出现在 ftp 等协议中。往 windows ftp 服务器上传的文件名，都会被当作当前地区编码对待，如果你传个 utf-8 的，处理也会不正常。