Overview
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 (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 GET command.
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 will involve a file with a binary data type and 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. We had a problem earlier because I 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. So there's usually no need to issue the binary command if you download an image file. So why 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. In general, 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 aren't supported. These text files are exceptions and should be transferred using binary mode.
So, in addition to plain text files (files with the .txt extension), HTML files, CGI scripts, cascading style sheet files, and javascript files also fall under this classification. Some of the file extensions that likewise fall under this classification include .html, .php, .cgi, .js, .txt, and .css.
Ready to See for Yourself?
Interested in a file transfer solution that intelligently handles different file types and transfer modes? Schedule your free demo today and let us show you how!
But why is it necessary to use the ASCII transfer mode?
This is due to the way end-of-lines (EOLs) are handled. In FTP, EOLs in ASCII files (ex., 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 systems like Linux, FreeBSD, AIX, and Mac OS X don't. These systems only use LF for line endings. Some archaic systems used only CR, like the Commodore 8-bit machines, Mac OS up to version 9, and Acorn BBC.
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. If 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 the image file got corrupted after the download in the example. Binary files can get corrupted even if 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 some text files do 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 can now detect 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 be helpful.
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.
Get Your Free Trial
Would you like to try this yourself? JSCAPE MFT Server is platform-agnostic and can be installed on Microsoft Windows, Linux, Mac OS X, and Solaris. It can handle any file transfer protocol as well as multiple protocols from a single server. Additionally, JSCAPE enables you to handle any file type, including batch files and XML. Download your free 7-day trial of JSCAPE MFT Server now.
Related Content
Active vs. Passive FTP Simplified: Understanding FTP Ports
How To Protect FTP Passwords From Brute Force Attacks