Validação de número é o conjunto de conferências que decide se uma sequência de caracteres pode ser tratada como um número daquela família: quais caracteres aparecem, quantos são e se o dígito final fecha a conta dos anteriores. Neste texto, mostramos as três camadas que compõem essa checagem, por que a ordem entre elas altera o diagnóstico e o que cada resposta permite concluir.
O que é validação de número?
Verificar um número responde a uma pergunta mais estreita do que a maioria das pessoas imagina. Não se pergunta se o número pertence a alguém, se está ativo ou se pode ser usado: pergunta-se se os caracteres digitados formam uma sequência que aquele esquema aceita, seguindo as regras que o próprio esquema publica.
A peça central dessa checagem é o dígito verificador. Trata-se de um ou dois caracteres no fim do número que não identificam nada por conta própria: eles são calculados a partir de todos os que vêm antes, por uma regra pública. Se alguém troca um dígito ao digitar, a conta deixa de fechar e a inconsistência aparece antes de qualquer consulta externa. É por isso que o dígito verificador é barato e eficaz contra erro de transcrição — e é por isso também que ele não protege nada, já que qualquer pessoa que conheça a regra consegue recalculá-lo.
Como o resultado dessa conta varia de esquema para esquema, a resposta honesta nem sempre cabe em duas palavras. Existem, na prática, quatro conclusões distintas: o dígito verificador confere; o formato confere mas o dígito não; o esquema não publica algoritmo e só o formato pode ser confirmado; e não há regra conhecida para aquela entrada. A ferramenta de validação de número desta página mostra essas quatro respostas separadamente, em vez de resumir tudo em um “válido” genérico.
Três filtros em sequência: caracteres, comprimento e dígito verificador
A checagem costuma ser descrita como uma coisa só, mas é feita de três filtros independentes, aplicados em ordem. Cada um deixa passar um tipo diferente de erro, e é a combinação dos três que dá cobertura à verificação.
| Camada | O que ela confere | O que ela deixa passar |
|---|---|---|
| Conjunto de caracteres | Se só aparecem letras, dígitos e símbolos previstos pelo esquema | Um caractere válido colocado na posição errada |
| Comprimento | Quantidade de caracteres, depois de remover os separadores | Um dígito trocado por outro, desde que o total continue correto |
| Dígito verificador | Se os últimos caracteres fecham a conta publicada pelo esquema | Erros que a conta não distingue e toda informação que não está no próprio número |
A ordem importa. Antes de contar caracteres, é preciso normalizar a entrada: remover espaços, hífen, pontos e barras, e tratar letras maiúsculas e minúsculas como equivalentes. Só depois faz sentido perguntar quantos caracteres sobraram e se o conjunto é válido. Com a ordem invertida, um número correto escrito com separadores é reprovado na contagem e a mensagem de erro aponta para o problema errado.
Depois da normalização vêm as três camadas na sequência da tabela. O dígito verificador fica por último de propósito: é o cálculo mais caro e o menos informativo quando a entrada sequer tem o tamanho certo. Rodar a conta em uma entrada com metade dos caracteres produz um “inválido” tecnicamente correto e praticamente inútil.
Vale lembrar que as camadas não têm a mesma força. Conjunto de caracteres e comprimento descrevem apenas a forma; o dígito verificador é a única camada que compara o número com ele mesmo. Quando um esquema não publica algoritmo, a verificação para na segunda camada — e é aí que entra a resposta “apenas formato”, tema do texto sobre números sem dígito verificador.
Por que formato correto não prova que o número existe?
Passar nas três camadas significa uma coisa só: a sequência é internamente consistente segundo a regra publicada. Ela não foi comparada com nenhum cadastro, não foi emitida por ninguém e não carrega informação sobre quem a usa.
A confusão entre consistência e existência está na origem de boa parte dos erros de projeto nessa área. Um número pode ser construído do zero, com o comprimento certo e o dígito verificador calculado corretamente, sem nunca ter existido. Do ponto de vista aritmético ele é indistinguível de um número emitido: os dois fecham a mesma conta, porque a conta só olha para os próprios caracteres.
Saber se um número existe — se foi registrado, emitido ou continua ativo — exige consulta a quem controla o cadastro. Essa é uma operação de outra natureza: mais lenta, dependente da disponibilidade de terceiros, sujeita a limites de uso e capaz de falhar. Misturar as duas coisas no mesmo campo de resposta produz sistemas que dizem “número não existe” quando querem dizer “não consegui conferir agora”.
Por isso, diante de qualquer resultado de verificação, vale a pergunta: o que exatamente foi conferido? Se a resposta é “a conta do último dígito”, é isso e nada mais o que o resultado prova.
Um mesmo número pode pertencer a mais de um esquema
Esquemas diferentes usam comprimentos e conjuntos de caracteres que se sobrepõem. Não é raro que uma mesma sequência satisfaça as regras de dois ou três esquemas ao mesmo tempo, cada um com seu nome e sua finalidade. Isso não é defeito da entrada nem empate a ser resolvido: são várias afirmações verdadeiras sobre a mesma sequência.
Um verificador bem-comportado lida com isso listando os esquemas candidatos, em vez de escolher um. Escolher por conta própria é adivinhar, e adivinhar errado tem custo: o usuário recebe explicação sobre um documento que não é o dele, ou uma mensagem de erro sobre um campo que estava certo. Quando o resultado é uma lista, quem tem o contexto decide qual linha interessa.
Essa característica também explica por que a verificação não deve ficar espalhada pela regra de negócio. Se o sistema assume que determinado comprimento é sempre de um país, ele funciona na maioria dos casos e falha em silêncio no resto. Tratar as famílias de números como dados, e não como suposições embutidas no código, é o que permite conviver com a ambiguidade.
Normalização: espaços, hífen e maiúsculas
Toda interface de digitação recebe variações. As pessoas escrevem números com espaços a cada quatro caracteres, com hífen entre blocos, com pontos e com barras. Alguns esquemas aparecem em maiúsculas em um formulário e em minúsculas em outro, e o mesmo valor volta de uma planilha com formatação diferente da que foi digitada.
Normalizar é reduzir todas essas formas a uma só, antes de qualquer comparação. Os separadores mais comuns — espaço, hífen, ponto e barra — são descartados; letras passam a ser tratadas sem distinção entre maiúsculas e minúsculas. Depois disso, o mesmo número escrito de três maneiras diferentes vira exatamente a mesma sequência, e a verificação passa a dar o mesmo resultado para as três.
Dois cuidados evitam conclusões erradas. O primeiro é que normalizar não corrige erro: se faltou um dígito, nenhuma limpeza de separadores repõe o que não foi digitado. O segundo é que normalizar não é medida de segurança — é padronização de entrada, e não impede que alguém envie um número bem formatado e inventado.
A normalização também é o motivo pelo qual a resposta exibida ao usuário deve mostrar a versão normalizada do número. Quando a mensagem diz que algo está inválido, mostrar exatamente qual sequência foi conferida evita a discussão sobre se o problema estava no número ou na forma como ele foi escrito.
Para quem desenvolve: camadas de uma rotina de verificação
Uma rotina de verificação fica mais fácil de manter quando as etapas são explícitas e separadas, nesta ordem:
- Normalizar a entrada, removendo separadores e igualando maiúsculas e minúsculas.
- Conferir conjunto de caracteres e comprimento contra os esquemas candidatos e guardar quais passaram.
- Calcular o dígito verificador apenas para os esquemas que chegaram até aqui.
- Devolver uma conclusão por esquema, com rótulos distintos: válido, inválido, apenas formato ou sem regra.
- Registrar qual regra foi aplicada e qual era a versão dela, para que a decisão possa ser reproduzida depois.
Duas decisões de projeto economizam manutenção. A primeira é separar verificação de regra de negócio: a checagem responde sobre formato e consistência, e a regra de negócio decide o que fazer com a resposta. A segunda é não transformar a falha em acusação — uma mensagem que diz “formato inválido” é acionável, enquanto “número inexistente” afirma algo que a rotina não tem como saber.
Todos os números mencionados neste texto são exemplos construídos para explicar as camadas de verificação. Nenhum deles corresponde a uma pessoa, uma conta, um documento ou uma empresa real, e nenhum resultado de verificação deve ser tratado como prova de que um número existe ou pode ser utilizado.
Próximos passos
Se a sua dúvida é como as contas por trás do dígito verificador variam entre famílias, o texto sobre algoritmos de dígito verificador compara mod-10, mod-11 e mod-97 sem entrar em parâmetros de nenhum país. Para ver as quatro conclusões aplicadas a uma entrada sua, cole o número na ferramenta de validação de número e observe o que ela lista.