Google Maps to CSV: the encoding and delimiter traps

How do you export Google Maps data to CSV?

Lead Finder writes CSV directly, and the format choices in that file determine whether the list survives being opened, imported and passed between systems. Three properties matter more than any other. Encoding must be UTF-8, because business names routinely contain accented and non-Latin characters that become unreadable in a legacy encoding, and that damage is irreversible once saved. Delimiters must be handled with proper quoting, because addresses contain commas as a matter of course and an unquoted address splits into several columns, silently shifting every field after it. And embedded line breaks, common wherever a business has typed a multi-line address, must be quoted too or a single record becomes two broken rows.

Encoding: why UTF-8 is not optional

A city sweep in almost any market returns business names with accents, and in many markets names in non-Latin scripts. Saved in a legacy single-byte encoding, those characters are replaced or mangled, and reopening the file in UTF-8 afterwards does not recover them because the information is gone.

The failure is quiet, which is what makes it dangerous. Nothing errors, the file opens, and a proportion of business names are subtly wrong in ways that only show up when someone tries to match them against another system or reads them aloud on a call.

Delimiters and quoting

Addresses contain commas by design, so a comma-delimited file has to quote them. Without quoting, one address becomes several columns and every field to its right shifts, which corrupts the row without producing any error message.

Quotes inside quoted fields need escaping too, which matters because business names include them more often than expected, particularly nicknames and trading names. A file that survives export but breaks on reimport almost always fails on one of these two rules.

Line breaks inside fields

Multi-line addresses are common, and a raw newline inside an unquoted field turns one record into two, one of which has too few columns. Most parsers then either error or, worse, accept both rows and produce a list with phantom entries.

Checking the row count after export against the count the tool reported is a cheap way to catch this. A discrepancy means fields are breaking, and the file needs fixing before anything downstream touches it.

Related reading: the full export workflow , what changes when Excel opens it .