Conversão de tipos de dados

Converter é mudar a representação com uma intenção

Conversão de tipo é o processo de obter um valor em um tipo de destino a partir de um valor de origem. Ela aparece quando uma entrada textual precisa virar quantidade, quando um inteiro participa de um cálculo fracionário ou quando um resultado precisa ser exibido como texto.

A conversão deve preservar aquilo que importa no problema. Transformar "12" em 12 preserva a quantidade doze, mas transforma "0012" em 12 e depois novamente em texto não preserva o identificador original. A operação pode ser tecnicamente possível e ainda estar errada para o domínio.

Por isso, parta do contrato construído em Como escolher o tipo de dado adequado. Converter não corrige uma escolha de tipo inadequada.

Conversão não é sinônimo de cast

Conversão é o processo geral. Cast é uma forma explícita de solicitar ou declarar determinada conversão em linguagens que oferecem essa sintaxe. Além do cast, há funções, construtores e métodos especializados.

Quatro famílias ajudam a organizar o assunto:

Família	Quando ocorre	Exemplo conceitual	Principal cuidado
implícita	a linguagem realiza sem sintaxe adicional	inteiro para um tipo numérico mais amplo	não presumir exatidão em todo par
explícita	o programa solicita o tipo de destino	real para inteiro	fração, faixa ou sinal podem ser perdidos
parsing	texto é interpretado segundo uma gramática	"42" para inteiro	formato inválido, faixa e convenção regional
formatação	valor vira uma representação textual	preço para texto exibido	formato não deve substituir o valor interno

Os nomes e as regras concretas variam. Consulte sempre a documentação da linguagem e do tipo de destino.

Antes de converter, responda cinco perguntas

1. Qual é o tipo de origem? Texto externo, inteiro, valor aproximado ou outro?
2. Qual é o tipo de destino? Por que o algoritmo precisa dele?
3. Quais valores da origem são aceitos? Todos ou somente um subconjunto?
4. Que informação pode mudar? Fração, precisão, faixa, sinal, zeros ou formato?
5. O que acontece se não for possível? Erro, resultado de tentativa, valor padrão ou interrupção?

Se a política de falha não está definida, a conversão ainda não está pronta para receber dados reais.

Conversão implícita

Uma conversão implícita ocorre sem uma instrução explícita de cast. Em linguagens estaticamente tipadas, o compilador permite determinados pares segundo regras conhecidas. Um inteiro menor pode, por exemplo, ser atribuído a um tipo inteiro com faixa maior.

quantidadeInteira ← 12
quantidadeAmpla ← quantidadeInteira

Não use “implícita” como sinônimo universal de “exata”. A especificação do Java mostra que algumas ampliações de inteiro para ponto flutuante podem perder bits de precisão, embora não gerem exceção em tempo de execução. A garantia depende do par de tipos, não apenas da direção aparente.

Em um algoritmo independente de linguagem, registre a intenção:

media ← converterParaReal(total) / quantidade

Ao implementar, confira como a linguagem promove os operandos e qual será o tipo do resultado.

Conversão explícita e estreitamento

Uma conversão explícita sinaliza que o programador está solicitando uma mudança que pode não ser garantida automaticamente. Ela é comum quando o destino aceita menos valores ou menos detalhe.

Considere 19,75 convertido para inteiro. Em muitas linguagens, o resultado é 19: a parte fracionária é descartada, não arredondada. Já um inteiro grande convertido para um tipo menor pode falhar, transbordar ou produzir outro valor, conforme a tecnologia e o modo de verificação.

Arredondar e converter são decisões diferentes. Se o problema exige arredondamento, aplique primeiro a regra definida — por exemplo, para cima, para baixo ou para o mais próximo — e só então converta para o tipo final.

Parsing: interpretar texto como valor

Campos de formulário, arquivos e respostas de rede frequentemente chegam como texto. Parsing interpreta esse texto conforme a gramática do tipo desejado.

O texto "42" pode ser interpretado como inteiro. Já "quarenta e dois", "12x" ou um valor além da faixa não formam necessariamente um inteiro válido. Dados externos são incertos, portanto falhar ao interpretar é um resultado esperado que deve ser tratado.

Em pseudocódigo:

leia quantidadeTexto

se tentarConverterInteiro(quantidadeTexto, quantidade) então
    se quantidade >= 1 então
        escreva "Quantidade aceita"
    senão
        escreva "A quantidade deve ser positiva"
    fim se
senão
    escreva "Informe uma quantidade inteira"
fim se

Há duas validações diferentes:

• técnica: o texto representa um inteiro dentro da faixa?
• de domínio: esse inteiro é uma quantidade permitida no sistema?

Converter com sucesso não torna o valor válido para o negócio. -3 pode ser um inteiro perfeitamente interpretável e uma quantidade proibida.

No .NET, métodos como TryParse devolvem um indicador de sucesso sem usar exceção para uma entrada inválida esperada. Outras linguagens usam exceções, resultados opcionais ou funções com contratos diferentes. Preserve o fluxo conceitual: tentativa, sucesso ou falha, e validação do domínio.

Formato e convenção regional fazem parte do parsing

O texto "1.234" pode significar mil duzentos e trinta e quatro ou um valor com três casas decimais, dependendo da convenção. Símbolos monetários, separadores de milhares, espaço e sinal também podem alterar a aceitação.

Ao processar dados para pessoas, use a localidade esperada e comunique o formato. Em integrações entre sistemas, defina um formato estável e explícito. Não tente adivinhar silenciosamente múltiplas convenções, pois a mesma sequência pode ser válida com significados diferentes.

