What's the point of ASCII mode in FTP?

Why is there an ASCII mode in FTP, which is prevalent in today's software and FTP implementations? Why not just always use binary regardless of the data?

Solution 1:

When in doubt, read the RFC:

File-structure is the default to be assumed if the STRUcture command has not been used but both file and record structures must be accepted for "text" files (i.e., files with TYPE ASCII or EBCDIC) by all FTP implementations. The structure of a file will affect both the transfer mode of a file (see the Section on Transmission Modes) and the interpretation and storage of the file.

The "natural" structure of a file will depend on which host stores the file. A source-code file will usually be stored on an IBM Mainframe in fixed length records but on a DEC TOPS-20 as a stream of characters partitioned into lines, for example by <CRLF>. If the transfer of files between such disparate sites is to be useful, there must be some way for one site to recognize the other's assumptions about the file.

etc etc ... In short, it is to ensure that text representations in one encoding got converted properly when transferred to hosts using a different encoding.

Solution 2:

Because different operating systems (Windows, UNIX, VAX) use different line ending methods for simple text files.

Windows (DOS) uses a CR/LF pair, UNIX uses only one of them. ASCII mode converts CRLF pairs and BIN mode doesn't.

Ron

Solution 3:

ASCII mode had its place back in the day when character and EOL encoding was a real problem, but I would like to see ftp clients remove or perhaps just hide this option today. Nowdays it's mostly just EOL conventions that get messed up between systems, but I've found most decent text editors don't care anymore anyway. So in order to avoid corrupting binary files (or even some text based ones), I recommend just using binary mode for everything.