Codificar em hexadecimal

O hexadecimal é uma forma de escrever bytes, e um byte tem exatamente 256 valores possíveis, ou seja dois dígitos hexadecimais. Por isso a saída sempre tem um número par de dígitos — um comprimento ímpar é sinal seguro de que alguma coisa se perdeu no caminho.

Um caractere, por outro lado, não é necessariamente um byte. Um `a` é, um `ç` são dois, um caractere chinês três e um emoji quatro. Quem quer saber o comprimento de um texto em bytes vê isso aqui direto, e com frequência ele é um terço maior do que o número de caracteres com que alguém calculou o limite de um campo.

Um texto é uma sucessão de caracteres; ele só vira bytes através de uma codificação. A pergunta «que bytes tem este texto» está, portanto, incompleta enquanto não se disser qual. Aqui é UTF-8, porque a web, o Linux, o macOS, o JSON e praticamente qualquer protocolo moderno estão fixados nela.

Onde houver outra coisa envolvida — uma página de código antiga do Windows, Latin-1 numa coluna de banco — os bytes diferem, e diferem justamente nos caracteres acima do ASCII. Um `ç` é `c3 a7` em UTF-8 e o byte único `e7` em Latin-1. Se os seus valores não fecham, esse é o primeiro lugar para olhar.

Os dois-pontos entre bytes são a forma como o OpenSSL imprime impressões digitais de certificado e como se leem endereços MAC. Os espaços são a forma de um dump hexadecimal, como o que o `xxd` ou uma captura de rede mostram. Sem separador é o que vai num campo de banco, numa linha de configuração ou numa comparação de hash.

Na prática, a escolha depende de para onde o valor vai e não do que fica mais bonito. Uma comparação entre duas impressões digitais falha com uma frequência surpreendente só porque uma está anotada com dois-pontos e a outra sem — os bytes são os mesmos, as strings não.

Para o valor de um byte a caixa dos dígitos dá no mesmo: `ff` e `FF` são o mesmo número. Para uma comparação de texto muda tudo, então a pergunta deixa de ser cosmética assim que o valor é comparado, hasheado ou usado como chave.

As convenções não são uniformes: as ferramentas Unix e a maioria das bibliotecas escrevem em minúsculas, as do Windows e muitas telas de certificado em maiúsculas, e os endereços MAC das duas formas conforme o fabricante. Quem compara, normaliza antes; e quem calcula uma assinatura precisa saber qual caixa a especificação pede, porque senão o hash é outro.

O motivo sério mais comum para olhar um texto em hexadecimal é uma comparação que falha embora os dois valores pareçam idênticos. Na visão de bytes aparece na hora o que a tela esconde: um `c2 a0` de espaço rígido, um `0d` na frente do `0a` de uma linha do Windows, um `09` de tabulação onde deveria haver um espaço.

Igualmente frequente é um `ef bb bf` no começo — a marca de ordem de bytes que o Excel e alguns editores do Windows colocam no início do arquivo. Ela é invisível, faz parte do conteúdo, e é a razão de a primeira coluna de um CSV ter às vezes um nome que nenhum programa reconhece.

O `ã` pode ser escrito de dois jeitos em Unicode: como um único caractere, que em UTF-8 é `c3 a3`, ou como um `a` seguido de um til combinante, que é `61 cc 83`. Na tela os dois são idênticos; em bytes são três contra dois, e nenhuma comparação de string os trata como iguais.

Isso não é curiosidade acadêmica no Brasil. O macOS armazena nomes de arquivo na forma decomposta, então um arquivo chamado «ação» criado num Mac e enviado para um servidor Linux chega com bytes diferentes dos que o mesmo nome teria vindo do Windows. Ver o dump é a maneira mais rápida de confirmar que é isso, e a correção é normalizar para a forma composta antes de comparar ou de gravar.

O Windows termina uma linha com `0d 0a`, o Unix e o macOS com `0a`. Na tela são idênticos; em bytes não são — e é por isso que os checksums de dois arquivos «iguais» diferem, que os sistemas de versão apontam mudança em linhas intactas e que uma comparação dada como trivial falha.

Nesta página isso se vê direto: cole um texto com uma quebra de linha e olhe se antes do `0a` há um `0d`. É a via mais rápida para decidir se alguma ferramenta da esteira reescreveu os finais de linha — coisa que o Git faz de forma explícita conforme a configuração.

Muito limite de armazenamento é contado em bytes e não em caracteres: um campo declarado com 255 bytes recebe 255 letras se o texto for ASCII e bem menos se ele tiver acento em cada palavra. Um nome com cedilha e til gasta um byte extra por caractere acentuado.

O sintoma disso é característico: tudo funciona nos testes, escritos em inglês, e falha com nomes brasileiros. Pior ainda quando o corte é silencioso, porque a string pode ser cortada no meio de uma sequência de dois bytes e o que fica guardado deixa de ser UTF-8 válido. Contar os bytes aqui responde a pergunta antes de o campo responder.

Os dois escrevem bytes como texto imprimível, e escolher entre eles é escolher entre legibilidade e tamanho. O hexadecimal precisa de dois caracteres por byte, ou seja o dobro do espaço; o Base64 precisa de cerca de um terço a mais do que os dados crus e é, portanto, bem mais econômico.

Em troca, o hexadecimal se lê. Dá para olhar um byte específico numa posição específica, colocar dois valores lado a lado e achar a primeira diferença, e os limites entre bytes são visíveis. Em Base64 nada disso funciona, porque ali três bytes se fundem em quatro caracteres. Por isso o comum em hash e impressão digital é hexadecimal, e em dados úteis é Base64.

O prefixo `0x` é uma convenção das linguagens de programação e diz ao compilador que os dígitos seguintes são lidos em hexadecimal. Ele vai na frente de um número solto no código, não na frente de cada byte de uma sequência: `0x48 0x61` é uma lista de dois números, `4861` são dois bytes.

Por isso aqui nenhum prefixo é gerado. O sentido contrário é mais generoso: o decodificador deste site aceita `0x` na frente de cada byte, porque essas listas copiadas de código-fonte chegam de verdade. Gerar e aceitar podem divergir, e aqui divergem de propósito.

Neste campo costuma entrar o valor que a pessoa preferiria não mover: um campo de log que está se comportando de forma estranha, uma chave, um candidato a senha para conferir com um checksum. Como a conversão acontece na página, não há compartilhamento conosco.

Isso se confere no painel de rede: enquanto você usa, nenhuma requisição sai levando a sua entrada. O que fica está na página de privacidade — a visita e as requisições de publicidade e estatística. O conteúdo do campo não está entre elas, e com esse tipo de valor é a única coisa que conta.