Evite também usar avaliação de código para converter texto. Uma entrada deve ser interpretada pela gramática específica do tipo, não executada como expressão do programa.

Formatação: transformar valor em texto

Formatação percorre o caminho inverso: cria uma representação textual para exibição, arquivo ou transmissão.

preco ← 19,9
precoExibido ← formatarMoeda(preco)

preco continua sendo um valor numérico adequado aos cálculos. precoExibido pode ser "R$ 19,90", mas agora é texto voltado à apresentação. Somar dois textos formatados não calcula o total.

Formatar pode arredondar o que aparece sem alterar o valor interno. Também pode remover detalhes que não serão recuperados ao interpretar o texto novamente. Por isso, não use a versão exibida como armazenamento principal quando o dado original precisa ser preservado.

Três formas de perder informação

Perda de fração

Real para inteiro pode descartar a parte fracionária. 8,99 pode se tornar 8, conforme a operação. Isso não equivale a arredondar.

Perda de precisão

Um destino pode manter a magnitude aproximada e perder dígitos significativos. O problema pode aparecer apenas em valores grandes ou após muitos cálculos.

Perda de faixa

O destino pode não comportar o valor. Dependendo da linguagem, haverá erro, saturação, transbordamento ou outro comportamento documentado.

Há ainda perda semântica. Converter o identificador "00042" para inteiro elimina zeros relevantes, embora o número 42 caiba perfeitamente no destino. Reveja tipos de dados sempre que a conversão parecer necessária apenas para acomodar uma escolha anterior.

Um fluxo seguro para entradas

Uma conversão robusta separa etapas e mantém o texto original disponível para diagnóstico:

1. receba o dado bruto sem presumir que seja válido;
2. defina tipo, formato e convenção esperados;
3. tente interpretar sem esconder a possibilidade de falha;
4. verifique faixa e perda de informação;
5. valide as regras do problema;
6. use o valor tipado somente após o sucesso;
7. registre ou comunique uma falha útil, sem substituir silenciosamente por zero.

Esse fluxo evita que uma entrada inválida se transforme em um valor aparentemente legítimo.

Valores padrão podem esconder erros

Imagine converter "abc" para inteiro e, em caso de falha, usar 0. Agora o restante do sistema não sabe se o usuário informou zero, se o campo estava ausente ou se houve erro de formato.

Um padrão só é correto quando o domínio define que a ausência realmente equivale àquele valor. Caso contrário, mantenha o resultado da tentativa separado do valor convertido.

O mesmo vale para booleanos. Textos como "false", "não", "0" e vazio não possuem uma interpretação universal. Defina explicitamente quais entradas são aceitas e rejeite as demais.

Erros comuns

Converter sem necessidade

Se um código precisa virar número apenas para ser armazenado, provavelmente o tipo de origem foi modelado incorretamente.

Confundir truncamento com arredondamento

Cast numérico não expressa uma política de arredondamento. Faça essa regra aparecer no algoritmo.

Presumir que todo texto numérico é válido

Formato, sinal, faixa, espaços e convenção regional precisam ser considerados.

Ignorar o resultado da tentativa

Usar o valor de saída após uma falha pode introduzir um padrão técnico como se fosse dado real.

Depender de conversões automáticas obscuras

Mesmo quando a linguagem permite coerção, uma conversão explícita e intencional pode comunicar melhor o contrato. Clareza é especialmente importante em comparações e concatenações.

Checklist de conversão

• A origem e o destino estão identificados?
• A conversão preserva o significado do dado?
• Sei quais valores podem perder fração, precisão, faixa ou formato?
• Parsing e formatação estão separados?
• A localidade ou o formato de integração foi definido?
• Falhas esperadas seguem um caminho explícito?
• A regra do domínio é validada após o parsing?
• Testei limites e entradas malformadas?

Pratique com um teste de mesa

Use o algoritmo de quantidade e teste estas entradas: "3", "0", "-2", "2,5", "dois", texto vazio e um inteiro maior que a faixa do tipo escolhido.

Para cada caso, registre:

1. se o parsing tem sucesso;
2. qual valor é produzido;
3. se a regra quantidade >= 1 é satisfeita;
4. qual mensagem deve ser apresentada.

Depois faça um teste manual e confirme que nenhuma falha se transforma silenciosamente em zero.

Para ver as regras concretas de uma linguagem estaticamente tipada, consulte o guia do blog sobre conversões de tipos de dados em Java.

O que você deve guardar

Toda conversão possui origem, destino e uma política de falha. Conversões implícitas seguem regras da linguagem; conversões explícitas tornam uma intenção visível; parsing interpreta texto; formatação produz texto.

Antes de converter, descubra o que pode ser perdido. Depois valide separadamente o formato técnico e a regra do domínio. Continue em Operadores aritméticos para construir cálculos conscientes dos tipos e das unidades, ou acompanhe o catálogo de Lógica de Programação.

Referências

• Microsoft Learn — Type conversions, casting, and boxing. Acesso em 10 set. 2026.
• Microsoft Learn — How to convert a string to a number. Acesso em 10 set. 2026.
• Java Language Specification 21 — Chapter 5: Conversions and Contexts. Acesso em 10 set. 2026.
• Python Documentation — Built-in Functions: int, float and str. Acesso em 10 set. 2026.
• MDN Web Docs — Number() constructor. Acesso em 10 set. 2026.
• MDN Web Docs — parseInt(). Acesso em 10 set. 2026.