[This forum posting is two years late, but I'm adding it because this is a frequently asked question and somebody out there may search for it again and find some hope.]

It is very difficult to fix gzip files corrupted by FTP ASCII transfer. The problem is that (on average) 1/256 of the bytes have 3/8 of their bits flipped, and there is no way to distinguish whether one of those CR/LF bytes was supposed to be the way it is, or got that way by the ASCII transfer - so it can't be inverted in any simple way.

So-called zip recovery programs only fix CRC/checksum errors (to avoid error messages), they don't actually fix the data. That's only useful if the file is truncated or has a bad block late in the compressed data. It doesn't work for which about 1/256 of their bytes are corrupted, throughout the file.

So for 99% of the cases, give up, find the original if you can, and re-transfer in binary mode.

Despite what I said above, there is a computationally expensive way to search for the necessary repair. However, it requires custom coding of a search heuristic, and lots of computation. Therefore it's not a turn-key process. It's only feasible if you have no other backup and the data is so critical that you're willing to invest in some custom coding. I documented some details on what it took to recover a pile of 20MB gzip files containing 250MB million-line web server logs, at my web site.