Conversor de texto para hexadecimal

Uma string como os bytes em que ela é guardada

Toda string que um programa manipula é, por baixo, uma fileira de bytes, e esta página os escreve em hexadecimal, dois dígitos para cada um. Digite Hello e você obtém 48 65 6C 6C 6F, um byte por letra, com um espaço depois de cada um menos o último. Se, em vez disso, você puser a direção em “Hexadecimal para texto” e colar hexadecimal tirado de um log, de um banco de dados ou de um depurador, recebe de volta o texto que esses bytes guardam.

Um mesmo texto dá bytes diferentes em codificações diferentes, e a unidade decide o que são os dígitos desta página. Ela começa em UTF-8, a codificação da web, em que H é o byte 48 e א, os bytes D7 90. UTF-16 LE e UTF-16 BE gastam dois bytes com cada um deles, em ordens opostas — 48 00 ou 00 48 para H —, enquanto “Pontos de código” deixa os bytes de lado e escreve o número que o Unicode atribui, U+05D0 para א. A unidade que estiver definida vale tanto para o hexadecimal que você lê quanto para o texto que você escreve, e continua definida: se o hexadecimal colado se parecer com o de outra unidade, a página pode sugeri-la, mas só um clique seu a muda.

Dois dígitos hexadecimais para cada byte

Um byte guarda um de 256 valores, de 0 a 255. O hexadecimal conta de dezesseis em dezesseis, com os dígitos de 0 a 9 e depois de A a F para dez a quinze, e dezesseis vezes dezesseis são 256, então dois dígitos hexadecimais nomeiam qualquer byte e um terceiro nunca é necessário: 00 é 0, 7F é 127 e FF é 255. H é 72, quatro vezes dezesseis mais oito, então o byte dele é 48.

Cada dígito hexadecimal representa exatamente quatro bits, meio byte: o 4 de 48 é 0100 e o 8 é 1000, e lado a lado eles são os oito bits de H, 01001000. A página mantém os dois dígitos de cada byte, então uma quebra de linha é 0A e um espaço, 20, e, como todo byte ocupa a mesma largura, o hexadecimal pode ser lido de volta sem nada entre os bytes: 4869 é Hi.

As letras do hexadecimal significam o mesmo em maiúsculas ou minúsculas. A página escreve maiúsculas, a menos que você escolha “minúsculas”, então é fica C3 A9 ou c3 a9, e ela lê as duas formas, mesmo misturadas no mesmo texto colado.

Cinco estilos, cada um pensado para onde vai ser colado

Em hexadecimal, o controle “Estilo” dispõe os mesmos bytes de cinco maneiras, cada uma para um lugar aonde o hexadecimal vai em seguida. Para Hi, os dois bytes 48 e 69:

• “Com espaços” dá 48 69, um espaço entre os bytes: o mais fácil de ler e de contar, e o estilo com que a página abre.
• “Compacto” dá 4869, os dígitos colados uns nos outros, para um campo ou um parâmetro que recebe um valor como uma única string hexadecimal.
• “Array” dá 0x48, 0x69, cada byte um número com 0x na frente e uma vírgula entre eles, pronto para colar em um array de bytes em C, C#, JavaScript, Python ou Go.
• “Com escape” dá \x48\x69, cada byte como \x e os seus dois dígitos, do jeito que um byte é escrito dentro de uma string em C ou de um literal de bytes do Python como b'\x48\x69'.
• “Despejo hexadecimal” dispõe os bytes em linhas, com a posição em que cada linha começa e os mesmos bytes como texto ao lado: a próxima seção lê um.

A leitura aceita os cinco de volta, junto com outras formatações que não mexem nos bytes: dois pontos, como em 48:69, os hifens que o BitConverter.ToString do .NET escreve, como em 48-69, 0x ou 0X antes de cada byte, e o texto colado inteiro envolvido uma vez em parênteses, colchetes ou chaves, ou entre aspas. O estilo e a escolha entre maiúsculas e minúsculas só importam para escrever, então os dois controles somem quando a direção é “Hexadecimal para texto”.

