That's not my name

Bård Aase opens with a personal problem: his Norwegian name, which contains a letter outside basic ASCII, keeps arriving mangled in marketing emails, receipts, and greetings from banks and vendors. That sets up a tour of how text is stored as numbers, and why plain text carries no label saying which encoding it uses.

The middle of the talk walks through recurring failure patterns. UTF-8 bytes are often read as Latin-1, Windows code page 1252 or Mac Roman, and text can be re-encoded each time it passes through another system, so one letter turns into two or more characters. He shows how old code pages, HTML's handling of ISO 8859-1, and the Angstrom sign, which many applications silently convert, produce familiar errors. He also covers how one visible character can be built from combining marks in different byte orders, and how the UTF-16 byte order mark can leak into files.

The closing discussion moved to passwords and security. A listener reported a Norwegian bank login that worked from a phone but not from a PC, apparently because of combining characters. Aase also noted that lookalike Unicode characters can make a spoofed domain appear to match a real one. The practical takeaways are to treat text input as untrusted, normalise it consistently, and state the expected encoding explicitly at every system boundary.