Your last name contains invalid characters (2010)
Software systems routinely reject or mangle perfectly valid personal names, from single-letter mononyms and short surnames to names with hyphens, diacritics, non-Latin scripts, or unusual capitalization. Commenters share extensive real-world failures – airline tickets, bank logins, government IDs, hotel sites, and legacy mainframes – that force people to misspell or truncate their own names, or be treated as fraudulent. A recurring theme is that rigid validation rules and ASCII-centric assumptions not only reflect poor technical design (e.g. lack of Unicode support), but also shift blame onto users instead of acknowledging system limitations.
Assumptions and Falsehoods About Names
- Many examples show common software assumptions are wrong: people may have one name, multiple family names, no family name, mononyms, very short names (1–2 letters), or multiple “full” names.
- Rigid first/last-name splits, enforced order, and minimum length rules routinely fail.
- Systems often insist the entered name “must match ID” while simultaneously rejecting characters actually present on IDs.
Technical Limitations: Encodings and Validation
- Names with accents, diacritics, ß, ø, ć, umlauts, and non-Latin scripts frequently break forms, databases, and downstream systems.
- Frontends may accept Unicode but backends silently truncate, re-encode, or reject, causing lost mail, mismatched records, or login failures.
- Legacy encodings (EBCDIC, old 8‑bit code pages, half/full-width variants in Japanese) and mainframe-era constraints still drive “ASCII only” rules.
- Some discuss whether systems should allow nearly all Unicode and simply strip control/line-separator characters; others note integration with non-Unicode or external systems (postal, airline, government) complicates this.
Airlines, Banks, and Government Systems
- Airlines are frequent offenders: rejecting certain characters, truncating names, mishandling transliteration (e.g., umlaut → ue vs u, ø → o vs oe), or treating substrings as obscenities (Scunthorpe-type problems).
- Security checks often rely on human common sense to bridge mismatches between ticket, passport, and backend limitations; sometimes this fails and creates significant hassle.
- Banks, tax offices, and official registries commonly drop diacritics, mangle spacing/hyphens, or enforce too-short fields.
Cultural and Legal Naming Conventions
- Several posts describe country-specific rules: mandatory gendered suffixes, restricted character sets for legal names, and official kanji-only or katakana representations.
- These rules collide with foreign scripts, middle names, and different ordering conventions, especially in cross-border contexts.
User Workarounds and Coping Strategies
- Many people “Anglicize” or ASCII‑ize their names, drop punctuation or middle names, or maintain multiple spellings (for airlines, banks, coffee shops).
- Some register aliases or shortened legal forms specifically to avoid software breakage.
- A recurring frustration is not just the technical failure, but systems and staff implying the person’s name is “invalid,” rather than acknowledging software limitations.