homepage Welcome to WebmasterWorld Guest from 54.161.200.144
register, free tools, login, search, pro membership, help, library, announcements, recent posts, open posts,
Become a Pro Member
Home / Forums Index / WebmasterWorld / Webmaster General
Forum Library, Charter, Moderators: phranque & physics

Webmaster General Forum

    
FTP binary or ASCII
which mode to use when transfering .JS files
Gene




msg:335720
 5:27 pm on Jul 7, 2001 (gmt 0)

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.

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!

 

tedster




msg:335721
 6:00 pm on Jul 7, 2001 (gmt 0)

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.

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.

Gene




msg:335722
 3:34 am on Jul 8, 2001 (gmt 0)

Tedster--

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.

tedster




msg:335723
 5:44 am on Jul 8, 2001 (gmt 0)

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.

engine




msg:335724
 6:49 am on Jul 8, 2001 (gmt 0)

Treat an RTF file as binary - just like a wordprocessed file.

bobriggs




msg:335725
 12:49 pm on Jul 8, 2001 (gmt 0)

tedster:

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

tedster




msg:335726
 10:00 pm on Jul 8, 2001 (gmt 0)

Thanks, bobriggs.

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.

bobriggs




msg:335727
 12:50 pm on Jul 9, 2001 (gmt 0)

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)

tedster




msg:335728
 1:17 pm on Jul 9, 2001 (gmt 0)

Yes, it's usually perl. You've explained it perfectly. Thanks!

Gene




msg:335729
 2:34 pm on Jul 10, 2001 (gmt 0)

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?

bobriggs




msg:335730
 11:57 pm on Jul 10, 2001 (gmt 0)

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>.

Gene




msg:335731
 5:32 pm on Jul 12, 2001 (gmt 0)

bobriggs--

Thanks for the help!

Yes, the file appears fine when viewed in WordPad.

And thanks for answering the .rtf question.

--Gene

Global Options:
 top home search open messages active posts  
 

Home / Forums Index / WebmasterWorld / Webmaster General
rss feed

All trademarks and copyrights held by respective owners. Member comments are owned by the poster.
Home ¦ Free Tools ¦ Terms of Service ¦ Privacy Policy ¦ Report Problem ¦ About ¦ Library ¦ Newsletter
WebmasterWorld is a Developer Shed Community owned by Jim Boykin.
© Webmaster World 1996-2014 all rights reserved