Há uma armadilha em “Com escape”. Em uma string de JavaScript, ou em uma string comum do Python e não em um literal de bytes, \x nomeia um caractere e não um byte, então \xD7\x90 ali são dois caracteres, e não o א cujos bytes UTF-8 são D7 90. Além do ASCII, entregue os bytes a algo que aceite bytes.

Lendo um despejo hexadecimal, coluna por coluna

Um despejo hexadecimal dispõe os bytes dezesseis por linha, com uma coluna de cada lado para ajudar você a encontrá-los. Escritos com o estilo “Despejo hexadecimal”, Hello, World! e uma quebra de linha enchem uma linha: primeiro 00000000, o deslocamento, que é onde fica o primeiro byte da linha contando a partir de zero, em oito dígitos hexadecimais; depois os quatorze bytes, oito e depois seis, com um espaço maior entre as duas metades; depois |Hello, World!.|, os mesmos bytes como caracteres, cada byte que não é ASCII imprimível mostrado como um ponto, a quebra de linha entre eles. Uma última linha contém só 0000000E, que é quatorze: onde ficaria o byte seguinte, e portanto o comprimento. Essa é a disposição que o hexdump -C imprime.

• Com “Hexadecimal para texto” escolhido e qualquer unidade menos “Pontos de código”, um despejo hexadecimal colado é lido apenas pelos bytes que contém: a coluna de texto fica fora da leitura, nenhum deslocamento é lido como byte, e um aviso abaixo do resultado diz que a entrada foi tomada como um despejo e nomeia a disposição.
• Duas disposições são lidas assim: a do hexdump -C e a que o xxd imprime sem opções, em que dois pontos seguem cada deslocamento e os bytes ficam em grupos de quatro dígitos. O hexadecimal simples que o xxd -p imprime não precisa de disposição nenhuma e é lido como qualquer outro hexadecimal.
• O hexdump -C imprime uma linha só com * no lugar das linhas que repetem a de cima, e a página preenche de novo essas linhas a partir do deslocamento de baixo, então os bytes voltam completos.
• Cada deslocamento depois do primeiro precisa bater com os bytes acima dele, incluindo o comprimento na última linha do hexdump -C, e uma linha cujo deslocamento não bate é recusada ali em vez de ser lida errado: é ali que aparece uma linha omitida, um byte perdido ou um deslocamento digitado errado. O que não tem nenhum deslocamento depois não pode ser conferido, então um despejo hexadecimal sem as primeiras linhas, ou o final de um que não tem linha de comprimento depois, já que o xxd não escreve nenhuma, é lido como o que sobrar.

UTF-16 LE, e por que um em cada dois bytes é 00

O Windows guarda o texto em UTF-16 com o byte menos significativo primeiro, que é o UTF-16 LE; no .NET, ele é Encoding.Unicode, e o SQL Server armazena um valor NVARCHAR do mesmo jeito. O UTF-16 dá dois bytes a cada caractere até U+FFFF, e para tudo até U+00FF — as letras do inglês, os dígitos, é e o resto do Latin-1 — o byte mais significativo é 00. Com o byte menos significativo primeiro, esse zero cai depois de cada letra: Hi é 48 00 69 00.

O SQL Server mostra um valor VARBINARY como 0x seguido do hexadecimal dele, então um NVARCHAR contendo Hi, convertido para VARBINARY, aparece como 0x48006900. Cole isso aqui com UTF-8 escolhido e o texto sai como H, um NUL, i e um NUL, e o aviso abaixo dele diz que um em cada dois bytes é 00, como acontece quando um texto no alfabeto latino é escrito em UTF-16 e não em UTF-8, com “Mudar para UTF-16 LE” ao lado. Clique nele e os mesmos bytes viram Hi.

O UTF-16 BE, ao contrário, põe o byte mais significativo primeiro, então ali Hi é 00 48 00 69, e א, D0 05 em UTF-16 LE, é 05 D0. Zeros no primeiro lugar de cada par fazem o aviso oferecer UTF-16 BE. Ele não diz nada assim que o texto tem um caractere além de U+00FF, porque o byte mais significativo desse caractere não é 00, e só se manifesta onde um em cada dois bytes o é.

