论坛 › ＰＣ数码 › ftp编码问题

明のｓｋｙ 发表于 2012-2-20 17:23

ftp编码问题

用Xlight架设FTP
D.C. ～ダ・カーポ～ 第01話 ｢好きになっちゃダメですか？｣ (DVD 1280x720 x264 AAC rev).mp4

文件名有那个该死的点
用filezilla打开后成了这样，

D.C. ～ダ?カーポ～ サイドエピソード#01 (DVD 1280x720 x264 AAC).mp4

而且还是不能下载，下载不了
无论在Xlight中开启或者关闭 utf8 encode 都一样结果。

Filezilla 强制utf8模式又打不开文件夹

服务器的东西拖不回来 本地又BT走不了 那个杯具

neverer 发表于 2012-2-20 17:26

filezilla不清楚，可以试试ftprush，另外如果flashfxp遇到这种可以用高级传输--传输为，自己修改下传过来的文件名就行了

鸡蛋灌饼 发表于 2012-2-20 17:30

xlight对UTF-8的支持很莫名，说能支持但经常有莫名其妙的问题
想彻底解决换server
引用第1楼neverer于2012-02-20 17:26发表的:
filezilla不清楚，可以试试ftprush，另外如果flashfxp遇到这种可以用高级传输--传输为，自己修改下传过来的文件名就行了 images/back.gif

面对编码问题FlashFXP就是一垃圾

neverer 发表于 2012-2-20 17:36

引用第2楼鸡蛋灌饼于2012-02-20 17:30发表的:
xlight对UTF-8的支持很莫名，说能支持但经常有莫名其妙的问题
想彻底解决换server

面对编码问题FlashFXP就是一垃圾 images/back.gif

虽然显示的乱，不代表不能下载……

明のｓｋｙ 发表于 2012-2-20 17:54

引用第3楼neverer于2012-02-20 17:36发表的:

虽然显示的乱，不代表不能下载…… images/back.gif


你那方法也下载不了

鸡蛋灌饼 发表于 2012-2-20 17:54

引用第3楼neverer于2012-02-20 17:36发表的  :

虽然显示的乱，不代表不能下载…… images/back.gif

FlashFXP的核心就根本没用Unicode
引用第4楼明のｓｋｙ于2012-02-20 17:54发表的:


你那方法也下载不了
images/back.gif

别折腾了
xlight遇到这类问题经常抽风
我弄过几个站点之间的FTP同步，Gene6，vsftpd和xlight之间就xlight出这种编码问题
Windows还是推荐Gene6，没复杂要求的服务器系统直接上IIS，对授权敏感的上FZ Server

明のｓｋｙ 发表于 2012-2-20 17:59

ftprush好像不支持网络映射硬盘

明日の香 发表于 2012-2-20 18:46

开个日文的xpmode下载

elvis_w 发表于 2012-2-20 20:29

试试SFTP(SSH)

鸡蛋灌饼 发表于 2012-2-20 22:05

引用第8楼elvis_w于2012-02-20 20:29发表的  :
试试SFTP(SSH) images/back.gif

开什么玩笑
能上ssh的环境谁还用xlight
引用第7楼明日の香于2012-02-20 18:46发表的  :
开个日文的xpmode下载 images/back.gif

不说这方案完全不着边，就算你自己能用，别人能么？
人手一个虚拟机？

PhoenixDown 发表于 2012-2-21 10:22

明日の香 发表于 2012-2-21 11:12

引用第9楼鸡蛋灌饼于2012-02-20 22:05发表的:

不说这方案完全不着边，就算你自己能用，别人能么？
人手一个虚拟机？ images/back.gif

你吃了枪药了？
又不是跟你说，你胡乱喷啥？

x3c 发表于 2012-2-21 11:29

好几年前也在这里问过FlashFXP关于日文里那个点的问题，至今没有解决方法，每次只能上服务器把文件名改了，等文件下来再改回去。马克一下看现在有没有更好的解决方法……

aqssxlzc 发表于 2012-2-21 12:59

鸡蛋灌饼 发表于 2012-2-21 15:33

FTP的编码问题——特别是Windows环境——其实很复杂也很头疼，虽然解决方案很简单
至于复杂在哪和简单在哪，看完下面的扯蛋就一目了然了

