A CSV is the simplest file in computing — values, commas, line breaks, nothing else. Which makes it genuinely strange that opening one is among the most dangerous clicks in Excel. The file is fine; it’s the opening that wrecks it, because double-clicking a CSV invites Excel to guess what everything is — and Excel guesses with confidence.

The greatest hits, every office, every year: phone numbers and account codes lose their leading zeros (07701… → 7701…, because Excel decided they were numbers); the product code MAR1 becomes 1 March; long IDs collapse into scientific notation (8.90051E+15 — and the true digits are gone, not hidden); and £ arrives as £, names like Müller as Müller. None of these are file corruption. All of them are guesses applied at the door.

The two-minute theory

Two facts explain everything above.

Fact one: CSV has no types. Unlike a real workbook, a CSV can’t say “this column is text”. Every value is just characters, and someone must decide what they are. Left to itself, Excel decides by pattern: looks numeric → number (bye, leading zeros), looks date-ish → date (the costume problem’s evil twin), too long → scientific. The fix is never a format applied after — the digits are already destroyed — it’s deciding types at import.

Fact two: text has encodings. Characters are stored as bytes, and there are several dictionaries for the translation. Most modern systems write UTF-8; Excel, opening a bare CSV, sometimes assumes an older dictionary — and every character beyond plain A–Z (£, é, ü, —) turns into the two-character gibberish of a wrong dictionary: £, é. Nothing is lost; it’s being read wrong, and re-reading with the right encoding restores it perfectly.

the file (bytes — always correct) C2 A3 33 34 30 · 4D C3 BC … wrong dictionary £340 · Müller every non-ASCII character doubles into gibberish read as UTF-8 £340 · Müller same bytes, right dictionary — nothing was ever corrupted the file never changes; only the reading does. choose the dictionary at import and the  never appears
£ is not damage — it's one set of bytes read through the wrong dictionary. Import tools let you pick the right one; double-clicking doesn't ask.

The routine: import, never open

So the rule that prevents the whole zoo: don’t double-click CSVs that matter — import them. Data → Get Data → From Text/CSV opens the file through Power Query, which asks the two questions double-clicking skips: File Origin (encoding — 65001: UTF-8 fixes the £) and, in the editor, a type per column — where account codes are declared Text before Excel ever sees them, dates are told their incoming order, and the 16-digit IDs survive intact. Land it in a Table, and — the compounding bonus — the import is now a recipe: next month’s file gets the same treatment by refresh, not by vigilance. (The legacy route, Text to Columns’ step three, does one-off type-setting too — the query does it repeatably.)

Going the other way, two courtesies when you export: save as CSV UTF-8 (the plain “CSV” option on older Excels writes the legacy encoding and inflicts the £ on the next system), and remember the export carries values in their costumes — formulas, formats and everything else that makes a workbook stay behind. CSV is a freight container, not a home.

If a mangled file has already happened to you: leading zeros and long IDs are only recoverable from the original file, re-imported properly — which is the quiet argument for the keep-the-original rule applying to downloads too.

Plainest format in computing; most opinionated doorman. Walk it through Import, answer the two questions, and the £ stays a £.