Decodificador de Protocol Buffers

O que um decodificador Protobuf sem esquema pode comprovar

Protocol Buffers armazena uma sequência de tags e valores de campo, não as declarações .proto originais. O guia oficial de codificação protobuf define cada tag como (field_number << 3) | wire_type. Assim, o decodificador comprova o número de campo, wire type, limites dos bytes e codificações estruturalmente possíveis. Não pode determinar se um varint foi declarado como uint64, int64, sint64, bool ou enum, pois podem compartilhar os mesmos bytes.

O modo de entrada é sempre explícito. Hexadecimal permite espaços ASCII e, no máximo, um 0x inicial. Base64 e Base64URL são validados separadamente, incluindo comprimento, padding e bits de preenchimento não usados; os alfabetos normal e URL-safe não podem ser misturados. Texto simples são os bytes UTF-8 exatos produzidos pelo TextEncoder do navegador, escapes com barra invertida não são interpretados. Um arquivo é lido byte a byte.

Wire types e interpretações

O tipo Number comum do JavaScript não representa todos os inteiros de 64 bits com exatidão. O parser usa BigInt e converte os inteiros exatos em strings decimais para exibição e exportação. NaN, infinitos e zero negativo também são exportados como strings para que o JSON não os altere silenciosamente.

Compreender a ambiguidade delimitada por comprimento

O wire type 2 serve para strings, bytes simples, mensagens incorporadas e escalares repetidos packed. Sem esquema, uma sequência pode ter vários papéis. 2a 03 01 02 03, por exemplo, é o campo 5 com três bytes: são varints packed válidos [1, 2, 3], mas também bytes normais. O decodificador mostra ambas as possibilidades sem escolher uma.

Um candidato a mensagem aninhada só aparece se todo o corpo formar uma mensagem completa. Candidatos varint, fixed32 e fixed64 packed também precisam consumir todos os bytes. UTF-8 estrito exige a sequência completa sem caracteres de substituição. Estas verificações mostram possibilidades estruturais, não o tipo declarado.

Os grupos seguem a gramática wire, apesar de os esquemas modernos preferirem mensagens incorporadas. Uma tag inicial precisa fechar com a tag final do mesmo campo. Um fim na raiz, número diferente ou fechamento ausente causa erro fatal no offset exato. Os campos completos anteriores continuam visíveis; bytes ausentes e valores desconhecidos nunca se tornam um zero fictício.

Limites, framing e tratamento seguro

O decodificador aceita uma mensagem sem framing até 10 MiB. Não separa streams com prefixo de comprimento, frames gRPC, arquivos de mensagens delimitadas nem envelopes de transporte. Remova primeiro o framing e decodifique uma mensagem. O parser limita registros, profundidade recursiva, linhas visíveis e trabalho dos candidatos, seguindo as recomendações sobre grandes conjuntos de dados e limites de implementação.

Os números de campo devem estar entre 1 e 536 870 911. O intervalo 19 000–19 999 gera um aviso porque as orientações oficiais o reservam para implementações. Os wire types 6 e 7 são inválidos.

A análise e a exportação ocorrem localmente. A visualização por etapas pode salvar um payload limitado no sessionStorage desta aba por até duas horas; recomeçar apaga-o. Nada entra na URL nem é enviado aos nossos servidores. O JSON é um relatório de decodificação no formato próprio desta ferramenta, não ProtoJSON. O CSV começa com BOM UTF-8 e neutraliza células semelhantes a fórmulas para maior segurança numa planilha. O relatório pode conter dados confidenciais: verifique-o antes de compartilhar.