^M (character #13 in the ASCII set) is a carriage return. ^J (character #10) is a linefeed. In Windows, PC-DOS, various ancient mainframes, and traditional Internet standards, a line break is represented by CR followed by LF (#13#10, ^M^J). In Unix, Linux, and similar operating systems, a line break is represented by a LF alone (usually called a “newline” by Unix geeks). In MacOS, as well as older Apple systems such as the Apple II series, and also on the Commodore 64 and some other obsolete home computers, line breaks are represented by CR alone. Loads of fun results when a file created in a system with one convention is used on a system with a different one.
Transferring by FTP in ASCII mode rather than binary mode should cause the line breaks to be converted properly to the destination system’s convention, assuming of course that the FTP program knows correctly what operating systems are in use at either end, and the file in question is in fact stored correctly for the conventions of the originating system. If the file has previously been transferred in the wrong mode, or it’s been sent in a non-FTP manner (e.g., over a LAN where remote systems of different OS are treated as if they’re local drives), then it can get all screwed up anyway.
The whole problem is the fault of whoever devised ASCII around 1963 or so (the year I was born); the control codes were designed to control printing Teletype terminals, and they decided that shoving the carriage to the left edge of the device (CR) should be a separate operation from moving it down a line (LF). Back in my college days, I remember occasional fads of doing neat animated effects (e.g., in plan files) by having CRs without LFs. Backspaces sometimes were also used there.