Character-set restrictions reject valid names

What it is

Unicode-safe name input lets people enter the scripts, combining marks, and separators their names actually use, then preserves them across storage, search, display, and export. An ASCII-only rule—or a regular expression allowing letters and one hyphen—rejects real names containing diacritics, combining marks, apostrophes, spaces, connector characters, non-Latin scripts, or multiple scripts.

Why it happens

One visible grapheme can contain multiple Unicode code points, and visually identical text can have different canonically equivalent sequences. Limits measured in bytes or UTF-16 code units can split surrogate pairs or combining sequences. Names also use Unicode Mark, connector punctuation, and language-specific spacing in addition to Letter. W3C name-internationalization examples cover mononyms, multiword parts, multiple surnames, patronymics, and unspaced names, demonstrating why no global regular expression enumerates valid names. If only the frontend is widened, a narrow database, queue, PDF font, or third-party API merely postpones failure.

Where it stops holding

Accepting Unicode does not mean accepting arbitrary control characters, nor does it make different strings the same person. Normalization, case folding, accent removal, and transliteration can aid search but can alter source text or create collisions; preserve the display value and derive search keys separately. Fraud controls may flag confusables, but mixed scripts alone do not make a name invalid. If a document or payment rail supports a restricted repertoire, collect a disclosed compatibility transliteration in addition to the original instead of overwriting it.

Applying it

• Use Unicode end to end, base user-facing length feedback on extended grapheme clusters, and leave database headroom for encoding and normalization. Never truncate blindly by bytes.
• Permit letters and combining marks across scripts plus common name spaces, apostrophes, and joining punctuation, handling explicitly disallowed control or invisible formatting characters by context. Prevent injection with parameterized queries, contextual output escaping, and safe export—not a name-character blacklist.
• Store the original display value, optional normalized search key, and any authority-required transliteration separately. Record conversion provenance and let users correct automatic transliteration.
• Exercise precomposed and decomposed diacritics, non-BMP characters, hyphen variants, curly and straight apostrophes, unspaced scripts, mixed scripts, and maximum lengths through registration, search, export, email, PDF, and third-party synchronization.

Related

• Same group: S2.05.1 The order and number of name parts are not fixed · S2.05.2 Split name fields can exclude users · S2.05.3 Middle names, patronymics, and suffixes need distinct handling · S2.05.4 Titles and honorifics vary by locale
• Adjacent: S1.03.1 Missing glyphs trigger fallback and change layout · S2.09.1 Regular-expression validation usually embeds a single-locale assumption
• Search terms: Unicode name input · grapheme cluster · name validation