Thanks for the tip, Sean. Looking back, I should have included "CSV" in the subject header of my post, but at the time I thought the issue my be something more than export format.

I agree this isn't related to encoding, it's best to stick to UTF-8. There is a hidden option to CSV and TSV Export "ForceDelimieters" that controls whether the setting for "TextDelimiters" is wrapped around text fields always, or only when needed. Since this isn't documented yet, this might change in future versions. The reason we always wrap non-numeric values in the delimiter is export would be much slower if it has to test each string for the presence of a comma, newline, or delimiter. Compare these outputs:

In[2382]:= ExportString[{{1, "B", "test,comma"}}, "CSV"]

Out[2382]= "1,\"B\",\"test,comma\"
"

In[2383]:= ExportString[{{1, "B", "test,comma"}}, "CSV", 
 "ForceDelimiters" -> False]

Out[2383]= "1,B,\"test,comma\"
"

In[2385]:= ExportString[{{1, "B", "test,comma"}}, "CSV", 
 "ForceDelimiters" -> False, "TextDelimiters" -> "'"]

Out[2385]= "1,B,'test,comma'
"

If your data does not contain any commas or newlines, then the best approach is to just disable text delimiters all together so that the string matching doesn't kick in (notice this mangles the field with a comma):

In[2387]:= ExportString[{{1, "B", "test,comma"}}, "CSV", 
 "TextDelimiters" -> None]

Out[2387]= "1,B,test,comma
"

P.S. I stumbled on this post by accident, and probably would have seen it sooner if CSV was in the title :)

Greg:

There is no need to try the CharacterEncoding->"Unicode" as this only proves that one can export the same data and by chosing that character encoding the file will be larger (double byte). But in your case it was the quoted and unquoted fields that made a difference.

I would like it if the CSV issues on all systems would be put to bed, but CSV is not yet a true standard (?). [Not looking for a debate]. Many don't implement it well not just on export but on import. But I believe that WRI is doing the export correctly, put quotes around fields. If one reads the RFC for CSV and many other notes and opinions on CSV, it is hard for me to see how one would not come to the conclusion that the safest way to protect fields from confusion is to wrap them in quotes and worry about types later.

Also note that the qoute character can be substituted and escape characters can be used. There are many EDI systems (formats) that indicate the record, field, escape separators and delimiters in a header/init or first line of file being transformed/consumed. So CSV is not different just badly implemented in many systems. Now WL provide ways that you can create you own import/export converter. So I think that could be the best approach. You want to export your CSV without quotes. I am not certain of all the pitfalls (if any). When time permits I may come back with code examples.

Hi Rohit,

Thanks for the suggestion. I will compare the files in terminal, but see my response to Hans.

Regards,

Greg

Hello Greg:

Please provide some sample code.

Using the Export and Import functions without options is asking for WRI magic to happen. In most cases this works very well if not even powerfull and keeps user from worry on/about details.

But without seeing any code on the Export and knowing what the default export options are on Apple Numbers, I would have to guess, ASCII, UTF-8, Unicode (character encoding) can account for the difference.

https://medium.com/@apiltamang/unicode-utf-8-and-ascii-encodings-made-easy-5bfbe3a1c45a

https://www.joelonsoftware.com/2003/10/08/the-absolute-minimum-every-software-developer-absolutely-positively-must-know-about-unicode-and-character-sets-no-excuses/