Décodeur Protocol Buffers

Ce qu’un décodeur Protobuf sans schéma peut établir

Protocol Buffers stocke une suite de tags de champ et de valeurs, pas les déclarations .proto d’origine. Le guide officiel de l’encodage protobuf définit chaque tag par (field_number << 3) | wire_type. Le décodeur peut donc établir le numéro de champ, le type wire, les limites en octets et les encodages structurellement possibles. Il ne peut pas déterminer si un varint a été déclaré comme uint64, int64, sint64, bool ou enum, car ces déclarations peuvent partager les mêmes octets.

Le mode d’entrée est toujours choisi explicitement. Le mode hexadécimal accepte les espaces ASCII et au plus un préfixe 0x. Base64 et Base64URL sont validés séparément, y compris leur longueur, leur padding et leurs bits de remplissage inutilisés ; les alphabets standard et compatible URL ne peuvent pas être mélangés. Le texte brut correspond exactement aux octets UTF-8 produits par le TextEncoder du navigateur : les séquences d’échappement avec barre oblique inverse ne sont pas interprétées. Pour un fichier, les octets exacts sont lus.

Types wire et interprétations

Le type Number ordinaire de JavaScript ne représente pas exactement tous les entiers 64 bits. Le parseur utilise donc BigInt de bout en bout et convertit les entiers exacts en chaînes décimales pour l’affichage et l’export. Les valeurs flottantes particulières comme NaN, les infinis et le zéro négatif sont aussi exportées sous forme de chaînes afin que JSON ne les transforme pas silencieusement.

Comprendre l’ambiguïté des valeurs délimitées par une longueur

Le type wire 2 sert aux chaînes, aux octets bruts, aux messages intégrés et aux valeurs scalaires répétées packed. Sans schéma, une même séquence d’octets peut remplir plusieurs rôles. Par exemple, 2a 03 01 02 03 est le champ 5 contenant trois octets. Ils forment des varints packed valides [1, 2, 3], mais restent aussi de simples octets. Le décodeur affiche les deux possibilités sans en présenter une comme plus probable.

Un candidat de message imbriqué n’apparaît que si tout le contenu délimité par la longueur forme un message complet. Les candidats varint, fixed32 et fixed64 packed ne sont également affichés que si leur interprétation consomme tous les octets. Un candidat UTF-8 strict exige que toute la séquence soit décodée sans caractère de remplacement. Ces vérifications indiquent des possibilités structurelles, et non le type déclaré du champ.

Les groupes sont analysés selon la grammaire wire, même si les schémas modernes préfèrent généralement les messages intégrés. Un tag de début de groupe doit être fermé par un tag de fin portant le même numéro de champ. Une fin au niveau racine, un numéro différent ou une fin manquante produit une erreur fatale à l’offset exact. Les champs complets décodés auparavant restent visibles ; les octets manquants et valeurs inconnues ne deviennent jamais un faux zéro.

Limites, framing et manipulation sûre

Le décodeur accepte un seul message sans framing, limité à 10 Mio. Il ne sépare pas un flux préfixé par une longueur, une frame gRPC, un fichier de messages délimités ni une enveloppe de transport. Retirez d’abord ce framing, puis décodez un message. Le parseur limite le nombre total d’enregistrements, la profondeur récursive, les lignes visibles et le travail consacré aux candidats. Ces protections suivent l’esprit des recommandations officielles sur les grands jeux de données et les limites d’implémentation : protobuf est efficace, mais un onglet de diagnostic doit tout de même borner sa mémoire et son travail.

Les numéros de champ doivent être compris entre 1 et 536 870 911. La plage 19 000–19 999 déclenche un avertissement, car les recommandations officielles sur les numéros de champ réservent cette plage à l’implémentation. Les types wire 6 et 7 sont invalides.

L’analyse et les exports se font localement. La vue en plusieurs étapes peut conserver un payload limité dans le sessionStorage de cet onglet pendant deux heures au maximum ; recommencer l’efface. Rien n’est ajouté à l’URL ni envoyé à nos serveurs. La sortie JSON est explicitement un rapport de décodage au format propre à cet outil, pas du ProtoJSON. Le CSV commence par un BOM UTF-8 et neutralise les cellules ressemblant à des formules pour une ouverture plus sûre dans un tableur. Un rapport peut malgré tout contenir des données applicatives confidentielles : vérifiez-le avant de le partager.