问题
The files downloaded by this, are nearly the same size but differ in some lines. Every answer points to binary file type. But this won't help. Got anybody an idea for the problem (transferring PDF)?
FTPClient ftpClient = new FTPClient();
OutputStream outputStream = null;
boolean resultOk = true;
try {
ftpClient.connect(host, port);
ftpClient.enterLocalPassiveMode();
ftpClient.setFileTransferMode(FTP.COMPRESSED_TRANSFER_MODE);
ftpClient.setFileType(FTP.BINARY_FILE_TYPE);
if (showMessages) {
System.out.println(ftpClient.getReplyString());
}
resultOk &= ftpClient.login(usr, pwd);
if (showMessages) {
System.out.println(ftpClient.getReplyString());
}
outputStream = new FileOutputStream(localResultFile);
resultOk &= ftpClient.retrieveFile(remoteSourceFile, outputStream);
outputStream.flush();
outputStream.close();
if (showMessages) {
System.out.println(ftpClient.getReplyString());
}
if (resultOk == true) {
resultOk &= ftpClient.deleteFile(remoteSourceFile);
}
resultOk &= ftpClient.logout();
if (showMessages) {
System.out.println(ftpClient.getReplyString());
}
} finally {
ftpClient.disconnect();
}
回答1:
It's clear from the files you have shared, that the transfer indeed happened in text/ascii mode.
While probably not required by FTP specification, with some FTP servers (e.g. FileZilla server), you cannot change transfer type before logging in. But servers like IIS, ProFTPD or vsftpd have no problem with that. On the other hand FileZilla server defaults to binary mode anyway (what is another violation of the specification), so you are probably using yet another one.
In any case, move the .setFileType
call after .login
. And test its return value.
And remove the .setFileTransferMode
call. It does not do any harm with most servers, as hardly any server support MODE C
, hence the call is ignored anyway. But if you encounter a server that does, it would break the transfer, as FTPClient
actually does not support it.
回答2:
It seems to happen when using unescaped paths that contain spaces. E.g. C:/Documents and Settings/test
Got it solved now by using a escaped path for the spaces. Thanks for your help
回答3:
While my problem was related to corruption of the upload, I resolved similar issue by moving the set of file type after ftp login (I dont use transfer mode leaving it to its default value):
resultOk &= ftpClient.login(usr, pwd);
ftpClient.setFileType(FTP.BINARY_FILE_TYPE);
I saw in some forums that setting binary file type before invoking login method, could lead to problems in transfer. Before this change, PDF file get downloaded but show corrupted fonts and elements. Now it works. Hope it may helps someone.
来源:https://stackoverflow.com/questions/49990280/ftp-file-corrupt-after-download-with-apache-commons-net