Uma marca de ordem de bytes no início

Um texto pode começar com U+FEFF, um caractere que não mostra nada e está ali para ser uma marca de ordem de bytes. Em UTF-16, os dois bytes dela dão a ordem de cada par que vem depois, FF FE para UTF-16 LE e FE FF para UTF-16 BE, e em UTF-8 ela é formada pelos três bytes EF BB BF, uma assinatura de que o texto é UTF-8, que tem uma só ordem.

A página mantém a marca em vez de descartá-la. O hexadecimal que começa com a marca da própria unidade escolhida é lido como um texto que começa com U+FEFF, e um aviso diz que a marca foi mantida, então escrever esse texto de novo dá os mesmos bytes, marca incluída. O hexadecimal que começa com a marca da outra ordem do UTF-16, ou com uma marca de UTF-16 enquanto o UTF-8 está escolhido, recebe um aviso de que os bytes começam com a marca de outra unidade, ao lado de um botão que muda para a ordem que a marca indica. Em qualquer ponto depois do início, U+FEFF é um caractere comum e não gera aviso nenhum.

Bytes que não são texto, mostrados como U+FFFD

Nem toda sequência de bytes é texto na unidade escolhida: um caractere ao qual falta o último byte, um byte solto como E9, que páginas de código antigas escrevem para é, e um byte sem par que sobra no final de um UTF-16 não formam nada. Mas uma sequência ruim não põe a perder o texto colado: cada uma é trocada por U+FFFD, o caractere de substituição, e todo o resto é lido normalmente.

Um aviso dá então o número delas e nomeia a primeira pelo lugar que ocupa entre os bytes, pelos dígitos que você escreveu para ela e pela linha e coluna em que está. Café salvo em Windows-1252, a página de código do Windows para textos da Europa Ocidental, é 43 61 66 E9, com o é escrito ali como um só byte, E9; lido como UTF-8, volta como Caf e U+FFFD, e o aviso nomeia o byte 4, escrito E9, na linha 1, coluna 10. Em UTF-8 a palavra é 43 61 66 C3 A9.

Ele conta sequências, não bytes: F0 9F 98, três dos quatro bytes de 😀, são um U+FFFD. E um U+FFFD que está de fato no texto, os bytes EF BF BD, é lido como texto e nem sequer é contado, então o aviso só trata de bytes que não puderam ser lidos.

Transformar hexadecimal de volta em um arquivo

A leitura entrega os bytes além do texto. Com a direção em “Hexadecimal para texto” e UTF-8, UTF-16 LE ou UTF-16 BE escolhido, “Baixar” salva, como um arquivo chamado bytes.bin, exatamente os bytes que foram lidos, incluindo os que não eram texto, e antes de qualquer um ser substituído: o trabalho que o xxd -r faz com um despejo hexadecimal. Não há “Baixar” para pontos de código, que não são bytes, nem durante a escrita, quando o que você leva são dígitos.

Assim, o hexadecimal de algo que nunca foi texto também volta inteiro. Toda imagem PNG começa com os oito bytes 89 50 4E 47 0D 0A 1A 0A; lidos como UTF-8, eles aparecem como U+FFFD, as letras PNG e quatro caracteres de controle, com um aviso sobre a sequência que não é texto, e “Baixar” salva os oito exatamente. O arquivo sempre se chama bytes.bin, já que bytes não carregam nome, então dê a ele um nome próprio, como image.png, depois de salvá-lo.

Aonde ir para um caractere, os bits dele ou um número

Para saber o que um caractere é — o nome, a categoria e se ele é um dos invisíveis —, o Inspetor de caracteres Unicode decompõe um texto um ponto de código de cada vez e mostra também os bytes UTF-8 de cada um.

O Conversor de texto para binário é esta mesma página abrindo em binário, onde o padrão que o UTF-8 segue pode ser lido nos primeiros bits de cada byte. E um número não é um texto: 255 inserido aqui são os dígitos 2, 5 e 5, e portanto os bytes 32 35 35, enquanto o Conversor de bases numéricas toma 255 como uma quantidade e o escreve em hexadecimal como ff.