Um Número Em Que O Algarismo Da Dezena Seja 6

Sobre números com dezena 6

A gente sempre precisa lidar com isso de alguma forma. Seja num formulário que pede CPF, num código de barras, num registro contábil. Um número em que o algarismo da dezena seja 6 é simplesmente qualquer valor inteiro cuja segunda posição da direita para a esquerda é igual a 6. Vai de 60 a 69, de 160 a 169, de 1.060 a 1.069 e assim por diante. A regra é sempre a mesma, mas o jeito como ela aparece na prática varia bastante dependendo do contexto. O método mais direto é dividir o número por 10 e olhar o resto da divisão por 10. Se o quociente terminar em 6, ou seja, se você pegar o número, dividir por 10, pegar a parte inteira e verificar se o resto é 6, então está certo. Mas na prática eu raramente faço conta manual. Eu pego o número como string e acesso a posição segunda. É mais rápido e quase impossível errar. No Brasil, isso aparece com frequência quando você trabalha com código de barras do Bradesco ou Itaucard, onde o dígito verificador da dezena tem peso diferente dos outros. Já vi gente gastar meia hora conferindo um boleto inteiro porque ignorou que a dezena precisava ser 6 num campo específico do layout.

Um caso que deu trabalho

Ano passado eu precisei validar um lote de cerca de 4.000 registros de um sistema legado que gerava números de protocolo com formatação fixa. O relatório que o cliente pediu dizia especificamente que o número tinha que ter o algarismo da dezena igual a 6. O problema é que o sistema antigo gravava o número como texto e, em alguns registros, os espaços em branco ou zeros à esquerda alteravam completamente a posição que eu deveria verificar. Eu pensei que seria trivial — só checar a segunda posição da direita. Mas os dados vinham com variáveis de comprimento, então o que parecia ser o dígito errado era só um registro menor com preenchimento invisível. A solução foi normalizar todos os valores para uma string de comprimento fixo usando zfill antes de fazer qualquer verificação. Depois disso, apliquei a lógica de pegar o caractere na posição len(str_number) - 2 e comparar com '6'. O lote inteiro passou a validar em cerca de 3 minutos usando um script Python simples, contra as 2 horas que eu estimava no início.

Armazenamento e exibição

Quando você armazena esses números, o ideal é tratá-los como inteiros internamente. O erro mais comum que eu vejo é guardar como texto e esquecer que comparações lexicográficas não funcionam do jeito que todo mundo espera. "60" é menor que "7" nessa lógica, o que quebra filtros e ordenações em bancos de dados sem aviso prévio. Se precisar de formatação fixa para exibição — como em relatórios ou planilhas — use formatação de string com zero à esquerda, mas mantenha o valor numérico separadamente. Se você está montando uma query SQL para selecionar todos os registros onde o algarismo da dezena é 6, não use LIKE '%6_' com a suposição de que o underscore resolve. O underscore corresponde a exatamente um caractere, sim, mas se o seu campo tem tamanho variável ou pode vir com caracteres não numéricos, a coisa quebra rápido. O jeito seguro é usar módulo: (FLOOR(numero / 10)) MOD 10 = 6

Isso funciona independentemente do tamanho do número e não depende de formatação de string. Em PostgreSQL, por exemplo, essa expressão é rápida e utiliza índice se o campo for inteiro. Em MySQL com campos VARCHAR, o cast implícito pode matar a performance em tabelas grandes. Nesses casos, o ideal é adicionar uma coluna computada ou um trigger que mantenha o dígito da dezena separado, facilitando indexação.

Quando essa abordagem falha

Não adianta fingir que é sempre simples. Existem cenários em que contar a dezena como 6 é irrelevante ou até enganoso. Números negativos, por exemplo — a convenção de sinal interfere na contagem posicional se você não tomar cuidado. Outro ponto: moedas estrangeiras com notação reversa, como alguns formatos japoneses ou árabes, podem confundir quem está acostumado com a escrita ocidental. E se o campo que você está tratando não é estritamente numérico — um código alfanumérico, por exemplo — forçar a leitura do algarismo da dezena vai dar resultado aleatório. Se o seu volume de dados for muito grande e você precisar filtrar frequentemente por esse critério, considere criar uma camada de normalização antes de qualquer processamento. Dados sujos de entrada, mesmo que venham de uma API confiável, costumam ter inconsistências que passam despercebidas até o relatório final ser gerado e algum número estar errado. Eu aprendi isso na mão quando um relatório mensal de vendas ficou divergente por três meses seguidos — o problema era que o sistema de origem às vezes enviava o código do produto com um hífen extra, deslocando todos os dígitos e fazendo a dezena parecer 6 quando na verdade não era.

Alternativas práticas

Se a validação por dezena é só um dos requisitos e o número em si precisa de outras verificações — como dígito verificador, tamanho fixo ou intervalo — combine as regras em uma única função de validação. Dessa forma você evita múltiplas passagens pelos dados e centraliza a lógica. Uma única função que retorne true ou false, com logs detalhados dos registros rejeitados, economiza tempo de depuração e ainda gera um histórico útil para ajustar tolerâncias caso algo mude no formato de entrada. O que funciona bem na maioria dos casos é manter os dados brutos intactos e aplicar transformações somente na camada de apresentação ou validação. Isso evita que um problema de formatação se propague para baixo e contamine outras consultas ou relatórios que dependem do mesmo campo.