gnome下的文件打包器？

gnwd

我使用gnome下的文件打包器，打包为zip, 自己解开是可以的，里面的文件可以正常使用。但是邮件接收者告诉我无法正常解压，因此我转移到windows测试了一下，的确如此。

请问，大家遇到过这个问题吗？。（命令行的tar我还没有尝试）

附件提供
补充：创建zip和tar.gz是一样的结果，windows下打开都有问题。

[xi@linux ~]$ locale
LANG=zh_CN.UTF-8
LC_CTYPE="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_PAPER="zh_CN.UTF-8"
LC_NAME="zh_CN.UTF-8"
LC_ADDRESS="zh_CN.UTF-8"
LC_TELEPHONE="zh_CN.UTF-8"
LC_MEASUREMENT="zh_CN.UTF-8"
LC_IDENTIFICATION="zh_CN.UTF-8"
LC_ALL=

gnwd

下面是网上看到的，如果黑体部分属实，那么如果文件系统将来采用了不同的字符集，不禁有点担心具有中文名称的文件可能出现问题。

　　这篇文章的部分观点是我的个人看法，可能会有错误，希望大家指正。
　　WINDOWS与LINUX/UNIX对文件系统字符集的处理方式是不相同的。WINDOWS文件系统驱动层本身就有对字符集转换、处理的模块，无论从操作系统上下达的是什么字符集，最后要统一转换到不同文件系统的字符处理模块上，比如存储在NTFS上的文件名称，现在几乎统一以$I30方式索引，采用UNICODE方式存储。而LINUX/UNIX则不同，文件系统驱动层本身并不负责对字符集的处理，操作系统传下来的文件名称以字节流的方式直接记录进文件系统索引结构，并不去理解字符集，所以，在同一个LINUX/UNIX文件系统中，可以允许目录结构中有多种不同的字符集存在。
　　如果在LINUX/UNIX下对某些文件做了tar包，tar包里便直接记录从文件系统上读到的名称字节流，那如果这个TAR包在 WINDOWS下解压，便很有可能会出现乱码，或无法解压。其实解决的办法很简单，只要把WINDOWS调整成不同的字符集，解压对应的文件即可，只是这个对应需要人工去判断了。
　　打开WINDOWS的控制面板，选择“区域和语言选项”，再移至“高级”选项卡上，在“选择一种语言，使之与您使用的非UNICODE程序的语言。。。。”一项上选择相应的字符集。然后，将tar包里对应这个字符集的文件解压到NTFS文件系统上，这些文件就会自动转换成UNICODE通用字符集。再换成其他字符集，解压，就可以把别的字符集也转换成UNICODE了。
　　很多NAS设备，由于用户使用的字符集可能不同(典型的，香港、台湾地区、大陆的联合企业使用的NAS)，这样如果对NAS数据做备份后，想在WINDOWS上解开，网管对LINUX又不熟，用这个方法可能能容易的解决。

gnwd

还有一篇可以参考。似乎我现今看到的最简单答案是采用第三方的压缩工具（rar或者7zip，不过我都没有试过）

在很久很久以前——大约是2年多年前，我整了一台P3的机器装了FreeBSD 6.2做服务器，经常用Filezilla的SFTP往里面备份本地的文件，当然也包括一些中文名的文件。一切都很正常，上传下载都没问题，即使是用 SSH连过去用Tar打包再Gzip压缩以后下载下来解开都没问题。

但是好日子在前几天到头了。我前一阵又弄了一台P3的机器装了Ubuntu 7.10。问题出现了：

首先是在Windows上用Filezilla连接Ubuntu时看到的中文文件名全是乱码，但是用Putty通过SSH连接Ubuntu却是正常的（原先是乱码，后来改设置为UTF－8编码就好了，不过Filezilla没有类似的设置可改）。如果用Filezilla向Ubuntu上传本地的中文文件，则在Filezilla里看到Remote端的文件名是正确的，但在Putty里看到是乱码。

然后更严重的问题是：当我在Ubuntu上用Filezilla的SFTP从FreeBSD上下载文件时发现那些中文文件名都成了乱码。只好改用 tar/tar.gz再试，结果还是乱。最后问了Google，但是结果并不理想，试过很多方法都无法解决，甚至为此特地在FreeBSD和Ubuntu 上都装了p7zip试验，也还是不行。

