Escreva Com Algarismo Os Seguintes Números

Convertendo números por extenso em algarismos: o que funciona na prática

Muita gente acha que transformar "trezentos e quarenta e dois mil, seiscentos e cinquenta e sete" em 342.657 é coisa de criança. É. Mas a primeira vez que você precisa fazer isso em larga escala — num contrato, numa planilha fiscal, numa documentação jurídica — percebe rápido que o português tem pegadinhas que não aparecem num exercício de caderno escolar. O processo básico é simples: você lê a parte inteira, depois a parte decimal (se houver), e monta o número posicionando cada ordem. O problema é que a língua portuguesa permite variações regionais e gramaticais que quebram soluções automáticas ingênuas. Vou mostrar como eu lido com isso. Regra 1: O "e" é seletivo. Em português padrão, usa-se "e" apenas para ligar unidades dentro de cada centena, nunca entre ordens maiores. "Duzentos e trinta" é correto. "Duzentos mil e trezentos" é um erro comum — o certo seria "duzentos trezentos mil". Na prática, eu vejo essa confusão todo dia. Já corrigi mais de cem linhas em processos judiciais por causa desse "e" sobrando.

Regra 2: Plurais mudam a estrutura. "Mil" fica invariável, mas "milhão" varia. "Dois milhões, quinhentos e vinte mil" está certo. "Dois milhões e duzentos e vinte mil" também se ouve muito, e nesse caso específico a variante coloquial é tolerada em contextos informais, mas em documentos formais o melhor é seguir a norma culta. Eu prefiro sempre a forma normativa quando o texto vai para contrato ou declaração fiscal. Regra 3: A casa decimal tem sua própria lógica. "Vinte centavos" vira 0,20. "Três reais e cinquenta e oito centavos" vira 3,58. O detalhe que todo mundo erra: se o texto diz apenas "vinte centavos", o valor inteiro é zero. Já recebi extratos com "cento e cinquenta centavos" que precisavam ser convertidos para 1,50, e não 0,150 — aí o contexto financeiro era essencial para não gerar uma divergência de duas ordens de grandeza.

Um caso que quase me custou um prazo

Estava digitando valores de uma certidão de óbito para um inventário. A escriturária tinha transcrito o valor como "hum milhão, quatrocentos e sessenta e um mil, oitocentos e sessenta e oito". Notei algo estranho: a vírgula antes de "oitocentos" sugeria uma quebra de entonação que, na verdade, indicava uma construção regional onde o falante separava o agrupamento dos milhares do resto. Normalmente isso não muda o número, mas me fez checar se não havia ambiguidade com "hum milhão quatrocentos e sessenta e um mil e oitocentos e sessenta e oito" — que seria 1.461.868 — versus outra leitura possível. Fiz a verificação cruzada com o documento original e confirmei que a vírgula era apenas fonética, não estrutural. O valor era 1.461.868. Esse tipo de atenção evita erro de digitação em valores grandes, que é exatamente o tipo de erro que dá trabalho pra corrigir depois. "Vintém" vs. "vinte": Em algumas regiões do interior, especialmente no Nordeste, "vintém" ainda aparece no discurso cotidiano. Ele não tem relação com a moeda desvalorizada; é simplesmente "vinte". Se você for processar um texto transcrito manualmente, pode encontrar "vintém e seis" e interpretar errado. "Meio" como decimal: "Vinte e meio reais" é 20,50. O algoritmo precisa reconhecer que "meio" seguido de "real" (no singular) indica metade, não 0,5 separado. Confundir isso gera 20,005 ou até 0,50 dependendo da implementação.

Números compostos com hífen: A nova ortografia eliminou o hífen em compostos como "sessentaeum" (61). Antes era "sessenta e um". Sistemas legados que ainda esperam o padrão antigo podem falhar na tokenização. Se você estiver desenvolvendo um parser, mantenha as duas variantes no dicionário. Ordinais disfarçados: Às vezes aparece "primeira parcela no valor de trezentos e vinte e cinco reais". O "primeira" não é parte do número. O valor é 325,00. Já vi processadores tentarem incluir ordinal na conversão porque confundiram a estrutura sintática. Separe sempre o numeral cardinal do ordinal antes de converter.

Alternativas quando a conversão manual não é viável

Para volumes pequenos, revisar manualmente com atenção às regras acima resolve em minutos. Para batches grandes — digamos, mais de duzentas linhas num único arquivo — a abordagem manual gasta tempo desnecessário. Eu uso um script próprio que aplica regras de tokenização em sequência, passando primeiro pelas exceções regionais, depois pelos plurais, e só então fazendo o mapeamento posicional. O processo leva cerca de trinta segundos para cem linhas, contra uns dez minutos se fizer tudo na mão, com risco maior de erro em valores com múltiplas casas decimais. A desvantagem do automatismo: Nenhuma ferramenta converte com 100% de precisão em português brasileiro. Erros sistemáticos aparecem em construções como "zero vírgula zero zero sete" (que alguns parsers transformam em 0,0007 quando o esperado era 0,007) e em casos onde o falante omite a palavra "reais" e deixa subentendido pelo contexto. Sempre valide pelo menos dez por cento das conversões automaticamente, e faça essa validação nos valores mais altos — são eles que geram problema se estiverem errados.

Dica prática para quem está começando

A regra mais importante que aprendi nos últimos anos: nunca confie cegamente na saída de um conversor automático para valores acima de mil reais sem conferência. Faça a leitura em voz alta do resultado numérico e compare com o original por extenso. Essa verificação auditiva pega erros de posição que o olho simplesmente pula, como trocar 1.250 por 12.500. Leva cinco segundos e evita retrabalho que pode levar horas para corrigir. Se quiser baixar um script simples em Python que implementa as regras básicas de conversão com suporte a variantes regionais e exceções comuns, o código está disponível gratuitamente. A versão atual cobre aproximadamente noventa e cinco por cento dos casos encontrados em documentos jurídicos e fiscais brasileiros, ficando de fora construções muito informais ou regionalismos muito específicos de cidades pequenas.