Saving a file in a CSV type in Excel always removes the BOM

85

There are no polite answers to questions of the form "Why does Excel do X?".

Why don't you just adopt "Save as Unicode Text" as your standard transfer format? Excel Save as ensures there's a BOM, uses TAB as a delimiter, quotes fields just like CSV ...

By the way, you don't "select the CSV extension". You have TWO choices -- format and extension. Try save as unicode text in the 'Save as type' box and manually change the extension in the 'File name' box to csv. Then exit from Excel and double-click on the file name in Windows Explorer. Opens up fine. Try it.

Update to discuss OP's comments:

  • "Save as Unicode Text" (in Excel 2007) will always save your file as a Text extension (I can't speak for previous or newer versions). That's the idea of "Save as type"...

=> Please read carefully what I wrote above and try it out for your self. It will always save your file with a TXT extension unless you override that: delete the txt in the 'File name' box and type csv.

  • To clarify your "Excel Save as ensure there's a BOM", is incorrect.

=> "Save as Unicode text" ensures that there is a UTF-16LE BOM at the front of the file. Try it and see.

  • This is the reason I asked a question in the first place! If I open a CSV formatted file that contains a BOM to indicate my file Encoding is UFT-16LE and modify this file via Excel, I expect when I save this file that the Encoding remains in tact...

=> and your expectations are not met, because Excel doesn't retain any info about input CSV files. There is no way to force it to do what you want to do. So you either give up or try something else, like what I'm suggesting.

  • What would be really nice is someone who's experienced these problems before, provide your insight please.

=> I have experienced these problems, with Chinese data and Excel 1997, years ago. I have, before answering your question, verified with Excel 2003 and Excel 2007 that Excel is still behaving badly. I have verified that the "save as type = Unicode text, extension = CSV" workaround does indeed work. I have provided my insights.

Share:
85

Related videos on Youtube

Ron Tesler
Author by

Ron Tesler

Updated on September 17, 2022

Comments

  • Ron Tesler
    Ron Tesler over 1 year

    I'm writing a library that will provide an "enhanced" activity class. Let's call it a "SuperActivity".

    I want the developer's application to have a second activity that will do the same as his original activity, but will also extend SuperActivity.

    I need the 2nd activity to be able to run at the same time with the original, to have different manifest attributes (theme, intent-filters, ...) and to keep the original activity with the same attributes.

    Also, I want to prevent more than one instance of the 2nd activity, while keeping the developer's original activity with the ability to have as much instances as he planned to have.

    Now the trivial solution is to make the developer do the following - 1. Make the original activity extend SuperActivity. 2. Write a new activity that extends the original activity. 3. Put a new node in AndroidManifest.xml with the name of the new activity and the required attributes.

    I'm not sure, but I think it's an ugly thing for the developer to do. Is there a more elegant way of doing it? (Fewer steps, not making the developer to write a new activity, ..)

  • Admin
    Admin almost 14 years
    "Save as Unicode Text" (in Excel 2007) will always save your file as a Text extension (I can't speak for previous or newer versions). That's the idea of "Save as type"... To clarify your "Excel Save as ensure there's a BOM", is incorrect. This is the reason I asked a question in the first place! If I open a CSV formatted file that contains a BOM to indicate my file Encoding is UFT-16LE and modify this file via Excel, I expect when I save this file that the Encoding remains in tact... What would be really nice is someone who's experienced these problems before, provide your insight please.