Apache Commons FTPClient未从源文件中检索所有字节[重复]

Posted 2023-03-28

【中文标题】Apache Commons FTPClient未从源文件中检索所有字节[重复]

【英文标题】：Apache Commons FTPClient Not Retrieving All Bytes From Source File [duplicate]

【发布时间】：2022-01-20 12:22:10

【问题描述】：

我有一个相当基本的3.8.0 FTPClient 用例：

FTPClient ftpClient = new FTPClient()

ftpClient.connect(hostName, hostPort)

if(FTPReply.isPositiveCompletion(ftpClient.getReplyCode())) 
  ftpClient.setFileType(FTP.BINARY_FILE_TYPE)
  ftpClient.login(userName, password)

  FileOutputStream fos = new FileOutputStream("localFile.txt")

  ftpClient.retrieve("remoteFile.zip", fos)

我遇到的问题是生成的本地文件总是比远程源文件小 ~1400 字节：

source file size: 134,914,722
dest file size:   134,913,316

这似乎不是服务器问题，因为标准 linux ftp 命令会检索整个文件。

它似乎也与OutputStream 无关，因为我在将文件内容拉入内存时遇到了同样的问题：

//still too small
Byte[] fileContents = ftpClient.retrieveFileStream("remoteFile.zip").readAllBytes()

什么会导致 apache commons FTPClient 允许连接和文件下载，但不能从源文件中彻底检索所有字节？

提前感谢您的考虑和回复。

【参考方案1】：

问题在于setFileType 的排序；它应该在login 之后而不是之前。

ftpClient.connect(...

ftpClient.login(...

ftpClient.setFileType(FTP.BINARY_FILE_TYPE)

文件变小可能是由于原始 zip 文件的字符集解释。

【讨论】：

确实，登录后需要选择模式。 ASCII 模式基本上解释接收端系统，然后根据接收端的偏好（LF/CRLF/CR）转换行尾。因此使用 ASCII 模式，例如。使用 ZIP 文件可能会导致文件损坏。 BINARY 模式传输，无需对内容进行任何修改。

您也可以在登录后的任何时候更改为模式，例如。在同一会话中将“test.txt”作为 ASCII 上传，然后将“mydoc.pdf”作为 BINARY 上传。