先从Windows本身开扯（考虑到*nix用户底子都不错在此不予赘述）
Windows系统中字符串所用的编码可以分为两层，一层是内核所用的，此层编码自从Windows 2000之后一直是UTF-16，该编码能支持所有已编码的字符，也不会出现・、♡被变成?这类问题。

另外一层，就是由于兼容考虑而保留下的ASCII兼容编码，GBK、BIG5和Shift-JIS都属于这一类。
但这层仅仅是对UTF-16的封装，最后交由系统处理时还会转换成UTF-16。同样，系统返回给用户程序的字符串也要反着变一下
这样问题就来了，ASCII兼容编码何其多，系统本身肯定是不知道你这个程序用的是什么编码的，上述转换过程只能依靠系统编码页的设置来进行。
而修改编码页即为大家常见的“转区”。而相对的，直接使用系统内部编码（UTF-16）和对应的API的程序是不需要转区的——无论你现在的编码页设置是什么。

下面进入FTP部分：
为什么说FTP复杂呢？部分是因为FTP这个东西除了Windows已有的两层以外，自己又加上了可选的第三层，即UTF-8。
大家都知道FTP这货已经很老了，当初那个年代统一出ASCII都是个功绩，更不要提Unicode了，考虑兼容问题，FTP只能使用ASCII兼容的编码。
很自然的，为了支持中文FTP服务器可以直接发送GB编码的文件名，为了支持日文则可以发送Shift-JIS；但这种方案只能处理在GB和Shift-JIS中都有的字符，对于中文环境下的・啊♡啊和日文环境下的简体中文那就只有哈哈哈了  

为了解决这个问题，就需要前面所说的第三层，UTF-8。作为Unicode的编码方案之一，和UTF-16之间是可以无损转化的。这就能解决上面所说的各种问题了。

小结一下：
Windows核心——Windows兼容层——应用程序——网络
     UTF-16         UTF-16->ANSI      ANSI        ANSI
这是普通FTP Server，懒省事直接用ANSI编码

Windows核心——应用程序————网络
   UTF-16        UTF-16->UTF-8         UTF-8
这是文艺FTP Server ，全程Unicode支持，不会有任何多国语言支持问题

Windows核心——Windows兼容层——应用程序——网络
     UTF-16         UTF-16->ANSI        ANSI->UTF-8        UTF-8
这是2B FTP Server，自己没Unicode支持就算了还假装自己有
这种服务器上你会发现开启了UTF-8支持都不能正常显示和打开本地编码（即当前代码页）支持不了的字符




FTP的另一个麻烦之处在于，它不仅有服务器还有客户端，所以不仅服务器要解决Unicode问题，客户端也需要解决。
第一个问题，客户端要能正确判断服务器发的是什么编码。
我们先不去考虑UTF-8这个问题，只考虑ANSI。那么如果服务器发送的是GB编码，客户端以为是Shift-JIS，或者反过来的话……大家见过的乱码应该很多了我就不说了。

但是很不幸的是这个编码判断基本是“（只有）我靠（得住）”的状态，因为一般来讲，FTP程序会假设服务器传过来的数据按本地编码来解释，比如你的代码页CP936，即本地编码为GB时：

           网络——客户端————Windows兼容层——核心
（管你是什么）  ANSI->GB          GB->UTF-16         UTF-16

如果服务器发的是UTF-8或者是Shift-JIS，那么你就有麻烦了……

第二个问题，即使引入了UTF-8客户端也要能支持UTF-8才行

在Windows下，FTP服务器的UTF-8支持不是默认打开的——因为有大批老掉牙的FTP程序不支持UTF-8编码的。比如C:\\Windows\\System32\\ftp.exe
注意到FTP客户端的连接信息的人应该能发现"OPTS UTF8 ON"这么一段，这是告诉服务器开启UTF-8，否则FTP服务器只会发送ANSI编码的信息。

但很不幸，一部分2B FTP客户端不会去发送这么个东西，用户只好看着问号与日文齐飞，或者乱码共英文一色了

第三个问题，客户端要支持Unicode

好，现在我们有一个支持UTF-8的客户端，但如果它的核心不支持Unicode，那么……

