Picturers doesnt work

[moisap]

Hi

 

I was working on my template images and when I uploaded the images with FTP (in ASCII mode) all the images in the template were weirdly corrupted..

What could be the problem?

 

:huh:

[FIMBLE]

you need to upload as binary, that prob why.

Rgds

nic

 

 

[Guest]

Ari-Pekka,

 

I always find it best to set the transfer mode to AUTO so it switches from ASCII to BINARY as required.

 

 

 

 

Chris

[MrPhil]

I uploaded the images with FTP (in ASCII mode) all the images in the template were weirdly corrupted..

Uh uh. Let me explain FTP.

 

ASCII (sometimes called TEXT) mode is for human readable text files (e.g., a .php file). All computer operating systems have some convention for marking the end of a line of text. DOS/Windows uses carriage return + linefeed (x0D0A), Linux/Unix uses newline (x0A), and older Macs use carriage return (x0D) to mark the end of a line. When transferring a file between two systems using different conventions (e.g., Windows PC upload to a Linux server), FTP (or any other file transfer method) needs to convert from the source's end-of-line convention to the destination's. If you don't, the file will be difficult to read and often won't work at all. The best solution is to retransfer the file, using the correct mode, but if you've lost the originals, usually you can transfer back to a PC in BINARY and then upload again, this time in ASCII.

 

BINARY mode is for anything else, including images, compressed files, tar files, zipped files, executables (.exe) etc. It does not do any end-of-line conversions, but copies the file bit for bit unchanged. Binary data such as an image may happen to include random x0D's and x0A's in the data, and changing them over (treating them as end-of-lines) will permanently corrupt a file. Usually it's impossible to fix the file, except to transfer the original again (in the correct mode), because there's no way to tell which end-of-line marks were converted (wrongly) in the first place. Say an image file on the PC includes x0D, x0A, and x0D0A sequences. Transferring in ASCII to a Linux server might leave the x0D and x0A alone, but x0D0A sequences would be turned into x0A. Now you have just x0D and x0A in the file. You realize your mistake, and transfer back to a PC in ASCII mode. All the x0A bytes will be changed to x0D0A, including any that were originally just x0A! Thus the file is still corrupted.

[multimixer]

Uh uh. Let me explain FTP.

 

MrPhil makes always a nice tutorial when answering a question

[moisap]

Uh uh. Let me explain FTP.

 

ASCII (sometimes called TEXT) mode is for human readable text files (e.g., a .php file). All computer operating systems have some convention for marking the end of a line of text. DOS/Windows uses carriage return + linefeed (x0D0A), Linux/Unix uses newline (x0A), and older Macs use carriage return (x0D) to mark the end of a line. When transferring a file between two systems using different conventions (e.g., Windows PC upload to a Linux server), FTP (or any other file transfer method) needs to convert from the source's end-of-line convention to the destination's. If you don't, the file will be difficult to read and often won't work at all. The best solution is to retransfer the file, using the correct mode, but if you've lost the originals, usually you can transfer back to a PC in BINARY and then upload again, this time in ASCII.

 

BINARY mode is for anything else, including images, compressed files, tar files, zipped files, executables (.exe) etc. It does not do any end-of-line conversions, but copies the file bit for bit unchanged. Binary data such as an image may happen to include random x0D's and x0A's in the data, and changing them over (treating them as end-of-lines) will permanently corrupt a file. Usually it's impossible to fix the file, except to transfer the original again (in the correct mode), because there's no way to tell which end-of-line marks were converted (wrongly) in the first place. Say an image file on the PC includes x0D, x0A, and x0D0A sequences. Transferring in ASCII to a Linux server might leave the x0D and x0A alone, but x0D0A sequences would be turned into x0A. Now you have just x0D and x0A in the file. You realize your mistake, and transfer back to a PC in ASCII mode. All the x0A bytes will be changed to x0D0A, including any that were originally just x0A! Thus the file is still corrupted.

 

Thank you Mr.Phil! This was a much-needed tutorial!

-ap

[moisap]

Yep problem solved with Binary mode upload..

Thank you all!

 

-ap

:)

[Getting Smarter Slowly]

MrPhil is a smart guy even though his cat looks mean! :thumbsup:

[MrPhil]

Snowball II is not a mean cat! If you call her "mean" again, I'll have her use your face as a scratching post!

 

Yes, I do tend to write tutorials. Glad to hear they're helpful.

[moisap]

:lol: