Were I to pursue this further, I'd follow what was suggested earlier around settings. SMTP mail was built for ASCII, and constructs including non-ASCII text and MIME encoding and file attachments and all the rest are all. I wish you well with this, but-having chased around sequential file format disagreements in heterogeneous networks and for most of thirty years, and this particular morass further involves disparate mail servers-I'm not particularly hopeful. You've seemingly already settled on an answer, and seemingly aren't interested in alternatives nor in other settings, so I see no further reason to discuss this here. txt as the attached file extension as Mail may handle other file type differently.

If any one of you can do a simple test to see if the problem can be duplicated, that would be great. I've used other mail client software to send the same text file as an attachment, the downloaded file was exactly the same as the original text file (no extra 0x0D).īelow is the hex dump of the original mail-test.txt as I don't see an attach file option here. You can see the extra line in the text display and the extra 0x0D (red arrow place) in the hex dump for each line. When I received this file attachment on Gmail or Yahoo mail, the downloaded file became: The issue was that Mail somehow added an 0x0D before each 0x0D 0x0A(=CR/LF) pair in the text file as an attachment when it reaches other mail systems. The point is Mail should send text file attachment following the standard (whatever that maybe), when a mail client (following the same standard) should be able to retrieve the attached text file exactly as the original file. And it is not about how unix vs windows handles the new line differently. However, the problem I've traced is not specific to CSV files but in general with any text files. No, I don't have Office around, so I can't test this. Other? Use tr or strings or another tool to trim the data?ĬSV files are a flaming mess which looks easy, and quickly degenerates into differences in the corner cases.

If you don't want that blank line and/or Microsoft isn't inclined to fix the export function and/or other steps, zip the file. 0x0d is a blank line in sequential file encoding on macOS and many other systems. If the xxd or hexdump shows the 0x0d carriage return in the export, ask Microsoft about their export function.

Use xxd or hexdump or a similar tool on that exported CSV file, and have a look at the data contents. Various other discussions involve old Excel versions, too Office 2011 and earlier. The linked topic involves an export from Microsoft Office Excel.

Carriage return in excel mac os