Decodificador de protobuf

O que dá e o que não dá para recuperar

Protocol Buffers codifica uma mensagem como uma sequência de campos, cada um com um cabeçalho pequeno e um payload. O cabeçalho é um único varint que carrega o número do campo e um tipo de três bits, e todo payload ou é autodelimitado ou vem precedido do seu tamanho. Isso basta para percorrer a mensagem inteira sem saber nada sobre ela, e é por isso que decodificar protobuf sem o .proto funciona.

E isso é tudo o que existe. Nomes de campo não trafegam no binário de forma alguma, então um decodificador pode dizer que o campo 3 vale 1500, mas nunca que esse campo se chama timeout_ms. Não é limitação desta ferramenta: os nomes simplesmente não estão lá, e nenhuma esperteza os recupera.

Além disso, duas coisas são genuinamente indecidíveis, e são a razão de esta página mostrar várias leituras por campo. Um varint é ao mesmo tempo um int32, int64, uint32, uint64, bool e enum válidos — e como sint32 e sint64 usam codificação zigzag, o número em si muda: o varint 3 é 3 como uint e −2 como sint. Ao mesmo tempo, um campo delimitado por comprimento pode ser uma string, bytes crus, uma mensagem aninhada ou um campo repetido empacotado, e nada na codificação os distingue.

Como usar

1. Cole os bytes. Hex ou base64, com ou sem espaços, dois-pontos ou prefixos 0x. Bytes copiados direto de uma captura de rede ou de uma linha de log funcionam do jeito que estão.
2. Percorra a lista de campos. Cada campo mostra seu número, seu tipo e todas as interpretações que a codificação permite. Mensagens aninhadas são abertas ali mesmo.
3. Trate várias leituras como ambiguidade real. Quando um campo tem mais de uma, todas estão certas e o formato não registra qual era a intenção. O contador no topo diz quantos campos estão nessa situação.

O exemplo por onde começar

Os bytes 0a 04 08 2a 10 07 são o padrão da caixa acima. Eles se leem como o campo 1 com um payload de quatro bytes — e esse payload é ao mesmo tempo uma mensagem aninhada perfeitamente válida com o campo 1 em 42 e o campo 2 em 7, e um bloco opaco de quatro bytes igualmente válido. As duas leituras valem. Nada nesses seis bytes diz qual quem enviou quis dizer.

Não é um caso forçado: é a situação normal de qualquer campo delimitado por comprimento, e por isso um decodificador que imprime uma resposta só está mostrando o próprio chute. Uma string binária curta vai ser lida como mensagem por acaso; uma mensagem aninhada sempre também pode ser lida como bytes. Só o schema resolve isso, e se você tivesse o schema não estaria aqui.

Há uma coisa que o formato diz alto e bom som. Os tipos 3 e 4 eram as antigas marcas de início e fim de grupo, abandonadas há muitos anos, e 6 e 7 nunca foram atribuídos. Se os bytes contêm algum, ou são bem antigos ou não são protobuf, e esta página diz isso em vez de produzir um absurdo plausível.

Limites honestos e como isto foi conferido

Isto decodifica o formato binário e nada acima dele. Não vai dizer o tipo da mensagem, não resolve nomes de campo e não tenta adivinhar um schema a partir dos números. Também não decodifica os tipos wrapper conhecidos nem Any, porque ambos precisam dos descritores para significar alguma coisa.

Quando um payload pode ser várias coisas, a leitura como mensagem aninhada vem primeiro se ela funcionar, porque em tráfego real costuma ser isso. Essa ordem é uma conveniência e explicitamente não um veredicto: as leituras como string e como bytes aparecem sempre ao lado, e payloads com caracteres de controle não são oferecidos como texto mesmo sendo UTF-8 válido, porque uma string cheia de caracteres não imprimíveis é ruído fantasiado de informação.

A implementação está fixada nos exemplos que a própria documentação do formato publica, e não em expectativas inventadas aqui: campo 1 como varint 150 é 08 96 01, campo 2 como a string testing, o exemplo empacotado com 3, 270 e 86942, e a tabela zigzag publicada. A suíte roda 577 verificações com 17 controles negativos. Passou de primeira, que é exatamente quando menos se deve confiar num conjunto de testes, e quebrar o motor de propósito então achou três lacunas reais: nenhuma verificação testava um valor de largura fixa, então lê-los na ordem errada passava batido; nada ficava entre os dois candidatos ao limiar de reinterpretação com sinal; e nenhum payload era ao mesmo tempo UTF-8 válido e caracteres de controle, que é a única forma de exercitar a checagem de texto.

Por que é grátis?

Isto é leitura de bytes e roda na aba que você já tem aberta. Nenhum servidor vê os seus bytes, então não há o que cobrar nem conta para criar.

Nada do que você colar é enviado, guardado ou registrado. Quadros de protobuf capturados costumam conter identificadores, tokens e dados pessoais, então isso merece ser dito com clareza em vez de deixado por sua conta.