Find&Close Help centre
Go to website
/

Results appear as you type. Use the up and down arrow keys to move through them and Enter to open one.

Accented characters look wrong when I open the CSV in Excel

Østre Aker instead of Østre Aker. Our file is correct UTF-8 with a BOM — this is Excel’s import behaviour, and there are three reliable fixes.

You open the export and see Østre Aker where it should say Østre Aker, or Café for Café. This is called mojibake, and it is an encoding mismatch rather than bad data.

The file is fine

Our CSV is UTF-8 with a byte-order mark. The BOM is three bytes at the very start whose only job is to tell a program "this is UTF-8". We include it specifically because Excel needs it.

You can prove the file is correct in one move: open it in any text editor, or in Google Sheets, or in Numbers. If the accents are right there, nothing is wrong with the export.

Why Excel still gets it wrong sometimes

Excel honours the BOM when you open a .csv file. It ignores it in some other paths — legacy Data → From Text, files renamed from .txt, and older Excel for Mac builds, which fall back to the system's legacy code page and produce exactly this result.

Three fixes, best first

1. Export XLSX instead

Choose XLSX in the export dialog. It carries encoding and types inside the file, so there is no import step to get wrong — and it costs exactly the same credits, because a credit buys a business, not a format. If a colleague will open the file in Excel, this is the answer. Choosing a format.

2. Import with the encoding set explicitly

In Excel, use Data → Get Data → From Text/CSV rather than double-clicking the file. In the preview pane set File Origin to 65001: Unicode (UTF-8) and set the delimiter to comma. The preview updates live, so you can see the accents come back before you press Load.

3. Open it somewhere that gets it right

Google Sheets, LibreOffice Calc and Numbers all read UTF-8 correctly without configuration. Google Sheets: File → Import → Upload, then choose "Replace spreadsheet".

Do not "fix" it with find-and-replace

Repairing mojibake by substituting characters produces a file that looks right and is subtly wrong — and any row you did not spot stays broken. Re-open the original with the correct encoding instead. The source file is fine.

The other Excel problem: mangled numbers

Excel also likes to reinterpret data on import. Two to watch for in our files:

  • Phone numbers. +47 22 42 45 40 can be read as a formula or stripped to a number. In the import preview, set the Phone and Phone international columns to Text.
  • Postal codes with leading zeros. 0181 becomes 181 unless Postal code is set to Text.
  • Reviews count is a band, not a number. 1-50 can be read as a date. Set that column to Text too.

XLSX avoids both. So does importing with the column types set explicitly.

If the accents are wrong in a text editor too

Then it is worth telling us. Send the export id to support@findandclose.com — see reporting a record. This would be a genuine bug rather than an import setting, and we would want to know.

Updated on:

Was this article helpful?

Related articles