This is Interesting: Free Magazines for Graphics designers and webmasters
Home > Archive > Webmaster forum > September 2006 > Re: When to use ASCII or BINARY for FTP...
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: When to use ASCII or BINARY for FTP...
|
|
| Andy Dingley 2006-09-24, 6:59 pm |
|
ship wrote:
> Please can someone explain to me when to use ASCII and when to use
> BINARY for FTP!
If in doubt, always use binary.
Always use binary for binaries: images, executables, raw data
Possibly use ASCII when it's ASCII text in a file with significant
linebreaks, and you're moving between Unix, Mac and Windows. ASCII mode
will fix up the end-of-line markers between these varying operating
systems.
"Web content" generally doesn't care about end-of-line markers. It
doesn't matter for HTML or CSS. It might matter for some scripting
languages.
Don't use ASCII when the content is non-ASCII text, i.e. it has
"foreign language" characters in a non-ASCII encoding.
Most ftp clients can switch modes automatically, and will usually make
a fair attempt at it.
If you're working with files from a Unix system on a Windows desktop,
make sure you have an editor that can cope with Unix linefeeds. Notepad
won't, but Wordpad can (both in the basic Windows package). Any decent
add-on editor will cope too.
| |
|
|
>
> sorry - not permitted in the UK (and other territories)
>
You are a harsh man, William Tasso, harsh...
Ship
| |
|
|
>
> Simple: ASCII for text files (including HTML, Perl, PHP, CSS and ASP
> files) and binary for binary files (including images, audio and pdf).
>
>
> Filesize is entirely irrelevent; different operating systems will
> measure the space taken up by a text file in different ways and hence
> report a slightly different filesize. A text file is not just the
> contents, it's also the associated header information (the data that
> defines the file to the OS), and that's going to be OS-dependent and
> will therefore affect the reported size. There is no reason at all why
> it should matter that they are not quite the same on the remote system
> as on your local system.
>
> Transferring a text file in binary, on the other hand, risks
> corrupting the file in odd ways such as the double spacing that you've
> mentioned. It won't usually be a major problem, but it can be
> irritating (and it can break script files if the line endings are
> converted in the process).
Mark
The problem is that for synchronisation purposes,
(using Beyond Compare 2, at least) file size *DOES* seem to matter.
In Beyond Compare 2 - which someone here recommended, btw - if the
files
are NOT the same size then they stay red, (rather than go black) and
are indistinguishable from files of different date! [groan]
BC2 which looks extremely promising, btw, and
MUCH better at synchronising in the desired manner
than DreamWeaver 8, incidentally.
What I cant quite understand is why transferring in BINARY
should do ANYTHING to a file.
In BC2, if I use BINARY to do FTP transfers they then do stay the
same size - but like Andy Dingley says *sometimes* it seems to
create double-spacing, and if this risks breaking Javascript scripts
then
this would be a disaster! ...Which seems to be pushing me back
to ASCII !
....But ASCII transfer means I can synchronise in BC2.
Aaaaarrrggghh
[Still in misery]
Ship
Shipeton Henethe
| |
|
| Is there any merit in tranferring ONE direction in ASCII but the OTHER
direction
in BINARY?
(Btw, I have a MASSIVE number of HTML files to transfer
so these are not trivial questions!)
Ship
Shiperton Henethe
| |
| Andy Dingley 2006-09-24, 6:59 pm |
|
Mark Goodge wrote:
> Simple: ASCII for text files (including HTML, Perl, PHP, CSS and ASP
> files) and binary for binary files (including images, audio and pdf).
HTML isn't an "ASCII text file" in this context. It may be non-ASCII
if you're using characters outside the ASCII set.
Fortunately it's also not a "text file" (for ftp's purposes) as
linebreaks aren't significant in it. This means that ftp is still
capable of moving them easily, just transfer them as binary and don't
worry about the linebreaks.
I don't think CSS or Javascript will care about linebreaks either
(counter-examples welcome) and the obvious language that is fussy about
line breaks (Python) is also quite generous about parsing the varying
characters used to delimit them.
I imagine VBScript would fall over if it even sniffed a Unix filesystem.
| |
|
| > > Simple: ASCII for text files (including HTML, Perl, PHP, CSS and ASP
>
> HTML isn't an "ASCII text file" in this context. It may be non-ASCII
> if you're using characters outside the ASCII set.
>
> Fortunately it's also not a "text file" (for ftp's purposes) as
> linebreaks aren't significant in it. This means that ftp is still
> capable of moving them easily, just transfer them as binary and don't
> worry about the linebreaks.
>
>
> I don't think CSS or Javascript will care about linebreaks either
> (counter-examples welcome) and the obvious language that is fussy about
> line breaks (Python) is also quite generous about parsing the varying
> characters used to delimit them.
So... you're pretty sure HTML should be always be transferred using
BINARY.
And if extra line-breaks appear then tough, right?
Hmmm... what happens if I accidentally have some extended ASCII
characters
in there? E.g. French or German weird ones e.g. for sake of argument
the "=F4" in "Swiss=F4tel" - or the GBP symbol ("=A3") perhaps went in
wrong (??)
(I'm not quite sure at this point *exactly* how everthing has been
entered - and like I say it's a site of several thousand pages!
[sigh] )
=20
Ship
Shiperton Henethe
| |
| Matt Probert 2006-09-24, 6:59 pm |
| On 20 Sep 2006 04:29:07 -0700, "ship" <shiphen@XXXXXXXXXX> wrote:
>(I'm not quite sure at this point *exactly* how everthing has been
>entered - and like I say it's a site of several thousand pages!
>[sigh] )
Relax!
Read my reply, or don't <g>.
But ZIP the HTML files before sending them, and then GZIP them out at
the server.
Matt
--
Veritas Vincti
http://www.probertencyclopaedia.com
| |
| Andy Dingley 2006-09-24, 6:59 pm |
| ship wrote:
> (using Beyond Compare 2, at least) file size *DOES* seem to matter.
> In Beyond Compare 2 - which someone here recommended, btw - if the
> files
> are NOT the same size then they stay red, (rather than go black) and
> are indistinguishable from files of different date! [groan]
Then use a real tool (which probably means it's time for a Unix or
Cygwin shell)
> What I cant quite understand is why transferring in BINARY
> should do ANYTHING to a file.
It doesn't. Ever. Nada.
Macs are a biit weird here, because of their attached file metadata.
This usually gets transferred too (from Mac to non-Mac with a Mac-aware
tool), but it ends up in some "nearby" file (usually a mangled filename
based on the first) rather than in the same file.
> In BC2, if I use BINARY to do FTP transfers they then do stay the
> same size - but like Andy Dingley says *sometimes* it seems to
> create double-spacing,
It doesn't _create_ double spacing, it's just that files from one OS
may appear mis-spaced if viewed on a different OS. You can avoid this
by modifying the file in transit, as ftp ASCII mode does.
Or you can ignore it. In most contexts the whitespace isn't significant
so although it looks ugly, it'll still work.
The problem with ftp is that it couples the concept of "ASCII" and
"text files with linebreaks" together. This is OK if you have one or
neither, but tricky if only one applies.
| |
| Andy Dingley 2006-09-24, 6:59 pm |
| ship wrote:
> So... you're pretty sure HTML should be always be transferred using
> BINARY.
> And if extra line-breaks appear then tough, right?
Extra line-breaks won't appear. Line break characters will get
translated, which isn't the same thing. There could be CR, CRLF or LF,
but you won't have these turn into LFLF
> Hmmm... what happens if I accidentally have some extended ASCII
> characters in there?
Extended 8-bit ASCII is OK with ftp, the problem really arises with UTF
encodings. If you use an ISO-8859-* encoding, or a Windows codepage,
or something ancient that is still compatible with an 8 bit ASCII pipe,
then it's OK. Of course you have to remember (outside of ftp) just
_which_ encoding you used, because much of ISO-8859-5 will be garbaged
if you later try to handle it as ISO-8859-1. Also there's no formal,
embedded description of what encoding was used for a file (you might
have a suitable <meta> if it's HTML).
UTF though can be a problem, even though this is rare. I wouldn't
advise transferring it as ASCII, although I wouldn't be surprised if
anyone posts "I've been doing this for years and never had a problem
yet".
| |
|
|
Matt Probert wrote:
> On 20 Sep 2006 04:29:07 -0700, "ship" <shiphen@XXXXXXXXXX> wrote:
>
>
> Relax!
>
> Read my reply, or don't <g>.
>
> But ZIP the HTML files before sending them, and then GZIP them out at
> the server.
Zipping & unzipping - what every single time you edit file?
You've gotta be kidding!
Ship
Shiperton Henethe
| |
| Karl Groves 2006-09-24, 6:59 pm |
| "Andy Dingley" <dingbat@codesmiths.com> wrote in
news:1158756992.369224.174840@m7g2000cwm.googlegroups.com:
> UTF though can be a problem, even though this is rare. I wouldn't
> advise transferring it as ASCII, although I wouldn't be surprised if
> anyone posts "I've been doing this for years and never had a problem
> yet".
Hi! ;-)
--
Karl Groves
www.karlcore.com
| |
|
|
Dylan Parry wrote:
> ship wrote:
>
>
> I've always let my FTP client decide this for me. I don't think[1] I've
> had any problems with taking this approach.
If only I could get Beyond Compare (v2) to ignore File Sizes,
then I would cheerfully just use ASCII transfer for all ASCII files.
But at present it's very hard to synchronise because it keeps
saying everything isnt the same - even though I have only just
copied it over!!
(In the ideal world it would ignore filesizes unless they were
SIGNIFICANTLY different!)
Hey-ho
Ship
Shiperton Henethe
| |
| Dylan Parry 2006-09-24, 6:59 pm |
| ship wrote:
> If only I could get Beyond Compare (v2) to ignore File Sizes,
> then I would cheerfully just use ASCII transfer for all ASCII files.
If it is relying on the reported file sizes to decide whether the files
are the same, then it's broken. I would suggest that you find a
different tool for managing your site.
--
Dylan Parry
http://electricfreedom.org | http://webpageworkshop.co.uk
Programming, n: A pastime similar to banging one's head
against a wall, but with fewer opportunities for reward.
| |
| Matt Probert 2006-09-24, 6:59 pm |
| On 20 Sep 2006 06:03:13 -0700, "ship" <shiphen@XXXXXXXXXX> wrote:
>
>Matt Probert wrote:
>
>Zipping & unzipping - what every single time you edit file?
>You've gotta be kidding!
>
No. That's what we do. We have an automatic process that ZIPs all the
source files (into a few archives), then we transmit the archives to
the server. There, another script unzips them. Excluding the transfer
it takes seconds.
Or perhaps you'd prefer another solution. Edit your files on the
platform they are intended for.
Matt
--
Veritas Vincti
http://www.probertencyclopaedia.com
| |
|
|
Dylan Parry wrote:
> ship wrote:
>
>
> If it is relying on the reported file sizes to decide whether the files
> are the same, then it's broken. I would suggest that you find a
> different tool for managing your site.
No, it is using date AND file size!
And this sounds sensible to me because date alone
may not be enough.
If you have any suggestions for any OTHER tools that can
do powerful synchronisations then I'd like to hear about them!
As described elsewhere, we have had severe problems with
using Dreamweaver's synchronisation because if someone
accidentally updates the local files (e.g. by editing a
template and saving) then Dreamweaver can not be trusted
to go and get the OLD version of the HTML pages when you
try and Synchronise.
i.e. There are times when you need to say in effect - "please
assume that the live website is the *master* copy of everything,
and go and take a copy of any file on the server that is not the
same as the corresponding local copy of each file"
The problem is that in DreamWeaver the only way to do this
appears to be to use the GET command and to get EVERTHING.
i.e. to be safe copy the entire website over!
We now have a LARGE website and to copy the ENTIRE website
of over 0.5GB is not very feasible - and all just to update a few
files of course!
So... any other suggestions (other than Beyond Compare or
using GET in Dreamweaver)?
Ship
Shiperton Henethe
| |
|
| > >> >(I'm not quite sure at this point *exactly* how everthing has been
>
> No. That's what we do. We have an automatic process that ZIPs all the
> source files (into a few archives), then we transmit the archives to
> the server. There, another script unzips them. Excluding the transfer
> it takes seconds.
What you transfer the ENTIRE website each time you need to make
sure one version is the master. Zipped & automated or not this strikes
me as a damned painful way of copying the few files which
need updating. Especially when you have a site like ours which
is over 500MB!
> Or perhaps you'd prefer another solution. Edit your files on the
> platform they are intended for.
Not feasible.
No we simply want to edit on a PC like most other folks and
upload on to a server... like most other folks!
Ship
Shiperton Henethe
| |
| William Tasso 2006-09-24, 7:00 pm |
| Fleeing from the madness of the http://groups.google.com jungle
ship <shiphen@XXXXXXXXXX> stumbled into news:alt.www.webmaster
and said:
> ...
> we simply want to edit on a PC like most other folks and
> upload on to a server... like most other folks!
There's your problem: "we"
'most other folks' are working on their own.
As soon as you have more than one person working on a site (no matter how
big it is) you are into version management and control.
I have one developer that works for me on occasion (no names), she has
twice (to my knowledge) overwritten other folks carefully crafted work.
Deciding that a file shouldn't be uploaded based on date and/or file-size
simply isn't good enough. Version control is paramount.
Visual SourceSafe if you are a Microsoft shop. Otherwise: Subversion.
Both will need to be loaded on a server that is accessible to all
developers and can also communicate with the dev/uat site server.
--
William Tasso
http://williamtasso.com/words/what-is-usenet.asp
| |
| Andy Dingley 2006-09-24, 7:00 pm |
|
William Tasso wrote:
> Visual SourceSafe if you are a Microsoft shop. Otherwise: Subversion.
I'd prefer a pile of post-it notes to Sourcesafe. Your source just
isn't safe with it.
Windows makes an excellent client for svn (in fact it's probably the
best client), and there's no reason why you can't also host the svn
server on it.
| |
| Matt Probert 2006-09-24, 7:00 pm |
| On 21 Sep 2006 09:15:04 -0700, "ship" <shiphen@XXXXXXXXXX> wrote:
>
>What you transfer the ENTIRE website each time you need to make
>sure one version is the master. Zipped & automated or not this strikes
>me as a damned painful way of copying the few files which
>need updating. Especially when you have a site like ours which
>is over 500MB!
>
>
>Not feasible.
>
>No we simply want to edit on a PC like most other folks and
>upload on to a server... like most other folks!
>
Oh dear!
(knowing nods and smiles from the technical bods)
Never mind, you could go always go into a profession where you are
qualified, and leave computing to those of us who know what we're
doing.
Oh, and yes, I *do* think people should learn how to drive before
getting behind the wheel of a car also.
Matt
--
Veritas Vincti
http://www.probertencyclopaedia.com
| |
|
|
>
> Oh dear!
>
> (knowing nods and smiles from the technical bods)
>
> Never mind, you could go always go into a profession where you are
> qualified, and leave computing to those of us who know what we're
> doing.
>
> Oh, and yes, I *do* think people should learn how to drive before
> getting behind the wheel of a car also.
>
> Matt
Exactly what point are you trying to make Matt?
You message lands as:
"Hi my name is Matt.
I know something you dont.
But rather than tell you anything useful,
I'm going to make you feel small, weak and inferior.
Why?Because I am insecure and it makes me feel better about myself.
....And I am a 'professional'.
Er thanks Matt
| |
| Charles Sweeney 2006-09-24, 7:00 pm |
| ship wrote
> need updating. Especially when you have a site like ours which
> is over 500MB!
That's about one page on Matt's site!
--
Charles Sweeney
http://CharlesSweeney.com
|
|
|
| | Copyright 2003 - 2008 forum4designers.com Software forum Computer Hardware reviews |
|