(All I'm qualified for because I'm mostly a mainframe programmer.)

If by "text", I assume you mean ASCII, and if my assumptions about "binary" format on the server-side are true... Then the only difference between text and binary are that only valid ASCII characters are permitted in a text file. (Gotta hunch somebody is going to tell me that's not what a binary file is at all.)

When I ftp an EBCDIC file from mainframe to LAN, I have to choose a text file for the receivor. This makes sure that an EBCDIC to ASCII conversion is performed. If I choose a binary receiver file, then the file is copied over verbatim. This results in an EBCDIC file residing on the LAN which is a pretty useless artifact.

If you want to make an ASCII file smaller, I am sure there are some utilities to compress it. Just don't ask me what they are.

Although, I could suggest some ways to program a proprietary compression routine. If you have mainly digits in the file, then it only takes 4 bits to encode all of the digits 0 thru 9. You also have some extra combinations left over (6). These could be used for 5 of the other most common characters in your files (at a guess: space, "e", "r", "s", "t", "." (if decimals in your numbers?), ?). Problems if you have upper case/lower case. Or lots of special characters - but you said 99% digits, so there's no problem. The last combination you should save for when the character is one that is not one of the 15 that you have special 4 bit translations for. It says simply: interpret the next 8 bits as a regular ASCII character. That would essentially cut your file size in half.

If you need more than that, you can count up duplicated characters and add a descriptor nibble that says "following are n iterations of this character".