Are you receiving corrupt files during FTP transfers? It might simply be due to an incorrect data type setting. In this post, we help you understand the nuances and differences between FTP binary and ASCII data types (a.k.a. transfer modes) so you can avoid these issues.
Let's begin our discussion with an example of using binary vs. ASCII.
Using FTP binary or image type
Let's download an image file named firefox.jpg using the FTP
Notice how the download proceeds without any issues. However, when you try to open the file, that's when you'll see the problem.
Here's what happens when we try to open the file using the Linux gThumb application.
You can see it only shows the JPEG icon instead of the image itself.
Now, here's what we see when we try to load the image using the Image Viewer. Clearly, there's something wrong with the file.
Let's do that again. This time, let's issue the
Binary command before executing the
Get command. The actual command that's sent to the server is
TYPE I, where I stands for Image. Image mode and Binary mode mean the same thing in FTP. This command tells the server that the transfer is going to involve a file with a binary data type and hence to prepare for a binary mode transfer.
The download proceeds as before. But now, when we try to open the file using the gThumb application, we can now see the actual image.
The same thing happens when we load the image file using the Image Viewer.
This worked because an image file requires an image or binary transfer mode, which transfers files as is. The reason why we had a problem earlier was because I actually issued the ascii command (not shown in the screenshot) before downloading the file. This executes the
TYPE A command, where A stands for ASCII, and sets the transfer mode to ASCII. More about ASCII shortly.
Image files aren't the only files that should be transferred using image mode. Other files that need to be downloaded using the binary transfer type include:
- image files (e.g. .jpg, .bmp, .png)
- sound files (e.g. .mp3, .avi, .wma)
- video files (eg. .flv, .mkv, .mov, .mp4),
- archive files (e.g. .zip, .rar, .tar)
- other files (e.g. .exe, .doc, .xls, .pdf, etc.)
Most popular FTP clients (the BSD command line client included) already use the binary or image type by default. Hence, there's usually no need to issue the binary command if you download an image file. So why then would you need the ASCII transfer type?
When to use FTP ASCII transfer mode
ASCII data type or transfer mode is recommended if you want to transfer text files. Generally speaking, files whose contents can be read using a simple text editor like Notepad, nano, or pico are considered text files.
Note: Some text files, like those using UTF-8 character encoding, may contain characters not supported by ASCII. For example, Japanese, Chinese or Korean characters. These text files are exceptions and should be transferred using binary mode.
But why is it necessary to use the ASCII transfer mode?
The answer partly lies in the way end-of-lines (EOLs) are handled. In FTP, EOLs in ASCII files (a.k.a. text files) are denoted by carriage return+line feed (CRLF) pairs (see RFC959). The thing is, not all platforms use CRLF for end-of-lines.
While Microsoft Windows does use CRLF, UNIX-based systems like Linux, FreeBSD, AIX, and Mac OS X don't. These systems only use LF for line endings. Some archaic systems, like the Commodore 8-bit machines, Mac OS up to version 9, and Acorn BBC, used only CR.
So, in order for text files to be usable upon arrival at their destination platform, changes have to be made to line endings.
If the sending platform is Windows and the receiving platform is Linux, then the sender won't have to make any changes. However, the receiver would have to remove the CRs. On the other hand, if it's the other way around, i.e. the sender is on Linux and the receiver is on Windows, the sender would have to add CRs and the receiver wouldn't have to do anything.
When you issue an ASCII command, each sender (whether the FTP client or server) will have to make the necessary changes.
Incidentally, these changes involving CRs and LFs aren't suitable for binary files. That's the reason why our image file got corrupted after the download in the example. In fact, binary files can get corrupted even if both the client and server are running on either Linux, Mac OS X, or some other platform that automatically adds/removes CRs or LFs to line endings.
While there are some text files that do just fine when transferred using binary mode, there are those that really require ASCII mode. Scripts, for instance, can cause problems when transferred in binary.
Some FTP clients are now capable of detecting the type of file to be transferred and automatically set the transfer mode accordingly. But if you're using a client that doesn't have that capability but supports a manual method of setting the transfer mode, what you've learned today should come in handy.
But what if the client doesn't issue a TYPE command to specify the data type? Some servers, like JSCAPE MFT Server allow you to set a default transfer mode.
This is the transfer mode the server will use in the event no TYPE command is issued by the client.
In addition to FTP, JSCAPE MFT Server also supports FTPS, SFTP, HTTP, HTTPS, AS2, OFTP, and other file transfer protocols. To try a fully-functional, evaluation edition of JSCAPE MFT Server, click the download button below.