Forum Moderators: phranque
Well, I just installed Dreamweaver and was looking at the default transfer modes. They have a JS file set to transfer in binary. I know very little about javaScript, but I thought that an external JS file was basically a text file. So shouldn't it be transfered in ASCII?
Anyone have a definitive answer? Or am I making a fuss over nothing to begin with? Thanks for any insight!
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.
So, a javascript file, being a text-only or 7 bit file, will usually transfer just fine in either mode. But it is most properly ASCII, as far as I know. This is also true for HTML files.
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.
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.
HTH
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.
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)
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?
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.
--Gene