折腾了好几天之后，我才想到应该研究一下几个系统上的locale设置究竟是如何的——坦白说，要不是因为搜到的资料里有提到这方面，我从前还真没注意到这回事。在FreeBSD和Ubuntu上分别运行了locale命令检查的结果是：

FreeBSD的LC_ALL为“C”，即”POSIX”的别名，似乎是一种无固定编码的方案，或者可以认为就是本地编码，默认的设置。
Ubuntu的LC_ALL为“zh_CN.UTF-8”，这个是我设置的。
Windows不必说了，肯定是本地编码——只是我没有想到的是，公司里用的英文版Windows居然也是本地编码，我一直以为是Unicode的，看来是为了保持兼容。

这样就好理解了，Filezilla不改变编码方式，所以当Remote端与本机的编码不一致时，必然乱码。所以在Windows上用 Filezilla连接Ubuntu看到乱码，而我的Putty因为是设置为UTF－8编码，所以看到的是正确的——因为Ubuntu一端是UTF－8。而如果用Filezilla上传中文文件，则因为Windows是本地编码，所以上传以后仍然为本地编码（GB系），而Ubuntu是UTF－8所以是乱码。

FreeBSD那边的问题也是一样的，因为那些文件都是以前从Windows上传上去的，用的都是GB系编码，而早年我用Putty都是用默认的本地编码方案，所以一直没有发现问题。这样的话，因为FreeBSD是本地编码，与Ubuntu的UTF－8不一致，所以怎么弄都是乱码。

但是据说用7zip这样的工具打包以后是可以解决这样的编码不一致问题的，我试了却没有成功。后来才想明白，因为7zip是根据系统的locale设置来对文件名进行相应的处理，因为原来我处理的时候文件名是GB系的编码，而系统是设置为UTF－8，所以总也不对。

最后的解决方案是：

在ubuntu上用以下命令：

export LC_ALL="zh_CN.GBK"
scp raptor@freebsdserver:/home/raptor/myfiles/*.* .
export LC_ALL="zh_CN.UTF-8"
convmv -f GBK -t UTF-8 --notest *.*

原理就是先把ubuntu的locale改为GBK，然后用SSH COPY文件过来，再改locale为UTF－8，然后用convmv来转换文件名的编码。

不过经过试验表明，不改变locale直接scp也是可以的，因为scp并不会改变文件的编码方式，不过改了locale以后便于在转编码之前检查scp过来的内容（否则scp过来是乱码，要到转编码后才正常）。

这样做的结果就是，这些文件在ubuntu上是正常了，以后要再弄回windows就比较麻烦，需要用7zip之类的工具打包下载再解开。

归根到底这些问题都是因为该死的Windows用本地编码来记录文件名，Unicode化做得不够彻底。

gnwd

我试过了，安装一个p7zip, 然后gnome文件打包器就可以创建7zip格式了。并且在windows下解压没有问题

linuxaker

我在windows下直接解压也提示有问题 原因是文件夹名和文件夹里的文件名都是乱码,所以无法解压...
   经过我的试验 解决方法如下: 在windows下双击.zip文件 会打开winrar的界面 在界面里右键单击文件夹或着文件名 选-->重命名  然后随便起个名字(这样名字就不是乱码了) 就可以正常解压了...  解压出来的文件内容不会有影响; 你的doc文件里是下面的内容吧:

考核方式及所占比例：
1、平时作业：（布置   次，是否按时交，成绩等方面）占    %；
2、课堂讨论和提问：（有原始记录、成绩评定）占    %；
3、阶段测验：（有成绩记录）占    %；
4、实验：（应做   次，有实验报告）占    %；
5、小论文：（论文题目，评分成绩记录）占    %；
6、考勤：（有考勤记录表、迟到缺课扣分标准）占    %；
7、其他方式：占    %；

附: 估计是文件名或着文件夹名编码问题.你压缩成为.ZIP文件的时候试试用英文做文件夹名或着文件名说不定会解决问题的.(猜想,没试)