You can specify what separator to use as the first line in the CSV file: sep=, My experience is that Excel 2007 and later will correctly parse the file and us

You can specify what separator to use as the first line in the CSV file: sep=, My experience is that Excel 2007 and later will correctly parse the file and use the specified separator. However, other software, such as Google Sheets, will simply render the declaration as-is. Then there's the issue of what character encoding to use to encode the file, whether to include a byte-order-mark with UTF-8 to make Excel recognize the file as UTF-8 and the effect that has on whether the separator line is recognized (spoiler: it isn't). Here's part of the documentation I wrote for Calcapp's CSV exporter, which digs into these issues in more detail (Javadoc): /** * The prologue of files containing comma-separated values (CSV). This * prologue contains an instruction detailing the separator character that is * used in the file. This instruction is known to be understood by Microsoft * Excel 2007 and later versions, but is rendered as-is by other spreadsheets, * including Google Sheets. * <p> * Microsoft Excel expects either a comma or a semicolon to separate values in * CSV files, depending on the Windows locale. The only way to produce a CSV * file that can be read by Excel regardless of what locale Windows is set to * use is to use a prologue similar to this one, which explicitly tells Excel * which separator is used. */ private static final String PROLOGUE = "sep=" + SEPARATOR_CHARACTER + "\n"; /** * The character set used to encode files containing comma-separated values * (CSV): UTF-16LE (UTF-16 for little-endian systems). Using UTF-16LE allows * characters that cannot be represented by the ASCII character encoding to be * correctly read by Microsoft Excel and other spreadsheets. * <p> * There is no way to formally specify the character set used by a CSV file. * With one exception, Excel assumes that CSV files use the ASCII character * encoding, unless the first three bytes consist of a byte-order mark, in * which case the UTF-8 encoding is used. (A byte-order mark is redundant for * UTF-8, as it does not depend on endianness, but is traditionally used by * Microsoft Windows applications to detect whether a text file uses the UTF-8 * encoding.) * <p> * Excel only recognizes a file as being encoded with UTF-8 if a byte-order * mark is included, but doing so prevents Excel from recognizing the * information of the {@linkplain #PROLOGUE prologue}, which in turn prevents * CSV files from being produced which work regardless of the locale Windows * is set to use. This is likely due to a bug, present in Excel 2007 and * likely later versions as well (based on anecdotal evidence). * <p> * Fortunately, Excel does recognize another character set which can encode * all of Unicode: UTF-16. Excel likely uses heuristics to determine that a * file is encoded using UTF-16. (Text written using Western languages and * encoded using UTF-16 tend to include many null bytes for various reasons, * making the detection of UTF-16 trivial, but only for Western languages.) * Unfortunately, UTF-16 is dependent on endianness, meaning that it would be * desirable to include a byte-order mark at the beginning of the file. * However, that does not work due to the aforementioned bug. * <p> * In other words, using UTF-16LE should work well for CSV files containing * mostly Western text and parsed on little-endian systems. It is probable, * though, that files produced using this converter will not work if the text * mostly contains Chinese, Japanese or Korean characters or if the file is * parsed on a big-endian system. */ public static final Charset CHARACTER_SET;