Gerador de Nomes brasileiros

Um cadastro preenchido com Teste Teste passa em tudo. São onze caracteres ASCII, nenhum acento, nenhuma ambiguidade de ordenação e exatamente o mesmo número de bytes e de caracteres. Nada ali pressiona o caminho que o texto percorre entre o formulário, o driver do banco, a coluna, o índice, o relatório em PDF e o arquivo de integração. A primeira vez que esse caminho vê Vinícius Guimarães Araújo costuma ser em produção.

O que esta ferramenta produz é deliberadamente simples: um prenome sorteado de uma lista separada por sexo, mais um ou dois sobrenomes tirados de uma lista comum aos dois — a maior parte dos nomes sai com dois, o restante com um. Não há partículas em minúsculas (de, da, dos) nem prenomes compostos, e a cedilha não aparece nas listas. Se o seu caso de teste depende desses formatos, gere o lote e edite algumas linhas à mão: o valor da massa está em ter variedade de acentuação e de comprimento sem precisar inventá-la linha a linha.

Acento ocupa mais bytes do que caracteres

Conceição tem nove caracteres e onze bytes em UTF-8, porque ç e ã ocupam dois bytes cada. Todo limite contado em bytes — campo de largura fixa em arquivo de integração, coluna declarada com semântica de byte, chave com teto em bytes — corta no meio de um caractere de dois bytes e entrega uma sequência inválida adiante. O sintoma raramente aparece onde o corte aconteceu: vira um losango com interrogação na tela, ou uma exceção de decodificação três camadas depois. A correção é truncar por caractere e reservar folga no limite, não contar tudo como se fosse ASCII.

O primo desse problema é o texto lido com a codificação errada. Bytes UTF-8 interpretados como latin-1 transformam João em João, e a gravação seguinte consolida o estrago no banco. Os pontos clássicos são a exportação de CSV e o charset da conexão do driver divergindo do charset da coluna — nenhum dos dois se manifesta sem acento na massa.

Ordenação alfabética não é ordem de bytes

Em JavaScript, ["Ávila", "Alves", "Zuza"].sort() devolve Ávila em último lugar. O sort padrão compara unidades UTF-16, e Á (U+00C1) vem depois de Z (U+005A). Para listagem exibida a usuário o comparador precisa ser new Intl.Collator("pt-BR").compare, que trata a vogal acentuada como a mesma letra base. No banco a decisão é da collation da coluna: uma collation binária ou C ordena pelo byte e produz exatamente o mesmo defeito no ORDER BY. Uma amostra só com nomes sem acento nunca revela isso, porque nela as duas ordens coincidem.

Normalização Unicode: dois nomes idênticos que não são iguais

O mesmo nome pode chegar em duas formas Unicode diferentes. Na forma composta (NFC), o é é um caractere só; na decomposta (NFD), é a letra e seguida de um acento combinante. As duas renderizam igual na tela e são diferentes para qualquer comparação de string, para o length e para o índice único.

const nfc = "Jos\u00E9";   // "é" em um único caractere (U+00E9)
const nfd = "Jose\u0301";  // "e" + acento combinante (U+0301)

nfc === nfd;   // false — mas os dois aparecem como "José" na tela
nfc.length;    // 4
nfd.length;    // 5

// Normalize na borda do sistema, antes de comparar, gravar ou indexar
nfc === nfd.normalize("NFC");   // true

// Chave de busca sem diacrítico: decompõe e descarta os acentos
const chave = (s) =>
  s.normalize("NFD").replace(/\p{Diacritic}/gu, "").toLowerCase();

chave("Conceição Guimarães");   // "conceicao guimaraes"

A regra prática é normalizar na borda — ao receber, uma vez — e guardar sempre na mesma forma, de preferência NFC. Para busca tolerante a acento, mantenha uma coluna ou índice funcional com a chave sem diacríticos em vez de aplicar a transformação a cada consulta: assim o índice continua sendo usado.

Collation do banco erra nos dois sentidos

As armadilhas são simétricas e igualmente comuns. Uma collation insensível a acento trata José e Jose como o mesmo valor: o índice único recusa um cadastro legítimo e o where nome = 'Jose' traz o registro acentuado sem que ninguém tenha pedido. Uma collation sensível a acento faz o inverso: a busca por Jose não encontra José, e o atendente conclui que o cliente sumiu da base. O mesmo vale para a cedilha na comparação sem distinção de caixa, em que ç e c podem ou não colapsar no mesmo caractere.

Nenhum dos dois comportamentos é defeito do banco: são consequência de uma escolha de collation que normalmente ninguém fez de propósito. Gerar um lote de nomes acentuados e rodar inserção, busca e ordenação em cima dele expõe qual das duas se aplica ao seu ambiente. O restante da estratégia de massa de teste, incluindo seeds determinísticos e fixtures versionados, está em massa de dados de teste: fixtures, seeds e faker.

Um gerador de nomes resolve um problema estreito: produzir texto humano plausível, em português, em quantidade. Vale usar quando é isso que falta.

• Seeds e fixtures de ambientes de desenvolvimento, no lugar de sequências como usuario1 e usuario2, que escondem problemas de largura de coluna e de ordenação.
• Telas, relatórios e capturas de documentação, em que uma lista de nomes verossímeis mostra o layout real — inclusive o que acontece com um nome de quarenta caracteres numa célula estreita.
• Testes de busca e de ordenação, exatamente pelas razões da seção anterior.
• Demonstrações para clientes, para não exibir a base de produção em tela compartilhada.

Não é a ferramenta certa nestes casos:

• Como identificador. Nome não é chave. Dois registros com o mesmo nome são normais, e a combinação aleatória aqui repete com frequência maior do que a intuição sugere. Para identificar pessoa física, o campo é o CPF.
• Quando você precisa controlar as colisões. Testar deduplicação ou merge de cadastros exige pares construídos de propósito — com e sem acento, com e sem sobrenome do meio —, não sorteio.
• Como substituto de anonimização. Trocar nomes reais por nomes sorteados em uma cópia de produção não torna a base anônima: o restante das colunas continua reidentificando as pessoas. O que a LGPD pede e o que isso implica para ambientes de teste está em LGPD e dados de teste.