|FTP binary or ASCII|
which mode to use when transfering .JS files
I've read that some files should be FTP'd using ASCII mode, (txt, rtf, html). Someone has also said that basically, if you can open & read a file in NotePad, then you should probably FTP it in ASCII mode.
Anyone have a definitive answer? Or am I making a fuss over nothing to begin with? Thanks for any insight!
Here's my understanding:
Every byte is 8 bits. In ASCII, a byte is made up of 7 "significant" bits and an eighth, "insignificant" bit, used for error control. Binary uses all 8 bits as significant bits. Text-only is ASCII, whereas word processing documents, image and data files, etc, are binary.
If a binary file is transferred in ASCII mode, every eighth bit becomes corrupted and the file unusable — you inevitably corrupt a binary file by sending it as ASCII.
But sending ASCII files as binary works much of the time, if the operating systems on both ends are using the same convention for that eighth "error-checking" bit. However, you certainly CAN get into trouble with Unix/Mac/Windows mismatches which use different conventions.
Nevertheless, I routinely send both JS and HTML in binary from Windows 98 to various flavors of 'nix and Windows with no problems. My guess is that many servers today (especially those offered by web hosts) will accommodate this minor sin by checking for the OS during the initial handshake, and matching their eighth-bit convention to the convention used by sender's machine.
I'm surprised that DW defaults a js file to binary. If there's something I've written above that is not correct, I'd appreciate knowing about it.
Thanks for the help. I also think that Dreamweaver had an .RTF file set to transfer in binary, which I've now changed to ASCII.
Oddly, their help file says that these settings have to be changed by hand, modifying a file named "FTPExtensionMap.txt. It's located in the "configuration" subfolder inside the Dreamweaver program folder, if anyone's interested.
Not 100% sure about RTF files, but they are not "text-only", they're Rich Text Files. I think the "Rich" part meeans they need a binary transfer.
Treat an RTF file as binary - just like a wordprocessed file.
You're partially correct about using the 8th bit as error control, however, it's outdated. The eighth bit can also be used for internationalization (extended character sets or codepages) but there is no standard for this.
The main use of ASCII transfer in FTP is for the FTP server to strip line ending characters (carriage return and line feeds) into the correct form for the server: on *NIX boxes, a CR/LF pair will be converted into a single LF. (MS-DOS/Windows computers use Carriage Return/Line Feed pairs to denote the end of a line)
All files are binary, ASCII is just a subset. It would be less confusing if instead of ASCII mode, the FTP clients called it 'text mode'. So if you sent an 8 bit ASCII file via FTP, any 8th bit that is set would be retained, and any CR/LF pairs would be converted to a single LF.
Perhaps you can help me understand this situation. It's the one time I know I MUST use ASCII sending a cgi file to a particular UNIX server from my Win98 machine.
If I use binary transfer, the cgi will not run, at least with this particular host. It's always puzzled me, because, as you say, all files are essentially binary.
I'm just assuming that the .cgi in question is an editable script like a perl script...Then since the cgi is actually executed on the (UNIX) server, the perl or cgi engine must see the script in its own OS specific format, which is to have a single line feed as a line terminator. A carriage return thrown in there will confuse it.
If the CR/LF pairs are sent to a MS or MAC machine with a .js or .css file, they're ignored (actually just treated as whitespace characters anyway)
Yes, it's usually perl. You've explained it perfectly. Thanks!
Thanks to everyone for the feedback!
I thought that .rtf should be FTP'd as ASCII because I read it in an O'Reilly book, "Web Design in a Nutshell," page 63.
I know that doesn't necessarily make it true. Perhaps it's a typo. Any thoughts?
On a slightly different note, here's an interesting situation I encountered...
I create a .txt file in NotePad, then, using Excite's web-based email, I send this file as an attachment (using their "attach" directions).
The recipient of this email is a web-based email account that I have with "catholic.org".
So now I log in to catholic.org, open my mail and download the the .txt attachment to my hard drive.
But NOW the file isn't the same anymore--it's all jumbled together! At the end of what should be the first line, there's a small "black box" and then the text continues on the same line (when it should have started a new one).
I know that the problem is with catholic.org because when I perform the same experiment in reverse order, and download the file from Excite's end, everything is fine.
I also notice that when I use the "view" option in catholic.org, the file is also jumbled together, whereas in Excite's "view" it isn't.
So what is catholic.org doing wrong? Is there something I can tell them to correct this?
What you are seeing is the UNIX line end characters (LF) line feeds (the square boxes). Notepad is a very simple program and expects CR/LF pairs to end a line, so there are no CR Carriage returns, everything looks funny. It just displays the LF as an unprintable character.
Open the same file in WordPad. Looks ok doesn't it? That's because wordpad knows that LF or CR/LF can end a line in a text file.
Why this is happening only one way I don't know. It could be a server mime/type problem; obviously the text is being transformed along the way. My guess is that excite mail strips the CR/LF pairs to a single LF and when reading back a single LF it will convert to CR/LF. Or some other app like sendmail along the way could be doing a conversion.
Also, RTF should be transferred as ASCII (or text). Find one on your hard drive, right click, and then select 'open with' and use Notepad. You'll see it contains formatting codes kinda like html (/par) instead of <p>.
Thanks for the help!
Yes, the file appears fine when viewed in WordPad.
And thanks for answering the .rtf question.