Conversor de bases numéricas
Converte um número entre binário, octal, decimal, hexadecimal e qualquer base de 2 a 36, com complemento de dois de largura fixa e uma grade de bits clicável.
8 bits de largura, 8 ligados
O que esta ferramenta faz
O mesmo número pode ser escrito em muitas bases, e os programadores movem-se entre quatro delas constantemente: binário porque é o que o hardware guarda, hexadecimal porque é uma abreviatura legível dele, decimal porque é assim que as pessoas pensam, e octal porque as permissões de arquivos e alguns sistemas mais antigos ainda o usam. Escreva um valor em qualquer dos campos e os restantes acompanham, além de mais um campo que pode fixar em qualquer base de 2 a 36.
O que o separa de uma calculadora escolar é o seletor de largura e a grade de bits. Escolha 8, 16, 32 ou 64 bits e os números negativos assumem a sua representação real na máquina em vez de um sinal de menos, e cada bit passa a ser algo em que pode clicar.
O que é realmente uma base
Uma base é quantos dígitos tem antes de os esgotar e ter de transportar. O decimal tem dez, por isso depois do 9 vem o 10. O binário tem dois, por isso depois do 1 vem o 10. A posição de cada dígito é uma potência da base, e é tudo:
1011 # o número, em base 2 1 x 8 = 8 # bit 3 0 x 4 = 0 # bit 2 1 x 2 = 2 # bit 1 1 x 1 = 1 # bit 0 8+0+2+1 = 11 # o total, em decimal
As bases acima de dez precisam de mais de dez símbolos, por isso pedem emprestadas letras: o hexadecimal vai de 0-9 e depois a-f, em que a é 10 e f é 15. Isso continua até à base 36, que usa todos os dígitos e todas as letras — a maior base que se pode escrever com o alfabeto simples, e a razão por que esta ferramenta para aí.
Por que hexadecimal, e não outra coisa
O hex é popular por uma razão concreta: 16 é 2 elevado a 4, por isso exatamente um dígito hex cobre exatamente quatro bits. Isso torna a conversão entre hex e binário uma consulta sem aritmética — cada dígito hex expande-se nos seus quatro bits, independentemente dos dígitos à volta.
d e a d 1101 1110 1010 1101 # cada dígito hex é o seu próprio nibble
O octal funciona da mesma maneira com três bits por dígito, já que 8 é 2 elevado a 3 — e é por isso que as permissões Unix são octais: três bits de permissão por grupo de usuários cabem exatamente num dígito. O decimal não tem essa relação com o binário, e por isso converter entre eles exige divisão a sério em vez de uma consulta.
É também por isso que aqui o campo binário é agrupado de quatro em quatro e o hex de dois em dois: os grupos coincidem com as fronteiras que importam, por isso pode ler um nibble ou um byte na tela sem contar.
Números negativos e complemento de dois
Um número negativo não tem forma binária por si só. Não há sinal de menos num registro — só bits — por isso o sinal tem de ser codificado nos próprios bits, e isso obriga a decidir quantos bits há. É por isso que o seletor de largura existe, e por isso a resposta muda quando o altera.
O esquema que todas as máquinas modernas usam é o complemento de dois: para representar um número negativo, toma-se a sua forma positiva, inverte-se cada bit e soma-se um. O resultado é que o bit de topo acaba significando «negativo», e a adição comum continua funcionando sem qualquer caso especial para os sinais.
0000 0101 # 5 1111 1010 # cada bit invertido 1111 1011 # mais um: -5 como byte, ou fb em hex
Alargue o registro e o mesmo número recebe outro padrão: -5 é fb em 8 bits, fffb em 16 e fffffffb em 32. O valor não mudou; mudou o número de bits que o transportam. Mudar de largura nesta ferramenta mostra exatamente isso.
Por que 0xFF é ao mesmo tempo 255 e -1
Os bits ff não dizem se têm sinal. Um byte com 1111 1111 lê-se como 255 se o código que o carrega declarou um tipo sem sinal, e como -1 se declarou um com sinal. Nada no byte em si distingue os dois — o tipo é uma afirmação que o programa faz sobre bits que não transportam essa informação.
Daí nasce toda uma família de erros reais: uma soma de verificação que sai negativa, um byte lido de um arquivo que compara como menor que zero, um char de C que se comporta de forma diferente em ARM e em x86 porque o seu sinal é definido pela implementação. Sempre que as leituras com e sem sinal diferem, esta ferramenta mostra ambas, porque a discrepância é normalmente aquilo que procurava.
A grade de bits
Cada bit do valor atual é mostrado com o seu número de posição, e clicar num deles inverte-o. As bases atualizam-se de imediato, o que torna algumas perguntas bem mais fáceis do que à mão:
- Que bit está ligado neste valor de flags — clique neles e leia as posições.
- Qual é a máscara para os bits 4 e 7 — ligue esses dois e leia o hex.
- O que faz ligar o bit de topo a um valor com sinal — torna-o negativo, à vista.
- Este valor é uma potência de dois — uma potência de dois tem exatamente um bit ligado.
O bit 0 é o menos significativo e fica à direita, o que é a convenção universal e a razão por que a grade se mantém da esquerda para a direita mesmo numa página que se lê ao contrário. As linhas têm oito bits para que as fronteiras de byte se vejam num relance.
Os números grandes mantêm-se exatos
Os números de JavaScript são doubles, que armazenam inteiros de forma exata apenas até 2^53 — cerca de 9 quatrilhões. Um valor de 64 bits pode ultrapassá-lo, e um conversor construído sobre números comuns arredonda-o em silêncio, dando uma cadeia hex que parece plausível e está errada nos últimos dígitos.
Aqui tudo usa inteiros de precisão arbitrária, por isso um valor completo de 64 bits converte-se exatamente. O modo de precisão arbitrária vai mais longe e remove o limite por completo — útil para valores criptográficos e identificadores grandes — mas note que sem uma largura fixa não há complemento de dois, portanto um número negativo nesse modo leva simplesmente um sinal de menos em cada base.
De binário para decimal, e de decimal para binário
Binário e decimal são aqui o único par que não compartilha nada: dois não é potência de dez e dez não é potência de dois, então nenhum dos dois sentidos é uma consulta e ambos exigem aritmética de verdade. Também não é a mesma aritmética, e essa é a parte que raramente se diz em voz alta: o método rápido à mão num sentido não é o inverso do método rápido à mão na volta.
- De binário para decimal, dobrando: comece no bit mais à esquerda com zero e, a cada bit, dobre o que você já tem e some esse bit. Para 1011 isso dá 1, 2, 5, 11 — uma única passagem, sem valores de posição para decorar, e é exatamente o que esta ferramenta faz ao ler o que você digita.
- De binário para decimal, pelas posições: some o valor de posição de cada bit ligado, que é o exemplo desenvolvido acima. Mais rápido quando só dois ou três bits estão ligados, e mais lento quando quase todos estão.
- De decimal para binário, dividindo: divida por dois e anote o resto, de novo e de novo, até não sobrar nada; depois leia os restos de baixo para cima. A resposta chega com o bit menos significativo primeiro, e por isso ela parece invertida durante todo o tempo em que você a escreve.
- De decimal para binário, subtraindo: tire a maior potência de dois que couber e repita. 200 perde 128 e sobram 72; 72 perde 64 e sobram 8; 8 perde 8 e não sobra nada — então os bits nas posições 7, 6 e 3 estão ligados e o byte é 1100 1000. Mais rápido do que dividir sempre que poucos bits estão ligados.
Há uma coisa que nenhum método à mão cobre aqui: um número decimal negativo não tem forma binária nenhuma enquanto uma largura não for escolhida. Peça menos cinco em binário e a resposta honesta é outra pergunta: quantos bits? É isso que o seletor de largura resolve, e é disso que trata a seção sobre complemento de dois acima. No modo de precisão arbitrária não há largura, então o sinal de menos simplesmente acompanha o número em qualquer base.
De decimal para hexadecimal, e de hexadecimal para decimal
Quase ninguém que faz isso com frequência divide por dezesseis. O atalho é a relação do hexadecimal com o binário: converta o número decimal para binário uma vez, corte os bits em grupos de quatro a partir da direita e leia cada grupo como um único dígito hex. A volta é o mesmo caminho ao contrário: expanda cada dígito hex nos seus quatro bits e some o valor de posição dos que estão ligados. Para qualquer coisa que caiba num byte há um caminho ainda mais curto: o primeiro dígito hex vale dezesseis vezes o segundo, então basta multiplicar e somar.
- 255 é ff — um byte com todos os bits ligados. É o que vale a pena saber de cor, porque é ali que o byte termina.
- 256 é 100. Um passo além de um byte cheio os dígitos viram, exatamente como 99 vira 100 no decimal, e o número hexadecimal ganha um dígito que o byte não consegue segurar.
- 65535 é ffff e 65536 é 10000: as mesmas duas referências um byte acima, onde um contador de dezesseis bits termina.
- 4096 é 1000, e é por isso que tamanhos de página, alinhamentos e deslocamentos na memória parecem redondos em hex e irregulares em decimal. O hex conta de quatro em quatro bits, e o hardware também.
Maiúsculas e minúsculas não fazem diferença: FF e ff são o mesmo valor, a ferramenta aceita as duas escritas na entrada e escreve minúsculas na saída. O que ela não faz é adivinhar. O prefixo 0x pertence ao campo hexadecimal e no campo decimal é recusado em vez de ser descartado em silêncio, porque um valor lido na base errada é o único erro que um conversor nunca pode fazer parecer plausível.
De octal para decimal, e o zero inicial que muda a resposta
O octal sobrevive num lugar mais do que em qualquer outro: as permissões de arquivos, onde três bits de permissão por grupo de usuários cabem exatamente num dígito octal. Converter para decimal é aritmética posicional comum com potências de oito — 755 em octal é sete sessenta e quatros mais cinco oitos mais cinco, ou seja 493 — e o sentido contrário é dividir por oito com os restos lidos de baixo para cima, a mesma forma de decimal para binário e pela mesma razão: oito também não tem relação com dez.
- 755 é 493 em decimal, 644 é 420 e 777 é 511. Nenhum desses números decimais serve para ninguém, e é justamente esse o ponto: as permissões são escritas em octal porque os dígitos coincidem com os bits de permissão, não porque o valor conte alguma coisa.
- Um zero inicial é uma marca de base em C e em Python 2: ali 0755 é octal e portanto o número 493. O Python 3 recusa essa escrita por completo e pede 0o755 no lugar, o que eliminou uma família inteira de erros silenciosos.
- O YAML 1.1 também lê um 0755 sem aspas como 493 — e por isso um modo de permissões num arquivo de configuração precisa ficar entre aspas, senão deixa de ser o modo que você escreveu.
- O JSON nunca permitiu isso: a gramática dele proíbe o zero inicial num número, então ali 0755 nem sequer é um número, e sim um erro de análise — o mais barulhento dos três comportamentos e o único que não dá para ler errado.
Esta ferramenta não vê num zero inicial nenhuma marca. Quem fixa a base é o campo em que você digita: 0755 no campo decimal é 755 e no campo octal é 493, e o prefixo 0o é aceito no campo octal e recusado em todos os outros. Adivinhar a base a partir de um prefixo significaria devolver um número diferente do que foi digitado.
De octal para hexadecimal: o par sem atalho
Os dois são potências de dois, então os dois são pura reagrupação dos mesmos bits — e ainda assim este é o único par entre as quatro bases sem nenhuma regra de dígito para dígito. Um dígito octal são três bits e um hexadecimal são quatro, e nenhum dos dois números divide o outro, de modo que as fronteiras nunca coincidem. Não há como escapar de escrever os bits e reagrupá-los.
- Escreva cada dígito octal com os seus três bits, na ordem: 755 vira 111 101 101.
- Reagrupe esses bits de quatro em quatro a partir da ponta direita, completando à esquerda com zeros quando a conta não fecha certo: 0001 1110 1101.
- Leia cada grupo de quatro como um dígito hex: 1ed. Completar pela ponta errada é o erro clássico aqui, e ele não parece errado: apenas multiplica a resposta em silêncio.
Que dois dígitos hex sejam exatamente um byte e dois dígitos octais não sejam é toda a razão pela qual o hex tirou o lugar do octal na leitura de memória: oito bits são dois dígitos octais e dois terços, então a fronteira do byte cai no meio de um dígito. O octal servia a máquinas cujo tamanho de palavra era múltiplo de três bits; o hex serve ao byte de oito bits. E nesta página, para este par, a grade de bits é mais rápida do que qualquer um dos métodos à mão: ligue os bits uma vez e os dois campos já estão mostrando a resposta.
Perguntas frequentes
- Por que -5 aparece como fb em vez de -101 em binário?
- Porque um registro não tem sinal de menos. Com uma largura selecionada, os negativos são mostrados em complemento de dois, que é o que a máquina guarda de fato: -5 num byte é 1111 1011, ou fb. Se quiser a forma matemática com sinal, mude a largura para precisão arbitrária.
- 0xFF é 255 ou -1?
- Ambos — os bits são idênticos e só o tipo declarado decide. Um valor de 8 bits com sinal lê ff como -1; um sem sinal lê-o como 255. Sempre que as duas leituras diferem, a ferramenta mostra-as lado a lado.
- Por que se usa tanto o hexadecimal em vez do decimal?
- Porque um dígito hex são exatamente quatro bits, por isso hex e binário convertem-se por consulta sem aritmética e os dígitos alinham com as fronteiras de byte. O decimal não tem essa relação com o binário, portanto um valor decimal não lhe diz nada sobre que bits estão ligados.
- Qual é a base mais alta aqui, e por que 36?
- 36, porque são 10 dígitos mais 26 letras — todos os símbolos que o alfabeto latino simples oferece. Ir mais alto exigiria uma convenção sobre que caracteres adicionais usar, e não há nenhuma consensual.
- Posso colar um valor com 0x ou com espaços?
- Sim. Os prefixos 0x, 0b e 0o são aceitos na base correspondente, e espaços e sublinhados são ignorados, por isso pode colar diretamente de código ou de uma ficha técnica sem limpar primeiro.
- Um valor de 64 bits converte-se exatamente?
- Sim. Toda a aritmética usa inteiros de precisão arbitrária, por isso os valores acima de 2^53 — onde um número normal de JavaScript começa a arredondar — mantêm-se exatos.
- Algo do que escrevo é enviado para um servidor?
- Não. É aritmética no seu navegador; nada é carregado nem registrado, e funciona sem conexão à rede.
- Como converto binário para decimal à mão?
- Dobre e some, da esquerda para a direita: comece em zero e, a cada bit, dobre o que você já tem e some o bit. 1011 dá 1, depois 2, depois 5, depois 11. É uma única passagem, sem valores de posição para decorar, e o mesmo método funciona em qualquer base: multiplique pela base em vez de dobrar.
- Quanto é 255 em hexadecimal, e por que esse número aparece o tempo todo?
- ff. É um byte com os oito bits ligados, ou seja, o maior valor que um byte segura e o ponto em que a contagem vira para um segundo byte — e por isso ele aparece em canais de cor, máscaras e limites de tamanho por toda parte. Um a mais é 256, escrito 100 em hex.
- O 0755 é o mesmo número que 755?
- Aqui sim no campo decimal e não no campo octal: quem fixa a base é o campo, e um zero inicial é apenas um dígito zero. Fora daqui depende da linguagem: C e Python 2 leem 0755 como octal, ou seja 493; o Python 3 recusa essa escrita e pede 0o755; o YAML 1.1 lê como 493; o JSON trata como erro de sintaxe.
- Como converto octal para hexadecimal?
- Passando pelo binário, porque não existe caminho mais curto: três bits por dígito octal, quatro por dígito hex, e os dois nunca coincidem. Expanda cada dígito octal nos seus três bits, reagrupe a sequência inteira de quatro em quatro começando pela direita e leia cada grupo de quatro como um dígito hex: 755 vira 111 101 101, depois 0001 1110 1101, depois 1ed.
Ferramentas relacionadas
- Conversor de tamanhos de dados
O mesmo número lido como uma quantidade de armazenamento e não como um padrão de bits: aquela página transforma uma contagem de bytes em KB, MB e GB ao lado de KiB, MiB e GiB, e diz onde os dois sistemas discordam.
- Calculadora de porcentagem
A base diz como um número é escrito; a porcentagem diz quanto ele vale ao lado de outro. Aquela página resolve partes, variações e cálculos inversos, e escreve a fórmula com os seus próprios números dentro.