You are here: Home > Knowledge Refreshers

KR edition 180 to 182

KR-180 : ASCII & BINARY - I

Recently during a session on FTP a question was posed to the audience "What is the difference between ASCII and BINARY transfer?"; we come across this frequently in programming and also during FTP. Ever wondered about the two?

Generally when transferring files we can specify the type of transfer - ASCII or BINARY format.

For example in FTP by default the transfer mode is ASCII; to do a binary transfer we should give the command:

BINARY at the ftp prompt.

To check what is the type of transfer currently set in the FTP session, just give the command TYPE and the ftp server will respond saying what transfer type is currently set.

So why do we have 2 different types? Let's take the case of binary (which is simpler to explain!)....

BINARY TRANSFER:

Everything on the PC is stored in terms of bits. So when we transfer in binary mode the bits are copied as such to the receiving PC. If the server has a file which contains the following byte -  1100 0001, then when this is transferred to another PC in binary format, the file at the client end will also contain 1100 0001.

i.e. binary transfer means a bit by bit replica of the original file. No conversions or additional bits are added.

So what about ASCII? More on that in the next edition...

KR-181 : ASCII & BINARY - II

What is ASCII?

  • ASCII is a coding methodology which uses only 7 bits in a byte. The 8th bit is always 0 in ASCII. 

  • In the olden days when transferring data since technology wasn't as advanced it used to take longer to transmit data; so by specifying ASCII one could ask for transmission of only 7 bits in every byte (leading to lesser number of bits being transferred without the loss of data); of course if the file didn't use ASCII coding but used someother format which uses the 8th bit then transferring in ASCII would lead to loss of data. 

  • So the person transferring would have to be sure that the original file itself was in ASCII format. For example pictures, program load modules, executables etc. make use of all 8 bits in a byte. 

  • But nowadays transferring data is much faster than in the good old days and hence reducing 1 bit in every byte doesn't really decrease transmission time by that much. So nowadays the difference isn't about speed.

What's the difference then?

  • Let's say we have a file in mainframes which contains the letter A (LRECL=1, FB file). 

  • Mainframes uses EBCDIC coding; so A is actually HEX C1 or binary 1100 0001. 

  • When we transfer this file to the PC, we would like to see the letter A appear in notepad because that is what we typed in mainframes. 

  • If we did a binary transfer then on our PC (let's say we use WINDOWS OS), the text file would contain the binary 1100 0001 which equals decimal 193. 

  • Now notepad will apply ASCII decoding to display the equivalent character for 193 on screen. But 193 isn't A in ascii! 97 is the code for "A" in ascii. 

  • So what we get on screen is some junk character which maps to 193 in ascii.

What if we want to get the "A" to be displayed on our Windows system as well? That's where the ASCII option comes to our resuce. More on that tomm.......

KR-182 : ASCII & BINARY - III

The concluding edition on types of FTP transfers: BINARY and ASCII.

  • In the earlier edition we saw that if we FTPed a file containing the letter "A" (typed in mainframes) to a windows system and opened it in notepad we get junk (because the ASCII and EBCDIC character to number mappings are different). "A" is 193 in EBCDIC and is 41 in ASCI 

  • So when we did a binary transfer, we received the file on the windows system with value 193 and when ASCII decoding was applied on this a junk character was displayed on the screen. 

  • Now what we actually need is for someone to say that 193 in EBCDIC is the same as 41 in ASCII; or in other words, 193 EBCDIC = 41 ASCII. Who does this? The FTP server and client take care of this. They ensure that when an ASCII type transfer is done, the data is converted into that required by the receiving system

  • Recap: There are 2 ways to FTP a file: binary or ascii. 

  • Binary implies as-is transmission of data (no conversions involved) 

  • ASCII implies there will be conversion of data if the sender and receiver are different systems

  • Anything else that happens in a ASCII transfer? 

  • ASCII transfer is meant for text files (i.e. any readable data). So FTP will also include a couple of extra bytes at the end of each line to signal end of the current line and beginning of the next. The 2 characters inserted are: the "carriage return" and "line feed". 

  • So if we transferred our file containing "A" from mainframes to windows, we'll have the value of 41 (for "A" in ASCII) + 10 + 13 (10 and 13 are the extra 2 bytes for a new line).

        So the next time you do an FTP transfer ensure you are doing the right type of transfer!

Go back to the main contents page