网络——客户端————兼容层——————核心
UTF-8    UTF-8->GB      GB->UTF-16          UTF-16
很好，客户端成功的在第二步把・和♡转换成了乱码

值得注意的是，FlashFXP即使能显示（不在本地编码中的）Unicode字符，也还是不能处理这些文件
换句话说，它的核心依然没有使用Unicode





普文二完整版总结：
Windows核心——Windows兼容层——FTP服务器——网络——FTP客户端——Windows兼容层——Windows核心
UTF-16                 UTF-16->GB           GB->ANSI     ANSI          ANSI->GB         GB->UTF-16               UTF-16
普通流程

Windows核心——FTP服务器————网络——FTP客户端————Windows核心
  UTF-16            UTF-16->UTF-8      UTF-8       UTF-8->UTF-16        UTF-16
文艺流程

Windows核心——Windows兼容层——FTP服务器——网络——FTP客户端——Windows兼容层——Windows核心
UTF-16                 UTF-16->GB           GB->ANSI     ANSI          ANSI->Shift-JIS    Shift-JIS->UTF-16               UTF-16
2B流程A，服务器和客户端都不支持Unicode，而且两者使用代码页不同

Windows核心——FTP服务器——网络——FTP客户端——Windows兼容层——Windows核心
UTF-16            UTF-16->UTF-8    UTF-8      UTF-8->Shift-JIS    Shift-JIS->UTF-16               UTF-16
2B流程B，客户端不支持Unicode，从UTF-8转换回Shift-JIS导致简体中文字符的丢失

Windows核心——Windows兼容层——FTP服务器——网络——FTP客户端——Windows核心
UTF-16                 UTF-16->GB           GB->ANSI     ANSI          ANSI->UTF-16    UTF-16
2B流程C，服务器不支持Unicode，数据在离开服务器之前就乱码了

扯了这么多细节，但如下的问题解决起来其实非常容易……
引用第12楼x3c于2012-02-21 11:29发表的  :
好几年前也在这里问过FlashFXP关于日文里那个点的问题，至今没有解决方法，每次只能上服务器把文件名改了，等文件下来再改回去。马克一下看现在有没有更好的解决方法…… images/back.gif

扔掉那些不支持Unicode的FTP软件，客户端和服务器都要扔
主要黑名单
FlashFXP，全版本，这种破烂也好意思拿出来卖钱
Serv-U，10之前全部
xlight，看上去支持但莫名其妙的问题太多了（也可能走的是2B流程，核心不支持但冒充自己支持）

白名单：
Gene6
IIS FTP
FileZilla Server
FTPRush
FileZilla Client
lftp
FireFTP

：转换成问号是WideCharToMultiByte的默认行为，并不一定会被转换成问号

引用第11楼明日の香于2012-02-21 11:12发表的  :

你吃了枪药了？
又不是跟你说，你胡乱喷啥？ images/back.gif

嘿嘿，不知所以然只会瞎出点子的人也就只有说别人态度不好的本事了  

x3c 发表于 2012-2-23 17:20

感谢LS的大大科普，回头先升Serv-U去……

ov_efly 发表于 2012-2-23 18:02

引用第14楼鸡蛋灌饼于2012-02-21 15:33发表的:
FTP的编码问题——特别是Windows环境——其实很复杂也很头疼，虽然解决方案很简单
至于复杂在哪和简单在哪，看完下面的扯蛋就一目了然了

先从Windows本身开扯（考虑到*nix用户底子都不错在此不予赘述）
Windows系统中字符串所用的编码可以分为两层，一层是内核所用的，此层编码自从Windows 2000之后一直是UTF-16，该编码能支持所有已编码的字符，也不会出现・、♡被变成?这类问题。
....... images/back.gif

windows要是再不废掉ANSI
统一code page
老子真不想用了
老的程序都应该发配给虚拟机

Mr.Hat 发表于 2012-2-24 01:14

回 16楼(ov_efly) 的帖子

既然你觉得老的程序都可以发配给虚拟机，那就意味着你可以脱离他们，你就只装新程序就好了，不是吗。为什么要阻止别人装老程序呢。

烈之斩 发表于 2012-2-24 11:27

太好了 终于找到一起黑FlashFXP的战友了

