Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Application Layer Protocols, Services and Applications (OSI Layers 5, 6 and 7)       9  TCP/IP Key Applications and Application Protocols            9  TCP/IP File and Message Transfer Applications and Protocols (FTP, TFTP, Electronic Mail, USENET, HTTP/WWW, Gopher)                 9  TCP/IP General File Transfer Protocols (FTP and TFTP)                      9  File Transfer Protocol (FTP)                           9  FTP Concepts and General Operation

FTP General Data Communication and Transmission Modes 1 2 3 FTP Commands and Replies

The most general way of designing the File Transfer Protocol would have been to make it treat all files as “black boxes”. The file would be represented as just as a set of bytes. FTP would pay no attention to what the file contained, and would simply move the file, one byte at a time, from one place to another. In this, it would seem to be very similar to the “copy” command that is implemented on most file systems, which likewise creates a copy without looking into the file to see what it contains.

So what would be the problem with that, you may wonder? Well, for some types of files, this is exactly what we want, but for others, it introduces a problem. The reason is that certain types of files use different representations on different systems. If you copy a file from one place to another on the same computer using a “copy” command, there is no problem: the same representation for files is used everywhere within that computer. But when you copy it to a computer that uses a different representation, however, you may encounter difficulties.

The most common example of this is a type of file that may surprise you: simple text files. All ASCII text files use the ASCII character set, but they differ in the control characters used to mark the end of a line of text. On UNIX, a line feed (LF) character is used; on Apple computers, a carriage return (CR); and Windows machines used both (CR+LF).

If you move a text file from one type of system to another using regular FTP, the data will all get moved exactly as it was. Moving a text file from a UNIX system to a PC as just a set of bytes would mean programs would not properly recognize end of line markers. Avoiding this predicament requires that FTP move past the idea that “all files are just bytes” and incorporate some intelligence to handle different types of files. The FTP standard recognizes this by allowing the specification of certain details about the file's internal representation prior to transfer.

The first piece of information that can be given about a file is its data type, which dictates the overall representation of the file. There are four different data types specified in the FTP standard:

• ASCII: Defines an ASCII text file, with lines marked by some sort of end-of-line marker as described above.
  
  
• EBCDIC: Conceptually the same as the ASCII type, but for files using IBM's EBCDIC character set.
  
  
• Image: The file has no formal internal structure and is sent one byte at a time without any processing; this is the “black box” mode I mentioned above.
  
  
• Local: This data type is used to handle files that may store data in logical bytes containing a number of bits other than 8. Specifying this type along with the way the data is structured allows the data to be stored on the destination system in a manner consistent with its local representation.

In practice, the two data types most often used are ASCII and image. The ASCII type is used for text files, and allows them to be moved between systems with line-end codes converted automatically. The Image type is used for generic binary files, such as graphical images, ZIP files and other data that is represented in a universal manner. It is also often called the binary type for that reason.

FTP General Data Communication and Transmission Modes 1 2 3 FTP Commands and Replies