A
If you want the file received to be 100% identical to the original file, you must always transfer in binary mode.A transfer in "alter" text mode you get, in a way that I will describe later. Most files that follow a standardized format should not be transmitted in text mode, because that "alteration" that suffers would leave them useless. This affects typical formats like PDF, xlsx, docx, zip, rar, mp3, mp4, jpg, png, etc... All of these must be transmitted in binary mode if you want them to be identical to the way they were originally ( otherwise you may not open them).Only the files to be opened with a plain text editor could be transmitted in text mode. For example, the source code for a C program, a Python script, a .txt or markdown file, etc... But even these types could also be transmitted in binary mode without problems, and what you would get would be an identical copy of how that file was in the source machine.What alteration does the text mode then?If the receiver is a Windows machine, and the issuer is Unix, the alteration he does is the following: analyzes each received byte and if he finds one with value 10 (0x0A in hexadecimal), it transforms him into two bytes of values 13 and 10 (0x0D, 0x0A in hexadecimal). The rest of bytes let them pass as well.If the receiver is a Unix machine, and the emitter is Windows, the alteration that does is the opposite: it analyzes the received bytes and if two followed of 13 and 10 values (0x0D, 0x0A) makes it one of only 10 value (0x0A).If the machines are both Unix or both Windows, it does nothing (and therefore the transmission equals a binary)Why those transformations?The reason is historical. In Unix the text files use the 0x0A byte to indicate where a line ends (it is the character known as "line Avance", or Line Feed in English, or LF, and typically written as \n in programming languages). Instead in Windows they use the pair of 0x0D bytes, 0x0A ("carrior return + line advance", or Carriage Return+Line Feed, CRLF, typically written as \r\n in programming languages).This difference makes that if you transmit a text file in binary mode, from Unix to Windows, by opening it in Windows with a "tont" editor, who expect a CRLF at the end of each line, as what I would find would be just LF, I wouldn't understand where the lines are divided, and I would show it all as a single long line. A smarter editor would detect that the file does not use the CRLF agreement but only LF and would show you well anyway.Conversely, if you transmit a file in binary mode from Windows to Unix and open it with a "tont" editor in Unix, as at the end of each line there is CRLF where only LF was expected, the lines will have an extra "rare" character at the end (the CR) which is typically shown as ^M in these editors. A smarter editor would detect that the file comes with the CRLF agreement and display it correctly.Therefore the transfer in text mode is to fix the LF vs CRLF issue and help you view it correctly even with dumb editors.Since today most editors are ready, text mode transmission could be considered optional. In addition, if by mistake you transmit in text mode a file that has internally bytes that can take the 10 (0x0A), but do not represent end-of-line, the alteration that makes the transfer in text mode might leave the file unusable (as if what you transmit is for example a .zip among many other formats).And the encoding?Encoding is a different matter that is related to how the characters that are not ASCII are encoded (e.g. eñes or accents). This matter does not fix it with a transmission in text mode, as it has been explained only "arrange" the CRLF problem. The encoding received will therefore match the encoding in origin. The editor in which you open it must support the same encoding.
