Decodificar hexadecimal

Os espaços, os dois-pontos, as vírgulas, as quebras de linha e os prefixos `0x` são removidos antes da leitura. O que você colar pode vir de uma captura de rede, de uma saída do OpenSSL ou da definição de um array em C, sem que você precise limpar antes.

O que não dá no mesmo é o número de dígitos que sobra: ele tem que ser par, porque um byte são dois. Um comprimento ímpar não é um caso de borda que convenha preencher com um zero em silêncio — ele significa que alguma coisa se perdeu na cópia, e por isso é avisado.

Uma sequência de bytes pode ser um PNG, um PDF ou um ZIP tão bem quanto uma frase. Ler esses dados como UTF-8 produz símbolos de substituição ou uma sequência tecnicamente válida que não significa nada.

Em vez de devolver algo com cara de resultado, aqui é dito que os bytes não são texto e quantos são. É a resposta útil: ela encerra a busca por um erro de codificação que não existe e transfere a atenção para o que interessa, que é que tipo de dado aquilo é de verdade.

Vale reconhecer alguns começos de cabeça. Um PNG abre com `89 50 4e 47`, um PDF com `25 50 44 46` — que é o texto `%PDF` —, um ZIP com `50 4b`, um GIF com `47 49 46` e um JPEG com `ff d8 ff`. Como um DOCX e um XLSX são ZIP por dentro, os dois também começam com `50 4b`.

Isso resolve a pergunta seguinte assim que a página diz que os bytes não são texto. Se o dump veio de um campo que deveria conter uma frase e começa com `ff d8 ff`, o problema não é de codificação: alguém gravou uma foto naquela coluna, e a investigação continua em outro lugar.

O UTF-8 tem uma estrutura que se lê com um pouco de prática. Os bytes abaixo de `80` são ASCII, um caractere cada. Um byte entre `c2` e `df` abre uma sequência de dois, entre `e0` e `ef` uma de três, entre `f0` e `f4` uma de quatro, e todos os bytes de continuação ficam entre `80` e `bf`.

Daí sai uma regra prática útil: um `c3` no meio do dump é quase certamente um caractere acentuado do português, porque `c3 a7` é `ç`, `c3 a3` é `ã` e `c3 a9` é `é`. Quem vê um `c3` num log onde deveria haver uma cedilha já sabe, com isso, que os bytes estão certos e que o problema é de exibição.

Existe um padrão que vale reconhecer: um `c3 83` seguido de `c2` e mais um byte. Isso é UTF-8 codificado duas vezes — um `ç` que foi lido como Latin-1, virou os dois caracteres `ç` e foi gravado de novo em UTF-8. Na tela aparece exatamente aquele amontoado de letras estranhas que todo mundo já viu num site brasileiro mal migrado.

A distinção importa porque a correção é diferente. Um texto simplesmente lido com a codificação errada se conserta na hora de exibir; um texto gravado duas vezes está estragado no banco e precisa de uma passagem de correção sobre os dados. Ver `c3 83 c2` no dump é a prova de que se trata do segundo caso.

Se a sequência começa com `ef bb bf`, ali existe uma BOM de UTF-8. Ela é invisível, faz parte do conteúdo, e é a razão de a primeira coluna de um CSV exportado do Excel ter às vezes um nome que nenhum programa de leitura reconhece.

A mesma marca pode ser `fe ff` ou `ff fe` com outra codificação — então se trata de UTF-16 e não de UTF-8, e os bytes não são legíveis aqui como texto. Um `ff fe` no começo seguido de zeros entre as letras é a assinatura típica de um arquivo do Bloco de Notas do Windows em versões antigas.

Se no dump aparece um `00` entre cada byte legível, a codificação é UTF-16 e não UTF-8. Um `48 00 61 00` é «Ha» em UTF-16 com o byte menos significativo primeiro — as mesmas letras, outra codificação, e lido como UTF-8 dá um texto com caracteres de controle intercalados.

Isso aparece em exportações do registro do Windows, em alguns campos do SQL Server e em tudo que tenha passado pela variante Unicode da API do Windows. Reconhecer é simples assim que se veem os bytes — e essa é a utilidade real desta página diante de uma ferramenta que só cospe uma resposta.

Qualquer sequência de bytes pode ser lida como Latin-1, porque ali cada um dos 256 bytes é um caractere. Um decodificador que, diante de um UTF-8 inválido, recorra a isso em silêncio devolve sempre alguma coisa — e essa coisa é lixo com dados binários e o famoso amontoado de letras estranhas com um UTF-8 mal lido.

Esses desvios transformam um erro reconhecível num resultado plausível, que é a pior das duas propriedades. Aqui não há segunda codificação silenciosa: ou é UTF-8 válido, ou você fica sabendo que não é e decide você o que aquilo significa.

Um motivo frequente é comparar duas impressões digitais de certificado ou dois checksums, um anotado com dois-pontos e em maiúsculas e o outro sem eles e em minúsculas. Os bytes são idênticos, as strings não, e uma comparação de texto aponta uma diferença por causa disso.

Quem passar os dois por este campo vê na hora se são os mesmos bytes. Se são, era problema de formato; se não são, eles diferem de verdade, e aí a pergunta seguinte é de segurança e não de estética.

Não há saída como arquivo. Se os bytes forem um PNG, esta página teria informação suficiente para oferecer um download — e não oferece, porque é outra tarefa e uma em que convém saber o que se está fazendo. Montar um executável a partir de um dump de origem alheia não é gesto que uma ferramenta de texto deva oferecer de passagem.

Também não há detecção automática de codificação. Ela seria pouco confiável com entradas curtas e erraria justamente quando importa. O que a página faz no lugar disso é dizer que aquilo não é UTF-8 — e a decisão sobre o que então aquilo é você tem mais controle para tomar do que uma heurística.

Um dump hexadecimal de log ou de captura de rede contém com frequência o que estava sendo transmitido: credencial, chave de sessão, dados úteis com nomes dentro. Como aqui a decodificação acontece na página, não há compartilhamento conosco nem tratamento nosso sobre esse conteúdo.

Com esse tipo de valor é o ponto que decide. Uma captura é, por definição, algo que ninguém quer mandar para fora de novo, e uma ferramenta que a decodifique num servidor alheio já a viu. O painel de rede mostra que daqui não sai nada.