Note that I havent done any proper quoting of cell values or anything, it will need some tweaking to be more robust.

Its also not the fastest solution in my minimal testing but its a start.

After that, I just went with the easiest solution for me personally.

If you are working with end-users, this may not be the best solution.

However what you could do is add a step to your export procedure whereby after saving the csv to disk you could open it in a text editor (I used Coda but quite a few others will do this) and use that to then save it out using another encoding.

For my language (polsih) it was not Macroman, but some variation of it.

Very effective because of the input encoding auto-detection performed by TextEdit.

Not the answer youre looking for Browse other questions tagged ms-office.

This site is not affiliated with or endorsed by Apple Inc.

I did an undergrad in computer science degree at Acadia University.

While a student, I served as the technical director (whatever that means) for the campus radio station, made sound work for the student union, and competed in the ICPC.

Nowadays, I fill my spare time with Dungeons Dragons, self-serving maker projects, video games, and sleep.

Unfortunately, over here in the real world, this new export format creates more problems than it solves.

Files saved in this format still suffer from two other problems: incorrect line ending, and a shocking corruption issue resulting in potentially irrecoverable data loss.

And, on top of that, Excel still has issues even opening files containing special characters.

If you inspect the raw file, youll find Unix-style line endings (that is, a single at the end of each line), quotes escaped with quotes, UTF-8 encoding (note the two-byte ), and a trailing newline.

Im using a fully-updated (as of this post) copy of Excel for Mac 2016.

To get special characters to decode correctly, I need to create a new workbook, then from the Data ribbon, select From Text then, after selecting the file, I can set the File origin to Unicode (UTF-8).

Of course, that method of import doesnt support line breaks in fields.

First, lets see what happens when we save the file using the oldschool Comma Separated Values (.csv) format.

And as expected, the special character has been replaced with 8E.

Unfortunately, thats also where things start going wrong: the first three bytes of the file are a BOM, because Microsoft tools are crazy.

Still, given the above experience trying to open a UTF-8 file, Im not surprised.

Why is the first quote not escaped, and where did that extra et come from Ill give you a hint: its from earlier in the field.

The output, when quotes within fields are involved, is completely untrustworthy.

The original input is all but unrecoverable (if there is a pattern for unwinding the damage, it isnt obvious to me), so any file saved this way is basically useless if there are quotes anywhere other than the header.

And I havent tried, but it looks like it would be pretty easy to generate collisions (the same output for different input) meaning that even if there is a pattern, its almost certainly not bijective.

What I dont get is how nobodys noticed this nearly eighteen months after Office for Mac 2016 was released to Office 365 subscribers.

At time of release, Office 2016 seemed like a huge step forward for Office for Mac, including far better compatibility with the Windows version of Office applications and a significantly improved UI.

But the persistence of issues like these do raise doubts about Microsofts continuing commitment to bugfixes outside of major releases.

Excel For Mac Csv Utf-8