可惜Ftprush部分功能还是不是太爽，比如目录缓存远不如FXP的好使，以及作者跑路之后2.0之后赶鸭子上架开发出来的多线程下载功能毛病挺多，比不上FZ
再加上不支持ipv6……那就是完美的ftp client了

不过鸡蛋灌饼我觉得你确实吃枪药了…有理不在声高 干嘛老那么爱喷呢

elvis_w 发表于 2012-2-24 11:40

回 9楼(鸡蛋灌饼) 的帖子

你啥环境？Windows? Windows一样可以上SFTP Server啊：http://www.digitalmediaminute.com/article/1487/setting-up-a-sftp-server-on-windows

ov_efly 发表于 2012-2-24 12:11

Re:回 16楼(ov_efly) 的帖子

引用第17楼Mr.Hat于2012-02-24 01:14发表的 回 16楼(ov_efly) 的帖子 :
既然你觉得老的程序都可以发配给虚拟机，那就意味着你可以脱离他们，你就只装新程序就好了，不是吗。为什么要阻止别人装老程序呢。 images/back.gif

都自带XP mode了
哪里算是阻止别人装
好吧
其实我最低的要求就是
@Microsoft 丫的完善65001啊
能作为默认code page

拜拜 发表于 2012-2-24 15:14

对于total commander属于黑名单还是白名单，求指点

烈之斩 发表于 2012-2-24 17:31

total commander 7.5之后（数字不准确）支持unicode吧但是ftp插件没用过 不清楚了

iemari 发表于 2012-2-24 23:09

FZ青路过，ACG用的FTP太棒了
RUSH的脚本功能好还蛮实用的，土鳖用户表示拿来定点刷更新不错


G6也不错，但用着心理作用总感觉性能怪怪的，貌似JShare也用的这个，不过都生存战略了好几月了

服务端的记得还有个很装B貌似很牛X的ioFTPD，好像6.x后号称支持Unicode，不知是软件走了2B还是我自己2B，每次看到腐女们从G6上传了OX物后到了io下的服务端里就成了?   


其实私人搞或啥内部交流的直接选好软件搭配就得了，但是开出去给大众的用的就倍儿有压力了，大学那会最流行的FTP客户端是流氓雷和IE6啊

7pu 发表于 2012-2-24 23:30

dahuatttt 发表于 2012-2-25 01:10

技术贴mark

烈之斩 发表于 2012-2-25 02:27

论进步程度我觉得FZ肯定排的上。我指客户端

我记得2.x年代 这玩意简直是反人类的 3.x好太多了

不过依然操作略反人类 平时下下东西没啥 用来做服务器端整理就显得非常难用

明のｓｋｙ 发表于 2012-4-6 20:43

貌似白名单里面没有一个支持网络映射目录

zatsuza 发表于 2012-4-6 21:00

对于WIN7仍然没有在EXE的PROPERTY PAGE中加入LOCALE我表示很失望

zihexing 发表于 2012-4-6 21:07

引用楼主明のｓｋｙ于2012-02-20 17:23发表的 ftp编码问题 :
用Xlight架设FTP
D.C. ～ダ・カーポ～ 第01話 ｢好きになっちゃダメですか？｣ (DVD 1280x720 x264 AAC rev).mp4

文件名有那个该死的点
用filezilla打开后成了这样，
....... images/back.gif





XLIGHT站点 启用UTF8编码。然后FLASHFXP或者FILEZILLA的站点管理器添加这个站点并设置UTF8编码访问

ayukas 发表于 2012-4-6 22:10

服务端在win下 配起来简单问题少的必然是fz server啊
性能也会不比系统层面的IIS差很多
gene6性能不太好 不过贵在扩展性极佳
这3者看你偏好的特性选择
初级用户fz server 喜欢小折腾一下的用IIS 想自己写扩展折腾的大牛去用gene6

客户端的话fz client没得说 除了不支持fxp外没觉得有什么缺点

明のｓｋｙ 发表于 2012-4-6 23:03

最后IIS 解决了FZ sever g6等等都不支持 网络驱动器映射

烈之斩 发表于 2012-4-7 01:45

fz client操作太屎，不过越来越好是真的

不过它支持脚本么？

查看完整版本: ftp编码问题