Gerador de CNH (número de registro)

A CNH traz mais de um número impresso, e o campo que um cadastro pede quase sempre é o registro. Trocar um pelo outro é a origem mais comum de bug em formulário de motorista: ou o sistema rejeita um número correto, ou aceita e grava como identificador do condutor algo que muda na renovação seguinte.

Número de registro

Identifica o condutor no cadastro nacional. É atribuído na primeira habilitação e acompanha a pessoa daí em diante: renovar a carteira, acrescentar categoria ou transferir o cadastro para outro estado não muda o registro. São onze dígitos — nove de base e dois verificadores —, e é o único dos três números com uma fórmula pública de verificação, razão pela qual é o único que um gerador consegue produzir de maneira conferível.

Número do espelho

Identifica a via emitida, não a pessoa. Cada renovação ou segunda via gera um espelho diferente, de modo que o mesmo condutor acumula vários ao longo dos anos. Serve para rastrear o documento físico; usá-lo como chave do motorista no banco quebra na primeira troca de carteira.

RENACH

A sigla nomeia o Registro Nacional de Condutores Habilitados, mas no dia a dia “o RENACH” costuma designar o número do processo aberto no DETRAN — o que a pessoa usa para acompanhar exames, aulas e prova enquanto ainda não tem a carteira. Combina a sigla do estado com uma sequência numérica e pertence ao processo, não ao condutor: abrir um novo processo em outro estado produz outro RENACH. Não siga o módulo 11 para validá-lo — a regra do registro não vale aqui.

O guia número da CNH: registro, espelho, RENACH e o dígito verificador mostra onde cada um aparece no documento e o que muda na versão digital da carteira.

Duas implementações de DV de CNH circulam há anos em código copiado entre projetos. A desta ferramenta é a convenção clássica descrita acima: pesos 9→1 e 1→9, o resto vira o dígito, resto 10 vira 0 e o desconto de 2 no segundo cálculo quando o primeiro resto foi 10. A outra, comum em bibliotecas JavaScript, usa pesos 2 a 10 no primeiro cálculo com dígito igual a 11 menos o resto, e pesos 3 a 11 mais 2 no segundo, já incluindo o primeiro verificador na conta.

Fora do caso do resto 10 as duas concordam sempre, e sempre aqui é literal: varrendo todas as bases de nove dígitos — um bilhão de combinações — não existe uma única divergência fora dessa faixa. A diferença de pesos se cancela na aritmética modular.

A faixa de risco, o resto 10 no primeiro cálculo, cobre cerca de uma base a cada onze. Mas ela não é uma zona de desacordo inteira: lá dentro as duas convenções ainda fecham o mesmo par de dígitos na maioria dos casos. O desacordo se concentra em três dos onze valores possíveis do segundo resto — 0, 1 e 10 —, o que dá 3 bases em cada 121, cerca de 2,5% do total, ou uma a cada quarenta. Nos outros oito valores o resultado é idêntico.

Quando o desacordo aparece, porém, ele é radical, não uma questão de um dígito para cima ou para baixo. Tome a base 987654321. Pela convenção clássica, a primeira soma dá 285 e deixa resto 10; o primeiro dígito vira 0 e o segundo cálculo (soma 165, resto 0) recebe o desconto, chegando a −2 — ou seja, essa base não tem DV válido. Pela outra convenção, a mesma base produz 09, e 98765432109 passa sem reclamação. Nos segundos restos 0 e 1 a disputa é sempre essa, “sem DV” contra um número aceito; no resto 10 as duas fecham dígitos diferentes — 00 pela clássica, 08 pela outra.

Por isso o gerador descarta a faixa inteira, todas as bases cujo primeiro resto é 10, em vez de filtrar só os três restos problemáticos: é um critério mais simples e sobra margem se uma terceira implementação aparecer. Perde-se cerca de 9% do espaço possível para eliminar 2,5% de casos ambíguos, e em troca todo registro que sai daqui é aceito pelas duas famílias. Se você precisa justamente testar esse caso-limite, monte a base à mão: qualquer sequência de nove dígitos cuja soma ponderada por 9…1 deixe resto 10 serve, e os segundos restos 0, 1 e 10 são os que separam os validadores. Outras armadilhas do mesmo tipo estão reunidas em erros comuns em validadores de documentos, e a mecânica do módulo 11 está no guia do algoritmo.

Faz sentido

• Popular seeds e fixtures de cadastro de motorista — mobilidade, entrega, frota, locadora — em que o campo precisa passar pela validação antes de o teste seguir adiante. O guia de massa de dados de teste trata de como manter esse lote estável entre execuções.
• Exercitar o formulário: gere um número válido, troque o último dígito e confira se a mensagem de erro aparece. Vale testar também comprimento diferente de 11 e entrada com letras.
• Conferir importações em lote. Um CSV com dezenas de registros distintos revela travas de unicidade e deduplicação que um mesmo número repetido esconde.
• Capturas de tela, demonstrações e documentação, sem expor a carteira de ninguém.

Não serve

• Preencher cadastro real, formulário de órgão público ou qualquer sistema de trânsito. Número fictício em cadastro real é fraude, e o fato de ter saído de uma ferramenta não muda isso.
• Deduzir categoria, validade, restrições médicas, pontuação ou estado emissor. Nenhum desses atributos está no número — eles vivem no cadastro, e a consulta oficial é o único caminho.
• Concluir que um condutor existe. DV correto significa apenas que os onze dígitos são internamente consistentes, o mesmo limite que vale para CPF válido e CPF existente.
• Justificar a permanência de CNHs reais em ambiente de desenvolvimento. Substituí-las por números gerados é o objetivo; manter as verdadeiras “só em homologação” continua sendo tratamento de dado pessoal, como explica o guia LGPD e dados de teste.

Como guardar o campo

Armazene o registro como texto de comprimento fixo, nunca como inteiro: bases com zero à esquerda são perfeitamente possíveis e um campo numérico devolveria dez dígitos. A CNH não tem máscara oficial como o CPF, então guarde os onze dígitos crus e deixe a formatação para a camada de exibição. E valide no servidor: máscara de front-end cuida da digitação, não da integridade do dado que chega na API.