FTP Data Type: ASCII vs Binary

[arthurk]

Please can anyone advise on which data type is best to use for FTP transfers? I've found various answers online, with little agreement, so I thought I'd see what opinions I might find here.

I've recently been trying out FileZilla for uploading files to my websites. After uploading an .htm file I noticed that the file on the server was smaller than the one on my computer; as well as being a bit disconcerting, it means that FileZilla's option to highlight differences between local and uploaded files by size is pretty pointless.

After looking into this, I gather that FileZilla's default setting is to transfer text files (including .htm) as ASCII type, which changes certain line ending characters, making the file smaller. My previous program (WinSCP) defaults to Binary type for all files; no changes are made, so the file sizes are identical.

Both programs allow me to select which type to use, and I am inclined to set FileZilla to use Binary for everything, so that I can use file size comparisons. Is there any good reason not to do this? And does any of this affect the way a browser renders a web page?

[andrewalston]

HTML ignores the line ending characters used in the editor at your end. There are tags to define paragraphs ( <p>, </p> ) and line breaks ( <br> ), so the format seen in a browser would be the same whether the source includes carriage returns, linefeeds, both or none at all.

So edit the HTML into blocks which make sense to you when looking at it in your editor.

[arthurk]

HTML ignores the line ending characters used in the editor at your end. There are tags to define paragraphs ( <p>, </p> ) and line breaks ( <br> ), so the format seen in a browser would be the same whether the source includes carriage returns, linefeeds, both or none at all.

Thanks - so the way it's rendered in a browser isn't going to be affected.

So edit the HTML into blocks which make sense to you when looking at it in your editor.

Yes, that's what I already do - but all this has reminded me of something that puzzled me a bit: when I look at the source of one of my pages after uploading it, everything is laid out in the blocks I wrote it in. Nothing seems to have been ignored or changed, so does this mean the browser's source code viewer is able to interpret the HTML and/or the carriage returns etc (whether in the form used by binary or ASCII) in order to show the document as it was originally produced?

Any thoughts on the main question - whether to upload as binary or ASCII?

[andrewalston]

Yes, the viewer will almost certainly treat a carriage return, a linefeed or a pair of them as "show at the beginning of the next line".

If you like being able to compare file sizes, use binary transfers. The stripping out of "extras" with text mode may save a few bytes, but few web pages will be big enough to make a noticeable difference, and storage is cheap these days in any case.

[SMJ]

Filezilla does have an Auto detect mode in the Settings>Transfers>FTP: File Types menu giving the options of Auto, ASCII or Binary.

If you're using standard ASCII characters (UTF8) then it makes no difference as everything gets interpreted as an 8 bit (1 byte) value from 0 to 255 and the conventional CR & LF happens as needed depending on the operating system. Also most graphic file formats are based around 8 bit data blocks to allow transfer over legacy systems anyway.

However if you extend the character set to include UTF16 or UTF32 (i.e. Japanese/Chinese or EMOJIs) in your webpage code then Binary is the way to go.

Binary mode is also there to allow the transfer of data files where the break up into 8 bit blocks or the truncating of empty blocks of code to save space would cause problems.

Differences in file size can often be caused because Windows sends a CR and a LF character pair at the end of each line whereas MacOS and Linux (everyone else) make do with just a LF.

[arthurk]

Thank you for all these thoughts and comments.

While researching this I saw a few complaints from people who said that using ASCII exclusively was causing some files (particularly images, I think) not to upload properly, so that doesn't seem a sensible option. FileZilla's auto-detect method does avoid this, with ASCII just for text or HTML files, but WinSCP defaults to binary for everything.

Anyway, since I do like to be able to see and compare file size in both local and remote folders, I've decided to use binary exclusively. (For completeness I'd add that I also like to compare dates and times, which was another setting to change in FileZilla - the remote folder initially showed date and time uploaded rather than last saved.)