FTPClient相关问题。。。
2013-10-30 15:14
162 查看
ftpClient 尽量不要传中文!!!
OutputStream out=ftpClient.storeFileStream("");
近来发现如果是中文名字,out老是为null,折腾了好几个小时。改为英文名字就ok了。
转载http://blog.csdn.net/lyh_927/article/details/4188514
一, 文件名中文乱码问题.
开始知道能用FTPClient的listNames方法得到当前目录下所有文件的列表. 但是发现中文文件名是乱码. 默认情况下FTPClient使用UTF-8字符集作为和服务器通讯的编码集. 而我们的ftp服务器是在中文windowsXP上装的ServU. 所有使用GBK做为通讯编码集. 经过查找api文档, 我看到了setControlEncoding方法, 试了一下,果然好使. 于是这个问题就解决了:
第8行: ftp.setControlEncoding("GBK")
至于conf.setServerLanguageCode("zh")对这个有什么影响,我还没有验证. 但是只有这句是不行的.
二, 传输binary文件, 由于FTPClient默认使用ASCII作为传输模式, 所有不能传输二进制文件. 通过
ftp.setFileType(FTP.BINARY_FILE_TYPE)个可以解决这个问题, 但是要在login以后执行. 因为这个方法要向服务器发送"TYPE I"命令.
开始的时候用的是setFileTransferMode, 不过不好使. 它会执行 MODE I命令, 服务器不接受.
三, 用被动模式传输: ftp.enterLocalPassiveMode()这个到不用在login之后执行, 因为它只改变FTPClient实例的内部属性.
四, 断点续传. 心想应该有支持吧, 于是查API结果找到了setRestartOffset()方法, 试了一下,果真好使. 用RandomAccessFile配合使用, 实现起来还是蛮简单的.[iocblog.net 来源]
五, 只能传一个文件!!
不知道大家有没有遇到这个问题, 传输第一个文件好使, 后面的的retrieveFileStream(name)都是返回null. 这个实在是令人头痛的问题, 难不成要传一个文件重新建立一次连接? 那样也太土了吧. 但是文档里也没有写, 来点狠的,debug它的源码, 看看它究竟做了什么事情. 首先看一下ftp服务器的日志, 发现日志没问题, 过来的命令和reply都是正确的, 但是发现第一个文件以后没有执行RETR命令. 于是跟踪PASV命令的reply代码,发现不是227,而服务器上的日志明明返回的是227.
难道是FTPClient解析Reply出问题了. 进一步跟踪发现了问题, 原来在一个文件传输过程中会产生两个Reply:
150 Opening BINARY mode data connection for a.sql (19890 Bytes).
226 Transfer complete.
而FTPClient 自动消费掉一个,于是解析Reply就发生了错位, 下一个命令的会解析266那条. 接下来的命令都不是解析自己的Reply而是前一次命令的. 所有在PASV命令的Reply码就不对了, FTPClient也就不会执行接下来本应该执行RETR命令.
他不消费,我们来消费吧. 于是在文件传输完成以后, 主动调用一次getReply()把接下来的226消费掉. 这样做是可以解决这个暂时的问题, 但不知道在其他的ftp操作上会不会也有类似的情况. FTPClient这点可做的不大好.
OutputStream out=ftpClient.storeFileStream("");
近来发现如果是中文名字,out老是为null,折腾了好几个小时。改为英文名字就ok了。
转载http://blog.csdn.net/lyh_927/article/details/4188514
一, 文件名中文乱码问题.
开始知道能用FTPClient的listNames方法得到当前目录下所有文件的列表. 但是发现中文文件名是乱码. 默认情况下FTPClient使用UTF-8字符集作为和服务器通讯的编码集. 而我们的ftp服务器是在中文windowsXP上装的ServU. 所有使用GBK做为通讯编码集. 经过查找api文档, 我看到了setControlEncoding方法, 试了一下,果然好使. 于是这个问题就解决了:
第8行: ftp.setControlEncoding("GBK")
至于conf.setServerLanguageCode("zh")对这个有什么影响,我还没有验证. 但是只有这句是不行的.
二, 传输binary文件, 由于FTPClient默认使用ASCII作为传输模式, 所有不能传输二进制文件. 通过
ftp.setFileType(FTP.BINARY_FILE_TYPE)个可以解决这个问题, 但是要在login以后执行. 因为这个方法要向服务器发送"TYPE I"命令.
开始的时候用的是setFileTransferMode, 不过不好使. 它会执行 MODE I命令, 服务器不接受.
三, 用被动模式传输: ftp.enterLocalPassiveMode()这个到不用在login之后执行, 因为它只改变FTPClient实例的内部属性.
四, 断点续传. 心想应该有支持吧, 于是查API结果找到了setRestartOffset()方法, 试了一下,果真好使. 用RandomAccessFile配合使用, 实现起来还是蛮简单的.[iocblog.net 来源]
五, 只能传一个文件!!
不知道大家有没有遇到这个问题, 传输第一个文件好使, 后面的的retrieveFileStream(name)都是返回null. 这个实在是令人头痛的问题, 难不成要传一个文件重新建立一次连接? 那样也太土了吧. 但是文档里也没有写, 来点狠的,debug它的源码, 看看它究竟做了什么事情. 首先看一下ftp服务器的日志, 发现日志没问题, 过来的命令和reply都是正确的, 但是发现第一个文件以后没有执行RETR命令. 于是跟踪PASV命令的reply代码,发现不是227,而服务器上的日志明明返回的是227.
难道是FTPClient解析Reply出问题了. 进一步跟踪发现了问题, 原来在一个文件传输过程中会产生两个Reply:
150 Opening BINARY mode data connection for a.sql (19890 Bytes).
226 Transfer complete.
而FTPClient 自动消费掉一个,于是解析Reply就发生了错位, 下一个命令的会解析266那条. 接下来的命令都不是解析自己的Reply而是前一次命令的. 所有在PASV命令的Reply码就不对了, FTPClient也就不会执行接下来本应该执行RETR命令.
他不消费,我们来消费吧. 于是在文件传输完成以后, 主动调用一次getReply()把接下来的226消费掉. 这样做是可以解决这个暂时的问题, 但不知道在其他的ftp操作上会不会也有类似的情况. FTPClient这点可做的不大好.
相关文章推荐
- FTPClient 相关问题
- WCF Host,Client配置相关问题
- 使用Apache 的 FTP Client获取FTP服务器上的文件列表FTP response 421 received.Server closed connection问题的解决
- FTPClient.listFiles()或者FTPClient.retrieveFile()卡死不执行不报错问题
- FTPClient调用retrieveFileStream导致线程挂起(防火墙问题)
- 解决FTPClient linux 下载文件小于实际文件,线程挂起等问题
- FtpClient中文乱码问题解决
- sun.net.ftp.FtpClient 上传文件和文件夹应用(改变相关文件中的内容)
- 使用sun.net.ftp.FtpClient进行上传功能开发,在jdk1.7上不适用问题的解决
- 关于使用FtpClient deleteFile 删除文件时删除不了问题解决
- 关于FTPClient操作文件后无法变更目录的问题。
- 【转】WCF Host,Client,Endpoint配置相关问题
- 谈谈VxWorks下FTP Server不能被普通Windows FTP Client访问的问题
- WebService:Java client + .NET WSE 2.0 相关问题解决方案
- 关于用FTPClient资源库上传下载以中文命名的文件的问题
- Apache FTPClient上传文件时的问题及解决
- c/s程序版本自动升级的问题,如何判断client端版本号是否最新,然后从指定ftp服务器down
- hadoop 相关问题: put命令报错WARN hdfs.DFSClient: DataStreamer Exception
- 搞定GridFTPClient中的list问题