Aller au contenu

Décodeur Protobuf

Protobuf Decoder

Décode une charge protobuf sans le fichier .proto, en déduisant les numéros de champ, les types de fil et l’imbrication.

Décode une charge utile protobuf sans le fichier `.proto`. Il lit le format binaire — numéros de champ, types de fil, imbrication — et montre côte à côte chaque lecture valide de chaque valeur, parce que sans le schéma il y en a réellement plus d'une.

🔒 Fonctionne entièrement dans votre navigateurprotobufdecodebinarygrpc

Charge utile

Déposez une charge binaire

Décodé dans cet onglet. Rien n’est envoyé.

Champs

Champs de premier niveau

3

Taille totale

17 o

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

En JSON (numéros de champ à la place des noms)

Sans le fichier .proto il n’y a pas de noms de champs et une même charge utile peut avoir plusieurs lectures valides : un varint est montré à la fois en non signé, en signé et en zigzag, et un champ à longueur préfixée en message, en texte ou en octets. L’imbrication affichée est la lecture où chaque octet tombe juste ; les autres sont imprimées à côté, pas cachées.

Comment s’en servir

  1. Collez les octets ou déposez le fichier

    De l'hexadécimal avec ou sans espaces, ou du Base64. Vous pouvez aussi déposer un fichier binaire jusqu'à 32 Mo.

  2. Lisez la liste des champs

    Chaque ligne donne le numéro de champ, le type de fil, le décalage en octets et la longueur, ainsi que les lectures possibles. Les messages imbriqués sont indentés sous leur parent.

  3. Emportez la projection JSON

    Le même arbre en JSON, avec les numéros de champ à la place des noms. Utile pour comparer deux charges utiles, ou pour coller dans un ticket.

Questions fréquentes

Pourquoi n'y a-t-il pas de noms de champs ?

Parce que protobuf ne les met pas sur le fil. Le message encodé ne porte que des *numéros* de champ — les noms vivent dans le fichier `.proto`, ce qui est exactement ce qui rend le format compact, et exactement pourquoi un décodage sans schéma ne peut vous montrer que des numéros.

Pourquoi une valeur est-elle montrée de trois façons différentes ?

Parce qu'un varint sur le fil n'est que des bits : les mêmes octets sont un `uint64` valide, un `int64` valide et un `sint64` zigzag valide, et seul le schéma dit lequel. En montrer un et cacher les autres serait présenter une supposition comme un fait.

Comment décide-t-il qu'un champ est un message imbriqué ?

Un champ délimité par sa longueur peut être un message, une chaîne ou des octets bruts. Il est présenté comme un message quand son contenu s'analyse complètement — chaque octet consommé, aucun reste — et la lecture en chaîne est affichée à côté quand les octets sont aussi du texte imprimable. Il arrive qu'une chaîne courte s'analyse comme un message par coïncidence ; les deux lectures sont là pour que vous puissiez trancher.

Peut-il décoder du trafic gRPC ?

Le corps du message, oui, une fois retiré l'en-tête de trame gRPC de cinq octets placé devant — un indicateur de compression et une longueur de quatre octets en big-endian. Donnez-lui les octets qui suivent et il décode normalement.

À alimenter depuis

Ensuite

Ces outils acceptent ce que celui-ci produit : le résultat peut y aller directement.