What's the point of ASCII mode in FTP?

Question

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?

Answer 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.

Answer 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

Answer 3

You have to understand that FTP is a very old protocol. The current version, RFC959, dates back to 1985; earlier versions were defined by RFC765 in 1980, and RFC114 all the way back in 1971. The Internet was a very different place back then. Nowadays it is dominated by Windows and various Unix-like systems (Linux, Android, macOS, iOS, etc); back then there were a great many mainframe and minicomputer systems, many of which did things – even quite basic things like how files were stored – very differently from how Windows and Unix-like systems do things – mainframes and minicomputers are still around on the Internet, but they've gone from being a significant minority, maybe even at some points a majority, to being a minuscule one. FTP has lots of features which made sense in the environment in which it originally developed, but which make far less sense today. The "ASCII mode" of which you speak is one of those; there are quite a few more, most of which are rarely implemented.

"ASCII mode" is a misnomer, albeit a very common one – the FTP protocol standard actually speaks of TYPEs – ASCII (A), EBCDIC (E), IMAGE (I), and LOCAL BYTE (L n). The term "mode" strictly speaking refers to the three transfer MODEs – STREAM (S), BLOCK (B) and COMPRESSED (C). FTP clients and servers on Windows and Unix-like platforms only implement STREAM mode; BLOCK (and more rarely COMPRESSED) mode is used to transfer record-oriented files on mainframe and minicomputer systems. While Unix and Windows store text files as a stream of bytes with line terminators (whether plain LF or CRLF), many mainframe or minicomputer systems store each line as a flat-file database record, either with each line being fixed-length (80 bytes padded with spaces is a common choice) or else with each line prefixed by a length byte. Block mode transmits files with record boundaries marked out-of-band, which works really well with those mainframe/minicomputer filesystems.

Back in the 1970s and 1980s, FTP was heavily used to transfer text files between sites. Plain text was popular as a lowest common denominator format which was easily transferable between systems. One of the major use cases for FTP in the beginning was to transport email; it was only later that SMTP was invented and took over that task from FTP. IBM mainframes and minicomputers were quite common, which natively spoke EBCDIC, so putting ASCII-EBCDIC conversion into FTP clients/servers made sense in that context. In fact, FTP clients and servers for IBM mainframe operating systems (z/OS, z/VSE, z/TPF) and IBM's minicomputer operating system (IBM i, formerly known as OS/400) still have this ASCII-EBCDIC support built-in. But today, when the average Internet user no longer has any interaction with EBCDIC-based mainframes or minicomputers, having ASCII-EBCDIC conversion support in the protocol has less relevance.

You also have to realise that we didn't always use 8-bit bytes. In the early years of the computing industry (1950s, early 1960s), there was a lot of debate about what size the byte should be, and 6 bit bytes and 9 bit bytes were both quite common choices. It was only with the introduction of the IBM System/360 mainframe line in the mid-1960s that the industry began to standardise on the 8-bit byte; but, still, in the 1970s and even early 1980s machines which didn't use the 8-bit byte, such as Unisys mainframes and DEC PDP-10s, were still reasonably common. Indeed, the later were heavily used on the early Internet, which is why the FTP protocol has special support for their file transfer needs. "TYPE L n" can be used to transfer a file composed of bytes which are not 8 bits long. It was commonly used to transfer files between PDP-10s by setting "TYPE L 36", to transfer files in 36-bit words (composed of six 6-bit bytes, or 4 9-bit bytes, or 5 7-bit bytes with a padding bit). FTP client/servers running on 8-bit byte machines (Windows, Unix-likes, even IBM mainframes and minicomputers) generally don't implement this, except that they often support "TYPE L 8" as a synonym for "TYPE I" (IMAGE). IMAGE type is based on sending arbitrary binary data in 8-bit bytes, which is what most people know as "binary mode" FTP.

TYPE A and TYPE E both support three subtypes, known as formats – non-print (TYPE A N, TYPE E N), TELNET (TYPE A T, TYPE E T), ASA (TYPE A A, TYPE E A). Mainframe line printers had some primitive control of formatting called "carriage control", and this actually declares how that carriage control information is encoded in the file. Most FTP clients/servers today only support non-print (TYPE A N, TYPE E N), which declares that the carriage control information is missing.

Anyway, all these complex features exist in the FTP protocol, but they made a lot of sense decades ago when they were invented, and some of them are still used today by the small minority of users who still work with mainframes or minicomputers. Most FTP clients/servers on Unix/Windows now default to TYPE I instead of TYPE A, which avoids most of the old problems with binary files being corrupted by ASCII transmission. It might even make sense, if one was writing an FTP client/server, to remove TYPE A entirely. But still there are some rare cases when "TYPE A" can be useful for some people. Suppose you want to download a text file from an IBM mainframe FTP server; if you specify "TYPE A", you'll get the file in ASCII, if you specify "TYPE I", you'll probably get it in EBCDIC. Now converting EBCDIC to ASCII yourself isn't that hard, but if you don't know how to do it, you can just use "TYPE A" and the FTP server will do it for you (and it might even do a slightly better job, in that it quite possibly knows which particular EBCDIC code page is being used, whereas people often screw up EBCDIC-to-ASCII conversion by using the wrong EBCDIC code page.)

Answer 4

I think it's just because it sometimes is convenient. Back in the day when FTP was how you got files from one system to the next, it was a big timesaver -- you didn't have to know what the system was on the other end in order to have a readable text file.

But yeah, mostly it's just a nuisance today. Just a corrupt-o-matic machine for the uninitiated!

Answer 5

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.

Answer 6

ASCII mode is used so that the software can automatically change EOL characters to the proper values for the client/server depending on if you are uploading/downloading. If you are uploading to the same type of system as you are using, there is no difference in these modes.

The reason for this mode though is because not all software on all systems will correctly handle EOL's that aren't the exact proper type of EOL (for instance, alot of Windows software will only handle "\r\n" properly and will balk something horrible on "\n").