Décodeur protobuf

Ce qui se récupère et ce qui ne se récupère pas

Protocol Buffers encode un message comme une suite de champs, chacun composé d'un petit en-tête et d'une charge utile. L'en-tête est un unique varint portant le numéro de champ et un type sur trois bits, et toute charge utile est soit autodélimitée, soit précédée de sa longueur. Cela suffit à parcourir le message entier sans rien savoir de lui, et c'est pourquoi décoder du protobuf sans fichier .proto fonctionne.

C'est aussi tout ce dont on dispose. Les noms de champs ne circulent pas dans le binaire, sous aucune forme : un décodeur peut donc vous dire que le champ 3 vaut 1500, jamais que ce champ s'appelle timeout_ms. Ce n'est pas une limite de cet outil, les noms ne sont tout simplement pas là, et aucune astuce ne les récupère.

Au-delà, deux choses sont réellement indécidables, et c'est la raison pour laquelle cette page affiche plusieurs lectures par champ. Un varint est à la fois un int32, un int64, un uint32, un uint64, un bool et un enum valides — et comme sint32 et sint64 utilisent l'encodage zigzag, le nombre lui-même change : le varint 3 vaut 3 en uint et −2 en sint. Dans le même temps, un champ délimité par longueur peut être une chaîne, des octets bruts, un message imbriqué ou un champ répété compacté, et rien dans l'encodage ne les distingue.

Comment s'en servir

1. Collez les octets. Hexadécimal ou base64, avec ou sans espaces, deux-points ou préfixes 0x. Des octets copiés tels quels depuis une capture réseau ou une ligne de log conviennent.
2. Parcourez la liste des champs. Chaque champ indique son numéro, son type et toutes les interprétations que l'encodage autorise. Les messages imbriqués sont dépliés sur place.
3. Prenez les lectures multiples pour ce qu'elles sont. Quand un champ en propose plusieurs, toutes sont correctes et le format n'enregistre pas celle qui était voulue. Le compteur en haut indique combien de champs sont dans ce cas.

L'exemple par lequel commencer

Les octets 0a 04 08 2a 10 07 sont ceux proposés par défaut ci-dessus. Ils se lisent comme le champ 1 portant une charge utile de quatre octets — et cette charge est simultanément un message imbriqué parfaitement valide, avec le champ 1 à 42 et le champ 2 à 7, et un bloc opaque de quatre octets tout aussi valide. Les deux lectures tiennent. Rien dans ces six octets ne dit laquelle l'émetteur avait en tête.

Ce n'est pas un cas tordu : c'est la situation ordinaire de tout champ délimité par longueur, et c'est pourquoi un décodeur qui imprime une seule réponse vous montre sa propre supposition. Une courte chaîne binaire s'interprétera comme un message par hasard ; un message imbriqué se lit toujours aussi comme des octets. Seul le schéma tranche, et si vous aviez le schéma vous ne seriez pas ici.

Le format vous dit tout de même une chose sans ambiguïté. Les types 3 et 4 étaient les anciens marqueurs de début et de fin de groupe, abandonnés depuis de nombreuses années, et 6 et 7 n'ont jamais été attribués. Si les octets en contiennent un, ils sont soit très anciens, soit pas du protobuf, et cette page le dit plutôt que de produire un contresens plausible.

Limites assumées, et vérifications

Ceci décode le format binaire et rien au-dessus. Il ne vous donnera pas le type du message, ne résout pas les noms de champs et ne tente pas de deviner un schéma à partir des numéros. Il ne décode pas davantage les types wrapper bien connus ni Any, qui ont tous deux besoin des descripteurs pour signifier quoi que ce soit.

Lorsqu'une charge utile peut être plusieurs choses, la lecture en message imbriqué est présentée en premier quand elle fonctionne, parce que dans du trafic réel c'est généralement ce dont il s'agit. Cet ordre est une commodité et explicitement pas un verdict : les lectures en chaîne et en octets sont toujours affichées à côté, et les charges faites de caractères de contrôle ne sont pas proposées comme du texte même lorsqu'elles sont de l'UTF-8 valide, car une chaîne pleine de caractères non imprimables est du bruit déguisé en information.

L'implémentation est calée sur les exemples que la documentation du format publie elle-même, plutôt que sur des attentes inventées ici : le champ 1 en varint 150 s'écrit 08 96 01, le champ 2 porte la chaîne testing, l'exemple compacté contient 3, 270 et 86942, et la table zigzag est celle publiée. La suite exécute 577 assertions avec 17 contrôles négatifs. Elle est passée du premier coup, ce qui est précisément le moment où une suite mérite le moins de confiance, et casser le moteur exprès a alors révélé trois vraies lacunes : aucune assertion ne portait sur une valeur de largeur fixe, si bien que les lire dans le mauvais ordre d'octets passait inaperçu ; rien ne se situait entre les deux seuils candidats de réinterprétation signée ; et aucune charge n'était à la fois de l'UTF-8 valide et des caractères de contrôle, seule forme capable d'exercer le test de texte.

Pourquoi est-ce gratuit ?

C'est de l'analyse d'octets, exécutée dans l'onglet que vous avez déjà ouvert. Aucun serveur ne voit vos octets : il n'y a donc rien à facturer ni de compte à créer.

Rien de ce que vous collez n'est envoyé, conservé ni journalisé. Des trames protobuf capturées contiennent couramment des identifiants, des jetons et des données personnelles, et cela mérite d'être dit clairement plutôt que laissé à votre supposition.