Why a German CSV opens as one column — and what 1.234 means

What a German file usually looks like

Saved by a spreadsheet set to German (Germany), the file has a semicolon between the fields, a comma as the decimal mark and a full stop between thousands, so one thousand two hundred and thirty-four and a half is written 1.234,56. Dates are written DD.MM.YYYY: the last day of 2026 is 31.12.2026.

The separator is not a character any of the numbers contain, so nothing in the file needs quoting to survive — which is exactly why the amounts and the fields can be told apart at all.

None of this is a rule the file carries with it — there is no country written inside a CSV. It is what the program that wrote the file was set to, which is why every tool here reads the bytes and says what it found rather than trusting a flag.

The number that means two different things

Written in a German file, 1.234 is one thousand two hundred and thirty-four. Read by a program expecting the English convention it is one point two three four — a thousand times smaller, with no error and nothing to notice. That single ambiguity is why a German CSV cannot be converted by replacing characters: whether the full stop is a thousands mark or a decimal point depends on what wrote the file, not on the character.

The delimiter fixer here resolves it the only way that is safe, by the shape of the whole column. A column qualifies for conversion when nearly every value in it reads as a number under the German rules; then 1.234,56 becomes 1234.56 and a bare 1.234 becomes 1234, because in a German file that is what it means. A column of prose that happens to contain 12,5 never qualifies, so it is never touched.

The count of rewritten values is shown before you download, and the conversion can be switched off entirely — the separator is still fixed and every value is carried across exactly as written.

The other two things in the file

Older German exports are often Windows-1252 rather than UTF-8, which is why Müller arrives as Müller. The fixer decodes by what the bytes actually are and writes clean UTF-8, so the umlaut survives the trip rather than being repaired by hand afterwards.

Dates written 31.12.2026 are unambiguous — no month goes above twelve in that position and the dots are not the English separator — so nothing reads them backwards by accident. They are still text to every tool until something reads them; the SQL console turns the column into real dates with strptime and the pattern from the paragraph above.