My CSV shows é where it should show é

Names and addresses are full of sequences like é, ü, or ’ where accented letters, umlauts, and apostrophes should be. Sometimes there are question marks or black diamonds instead.

Why this happens

• Text on disk is bytes, and the same bytes mean different characters under different encodings. The file was written as UTF-8, where é is two bytes, and read as a single-byte encoding such as Windows-1252, where those two bytes are à and ©. Nothing is corrupt; the file is being read in the wrong alphabet.
• Excel is the usual site of the mismatch because opening a CSV by double-clicking uses a system default rather than asking. The same file opened through the import dialog, with UTF-8 chosen, reads correctly.
• The question marks and diamonds are a different and worse case. There the conversion has already happened and the original character was replaced by a placeholder, so the information is gone rather than merely misread.
• A byte order mark at the start of the file is the usual peace offering: a few bytes that announce the encoding. It helps Excel and shows up as a stray character in tools that do not expect it, which is its own small problem.

What to do right now

• Reopen the original file rather than repairing the text. Data → From Text/CSV, then set File Origin to UTF-8, and the accents come back with no editing at all.
• Ask for the export as UTF-8 with a byte order mark if the sender's tool offers it. That one setting removes this problem permanently for that sender.
• Do not repair mojibake with find-and-replace. There are hundreds of these pairs, you will fix the common ones, and the long tail will survive into whatever you build on top of the data.
• If the file already contains question marks or diamonds, ask for it again. That form is genuinely lossy and no amount of processing brings the characters back.

Stopping it on the next file

The byte order mark is stripped on the way in, so it never arrives as a stray character in your first column. Beyond that, be clear about what a schema can and cannot see: mojibake is valid text, so a text field accepts “é” exactly as an enthusiastic parser handed it over, and no type check will flag it. Where it does get caught is on a field with a fixed set of options, because a mangled value no longer matches any of them and is refused by name.

The contact list template is a sheet with those rules already set, if you want to see the shape of one before building your own.