服务器FTP传中文文件名出现乱码或传输失败，核心原因在于FTP协议默认使用ASCII字符集，而中文属于多字节字符，需要客户端和服务端统一使用UTF-8编码（即UTF-8模式），并确保两端字符集设置一致。
乱码根源：FTP协议与中文编码的冲突
FTP协议诞生于二十世纪七十年代,最初设计时只考虑英文和ASCII字符，中文文件名占2到3个字节，当客户端使用本地编码（如GBK）发送文件名，而服务器端却按ISO-8859-1或UTF-8解析时，字节序列被错误映射，于是出现”锟斤拷””烫烫烫”这类经典乱码。
行业共识认为,目前FTP传输中文文件名主要有两条路：一是让服务器和客户端都切换到UTF-8编码，这是现代FTP服务器的标准做法；二是让服务器保持传统的GBK编码，客户端也强制使用GBK，但这种方式兼容性较差，仅适用于老式系统。
服务器端的编码配置方案
不同FTP服务器软件对中文文件名的处理方式不同,下面按主流服务器类型分别说明。
vsftpd（Linux常用）：vsftpd从2.3.5版本开始支持UTF-8，但默认不强制开启，修改配置文件/etc/vsftpd.conf，添加或修改以下参数：
utf8_enable=YES
设定后重启服务：
systemctl restart vsftpd
注意,这个参数只影响文件名编码的显示，不会转换已有的文件名，如果服务器上已经存在GBK编码的文件名，需要先转换文件名编码，再用FTP访问。
ProFTPD：在/etc/proftpd/proftpd.conf中设置：
UseEncoding UTF-8 UTF-8
这个指令的作用是让ProFTPD内部统一使用UTF-8处理文件名，同时要求客户端也用UTF-8传输。
Windows IIS FTP：IIS 7及以上版本在FTP服务的”高级设置”中有UTF-8选项，勾选”允许使用UTF-8″后，客户端需配合使用UTF-8模式登录，但实际测试中，IIS对UTF-8的支持并不完美，部分版本在文件夹名称层级较深时仍会出现乱码。
Serv-U：域属性->FTP设置->编码选项中，选择”UTF-8编码”或”自动检测”，业内专家指出，Serv-U的自动检测模式在混合编码环境下表现一般，建议手动固定为UTF-8。
客户端强制UTF-8模式的方法
服务器端配置好UTF-8后，客户端还需要在连接时发送OPTS UTF-8 ON命令，多数现代FTP客户端默认会发送这一命令，但部分老式客户端需要手动设置。
| 客户端 | 设置路径 | 备注 |
|---|---|---|
| FileZilla | 站点管理器->字符集->使用自定义字符集->UTF-8 | 新版默认自动检测，老版本需手动选 |
| FlashFXP | 站点管理器->选项->编码->UTF-8 | 连接前设置，连接后改无效 |
| CuteFTP | 全局选项->传输->文本传输->编码 | 选择UTF-8，同时将创建名称编码设为UTF-8 |
| WinSCP | 会话设置->环境->文件名UTF-8 | 需要在新建会话时点”高级”展开设置 |
以FileZilla为例,一个完整可验证的操作路径是：
- 打开站点管理器,新建站点。
- 主机填服务器IP,协议选FTP（或SFTP，如果服务器支持）。
- 传输设置中”字符集”选择”强制使用UTF-8″。
- 连接后,在服务器面板中右键点击目录，选择”手动输入文件名”，输入中文进行测试。
如果连接后服务器目录中的中文仍然乱码,常见原因是服务器端文件名本身的字节就是GBK编码，而FTP服务端只按UTF-8输出，此时需要反过来，客户端也选择GBK编码（如FileZilla字符集选”使用自定义编码”填入GBK），两者匹配后乱码即消失。
搭建支持中文文件名的FTP服务器实操
与其在乱码问题上反复折腾,不如从源头搭建一个对中文友好的FTP服务器，下面给出一个基于Linux + vsftpd + UTF-8的完整配置流程，可作为新服务器的参考。
检查当前系统默认字符集
登录Linux服务器后,先执行：
locale
如果输出显示LANG=en_US.UTF-8或LANG=zh_CN.UTF-8，系统层面就是UTF-8，如果显示POSIX或空值，需要先设置：
export LANG=en_US.UTF-8
并把export LANG=en_US.UTF-8写入/etc/profile，让所有用户登录时自动生效。
上传已有中文文件名文件后的处理技巧
如果服务器上已经有一批GBK编码的中文文件名,而FTP服务已改为UTF-8，访问时会出现乱码，这时可以批量转换文件名编码。
使用convmv工具（Linux）转换：
convmv -f GBK -t UTF-8 --notest ./
这条命令会将当前目录下所有文件名从GBK转换为UTF-8，执行前建议先不加--notest预览效果，转换完成后，再通过FTP访问，中文文件名就能正常显示了。
另一种思路是写一个FTP脚本自动下载乱码文件再改名,例如使用lftp工具，先以UTF-8模式连接，对乱码的目录使用z命令手动设置编码：
set ftp:charset = GBK
这行命令告诉lftp服务器端使用GBK编码,而客户端本地使用UTF-8显示，通过这种方式，即使服务器没有统一到UTF-8，客户端也能正确显示中文。
新服务器部署建议
对于尚未部署FTP的服务器,建议直接选用支持UTF-8的服务端，并在系统层面固定UTF-8，具体步骤：
- 安装vsftpd：
apt install vsftpd或yum install vsftpd。 - 修改配置：将
utf8_enable=YES加入配置文件，同时设置local_root指向一个共享目录。 - 创建具有正常中文权限的系统账户,或启用虚拟用户。
- 测试：从Windows本地使用FileZilla连接，上传一个中文名文件，再下载回来，对比文件名是否一致。
按照上述流程,绝大多数场景下中文文件名可以正确传输，但在少数配合NAS设备或嵌入式系统的FTP服务中，由于固件本身不支持UTF-8，仍需将编码设置为GBK，这种非标准场景需要单独维护。
中文文件名传输失败的隐蔽原因与排查方法
有时编码设置完全正确,中文文件名仍然传不上去，这类问题往往不是编码问题，而是FTP命令通道或防火墙策略导致。
文件名中带有特殊字符
FTP协议对文件名中的部分字符有特殊语义,
- 空格：部分服务端支持，但某些脚本化FTP客户端会截断。
- 括号、方括号：在通配符解析时可能被误处理。
- 以点开头的隐藏文件：默认配置下可能被过滤。
- 全角字符与半角字符混写：如果文件名中有全角空格或全角括号，部分服务端无法正确解析。
对于这类情况,建议将文件名中的空格、括号改为下划线，或使用百分号编码方式，这是行业内的常见做法。
被动模式与NAT网关的影响
FTP传输有主动模式和被动模式,在被动模式下，服务器会开放一个动态端口，客户端连接该端口进行数据传输，如果服务器位于NAT网关之后，数据端口无法正确映射，文件传输会在写文件名阶段中断，表现为”连接超时”或”写文件失败”。
排查方法很简单：用FileZilla连接后，查看消息日志中的PASV或EPSV命令响应，如果看到类似227 Entering Passive Mode (192,168,1,100,m,n)这样的地址，并且IP地址是内网地址，说明服务端未正确设置被动地址，此时需要在vsftpd配置中指定公网IP：
pasv_address=你的公网IP pasz_min_port=40000 pasv_max_port=50000
同时开放防火墙中的端口范围,经过这一步，大部分”传中文文件名失败”的案例其实是因为被动模式数据连接中断，而非文件名编码问题。
文件权限与所有权
即使编码正确、连接正常，如果FTP用户对目标目录没有写权限，客户端会报”550 Permission denied”，导致看似是中文文件名的故障，检查服务器端目录权限时，确认FTP用户对目录有
r和w权限：
ls -ld /srv/ftp/upload
输出应包含drwxrwxr-x或更高权限，如果权限不足，执行：
chown ftpuser:ftpgroup /srv/ftp/upload chmod 775 /srv/ftp/upload
做完这些,中文文件名通常能正常写入。
常见问题解答
为什么我用FileZilla上传中文文件名到服务器后，在服务器本地看是乱码，但在其他电脑通过FTP下载又正常？
这种情况说明服务器本地系统无法正确显示FTP写入的中文文件名,但传输链路是UTF-8一致的，服务器本地乱码的原因可能是操作系统的终端或文件管理器没有使用UTF-8解码文件名，比如Windows服务器上通过资源管理器查看vsftpd写入的文件，如果系统区域设置是GBK，就会显示乱码，解决办法是调整服务器操作系统的非Unicode程序语言设置，或者改用支持UTF-8的文件管理器（如MobaXterm）查看。
FTP传输中文文件名时，哪种客户端兼容性最好？
按照实际使用反馈,FileZilla是兼容性较好的免费客户端，它支持自动检测服务端编码，也能手动覆盖字符集设置，不过在处理老式FTP服务器（只支持GBK）时，WinSCP表现更稳定，因为它可以在会话中切换服务器字符集，且切换后无需重连，对于企业批量传输场景，不少运维人员倾向于使用lftp命令行工具，因为可以在脚本中显式设置set ftp:charset，完全可控，综合来看，没有一款客户端能解决所有编码问题，关键是服务器端编码与客户端设置形成一对匹配关系。
中文文件名在FTP传输过程中被截断为短文件名是怎么回事？
这类现象多见于Windows IIS FTP服务器，且服务器开启了”8.3短文件名生成”机制，当中文文件名较长时，FTP服务自动生成短文件名并覆盖传输请求，导致实际存储的文件名变成类似~1.TMP这样的格式，要解决这个问题，在IIS的FTP站点高级设置中，找到”允许UTF-8″并启用，同时确保客户端的FTP软件也声明UTF-8支持，如果仍被截断，检查服务器磁盘分区格式是否为NTFS，FAT32分区不支持部分UTF-8字符，需要在命令行中执行convert d: /fs:ntfs转换分区格式。
服务器FTP传中文文件名的核心结论始终是：让两端字符集相同，要么统一用UTF-8，要么统一用GBK，并在防火墙和权限层面排除干扰，掌握了编码切换和被动模式配置这两个关键点，中文文件名传输就不再是难事。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8ftp%e4%bc%a0%e4%b8%ad%e6%96%87%e6%96%87%e4%bb%b6%e5%90%8d%e4%b9%b1%e7%a0%81%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%8c%e6%80%8e%e4%b9%88%e8%a7%a3%e5%86%b3%ef%bc%9f/
