Seu sobrenome contém caracteres inválidos (2010)
Sistemas de software rotineiramente rejeitam ou deformam nomes pessoais perfeitamente válidos, desde monônimos e sobrenomes curtos de uma letra até nomes com hífens, diacríticos, scripts não latinos ou capitalização incomum. Comentadores compartilham falhas do mundo real em grande escala — passagens aéreas, logins bancários, documentos governamentais, sites de hotéis e mainframes legados — que obrigam as pessoas a soletrar errado ou truncar seus próprios nomes, ou a serem tratadas como fraudulentas. Um tema recorrente é que regras rígidas de validação e suposições centradas em ASCII não apenas refletem um mau projeto técnico (por exemplo, falta de suporte a Unicode), mas também deslocam a culpa para os usuários em vez de reconhecer as limitações do sistema.
Suposições e inverdades sobre nomes
- Muitos exemplos mostram que suposições comuns de software estão erradas: pessoas podem ter um único nome, vários sobrenomes, nenhum sobrenome, monônimos, nomes muito curtos (1–2 letras) ou múltiplos “nomes completos”.
- Divisões rígidas de primeiro/último nome, ordem imposta e regras de tamanho mínimo falham rotineiramente.
- Sistemas frequentemente insistem que o nome informado “deve corresponder ao documento”, ao mesmo tempo em que rejeitam caracteres que de fato aparecem nos documentos.
Limitações técnicas: codificações e validação
- Nomes com acentos, diacríticos, ß, ø, ć, tremas e caracteres de alfabetos não latinos frequentemente quebram formulários, bancos de dados e sistemas downstream.
- Frontends podem aceitar Unicode, mas os backends silenciosamente truncam, recodificam ou rejeitam, causando correspondência de registros falha, perda de correspondência ou falhas de login.
- Codificações legadas (EBCDIC, antigas páginas de código de 8 bits, variantes de largura metade/largura total no japonês) e restrições da era dos mainframes ainda impulsionam regras de “somente ASCII”.
- Alguns discutem se os sistemas deveriam permitir praticamente todo Unicode e simplesmente remover caracteres de controle/separadores de linha; outros observam que a integração com sistemas não Unicode ou externos (postal, companhias aéreas, governo) complica isso.
Companhias aéreas, bancos e sistemas governamentais
- Companhias aéreas são infratoras frequentes: rejeitando certos caracteres, truncando nomes, tratando mal a transliteração (por exemplo, umlaut → ue vs u, ø → o vs oe) ou tratando substrings como obscenidades (problemas do tipo Scunthorpe).
- Verificações de segurança muitas vezes dependem do senso comum humano para conciliar divergências entre bilhete, passaporte e limitações do backend; às vezes isso falha e cria grande transtorno.
- Bancos, repartições de impostos e registros oficiais comumente removem diacríticos, deformam espaços/hífens ou impõem campos curtos demais.
Convenções culturais e legais de nomes
- Vários posts descrevem regras específicas por país: sufixos obrigatórios marcados por gênero, conjuntos de caracteres restritos para nomes legais e representações oficiais apenas em kanji ou katakana.
- Essas regras colidem com scripts estrangeiros, nomes do meio e diferentes convenções de ordem, especialmente em contextos transfronteiriços.
Contornos e estratégias de adaptação dos usuários
- Muitas pessoas “anglicizam” ou transformam seus nomes em ASCII, removem pontuação ou nomes do meio, ou mantêm múltiplas grafias (para companhias aéreas, bancos, cafeterias).
- Alguns registram aliases ou formas legais abreviadas especificamente para evitar falhas de software.
- Uma frustração recorrente não é apenas a falha técnica, mas sistemas e funcionários insinuando que o nome da pessoa é “inválido”, em vez de reconhecerem as limitações do software.