That is most likely the problem.
The default mode for FTP is ASCII. That means it is in the mode to transfer text files. Text files differ based on the OS. With a Linux/UNIX system, new lines are delimited by an ASCII charater of Hex 10 aka LF aka Line Feed. Windows uses a Hex 13 + Hex 10 aka CRLF aka Carriage Return + Line Feed.
The problem is that when you transfer binary files .DOC, .ZIP, .RAR, etc between two disparate systems without specifying BINARY format, the FTP protocol will attempt to translate the file to the format of the desintation machine. That means if it is transferring a file from UNIX to Windows anytime it sees a Line Feed it will replace it with a carriage return + line feed. That is unless you specify to transfer in BINARY format first.
It gets even weirder when going from mainframe (EBCDIC) to UNIX or Windows, especially if there is PACK data (compressed) in the file.
If the file is still available at the source, use the BIN command prior to the GET command.
The BIN or IMAGE (both are used interchangebly) command tells FTP not to do a darn thing to the file, just send as is.
It is very hard (almost impossible) to repair a binary file once it has been "fixed" by FTP. Since binary files can have a LF or CRLF pretty much in any location trying to switch them back will fix some areas of memory but break others. The only fix is to retransfer the file in binary format form the source. Otherwise, I can attempt to reverse what FTP did. But I am not confident that will fix the issue.