Pular para o conteúdo

Decodificar Protobuf

Protobuf Decoder

Decodifica um payload protobuf sem o arquivo .proto, inferindo números de campo, wire types e aninhamento.

Decodifica um payload protobuf sem o arquivo `.proto`. Ele lê o wire format — números de campo, wire types, aninhamento — e mostra cada leitura válida de cada valor lado a lado, porque sem o esquema há genuinamente mais de uma.

🔒 Roda inteiramente no seu navegadorprotobufdecodebinarygrpc

Carga

Solte uma carga binária

Decodificado nesta aba. Nada é enviado.

Campos

Campos de primeiro nível

3

Tamanho total

17 bytes

  • #1VARINT@0, 3 Buint 150 · zigzag 75
  • #2LEN@3, 9 B"testing"
  • #3LEN@12, 5 Bmensagem (1 campo)
    • #1VARINT@0, 3 Buint 150 · zigzag 75

Como JSON (números de campo no lugar dos nomes)

Sem o arquivo .proto não há nomes de campo e uma mesma carga pode ter várias leituras válidas: um varint aparece ao mesmo tempo como sem sinal, com sinal e em zigzag, e um campo com comprimento como mensagem, texto ou bytes. O aninhamento mostrado é a leitura em que cada byte encaixa exatamente; as alternativas são impressas ao lado, não escondidas.

Como usar

  1. Cole os bytes ou solte o arquivo

    Hexadecimal com ou sem espaços, ou Base64. Um arquivo binário de até 32 MB pode ser solto em vez disso.

  2. Leia a lista de campos

    Cada linha dá o número do campo, o wire type, o offset e o comprimento em bytes, e as leituras. Mensagens aninhadas são indentadas sob a mensagem pai.

  3. Pegue a projeção JSON

    A mesma árvore como JSON, com números de campo no lugar dos nomes. Útil para comparar dois payloads, ou para colar em uma issue.

Perguntas frequentes

Por que não há nomes de campo?

Porque o protobuf não os coloca no fio. A mensagem codificada carrega só *números* de campo: os nomes vivem no arquivo `.proto`, que é exatamente o que torna o formato compacto e exatamente por que uma decodificação sem esquema só consegue te mostrar números.

Por que um valor é mostrado de três jeitos diferentes?

Porque um varint no fio é só bits: os mesmos bytes são um `uint64` válido, um `int64` válido e um `sint64` zigzag válido, e só o esquema diz qual. Mostrar um e esconder os outros seria um palpite apresentado como fato.

Como ele decide que um campo é uma mensagem aninhada?

Um campo delimitado por comprimento pode ser uma mensagem, uma string ou bytes crus. Ele é mostrado como mensagem quando o conteúdo é analisado por completo — cada byte consumido, sem sobras — e a leitura como string é impressa ao lado quando os bytes também são texto imprimível. De vez em quando uma string curta é analisada como mensagem por coincidência; as duas leituras estão ali para você distinguir.

Ele decodifica tráfego gRPC?

O corpo da mensagem, sim, depois que você tira da frente o cabeçalho de frame do gRPC de cinco bytes: uma flag de compressão e um comprimento big-endian de quatro bytes. Forneça os bytes a partir dali e ele decodifica normalmente.

Pode receber de

Em seguida

Estas aceitam o que esta ferramenta produz, então o resultado pode ir direto.