Collez une définition Protocol Buffers pour examiner les champs et signatures RPC détectés. L’outil décrit la structure sans compiler de code client.
Fonctionne localement dans votre navigateurCollez une définition Protocol Buffers puis cliquez sur Inspecter localement : la page énumère ce qu’elle peut lire du texte — la ligne de syntaxe, le paquet, chaque message avec ses champs dans l’ordre du fichier, les énumérations avec leurs valeurs, les groupes oneof et les services gRPC avec leurs méthodes, les appels en streaming étant signalés. Un exemple JSON structurel est construit pour le premier message du fichier. Rien n’est compilé ni téléversé : pas de protoc, pas d’appel gRPC, pas d’aller-retour serveur.
L’analyse traite de la même façon un texte proto2 et proto3, par motifs, et rend donc ce qui est écrit plutôt que ce que protoc en ferait. Panneau réseau du navigateur ouvert, inspecter une définition ne déclenche aucune requête ; le résumé, les compteurs et le tableau sont remplis dans l’onglet.
Les valeurs sont typées comme le JSON proto3 les encode : un champ string reçoit "example", int64 et uint64 deviennent la chaîne "0", bytes devient "base64-data", bool devient true et un champ repeated est un tableau d’un élément. Un champ map devient un objet à une clé d’exemple, et un champ de type message est développé en objet imbriqué.
Un champ d’énumération prend la première valeur déclarée dans cette énumération : un champ Currency vaut donc "CURRENCY_UNSPECIFIED" et non un nombre. Un message qui se référence lui-même s’arrête sur un objet vide, ce qui garde l’exemple fini, et seul le premier message du fichier en reçoit un — placez en tête le type qui vous intéresse.
Quand un type de champ n’est pas déclaré dans le texte collé — google.protobuf.Timestamp par exemple, ou un message venu d’un import — l’exemple affiche un objet vide et le panneau ajoute une note du type « 1 field type(s) come from imported or external definitions ». Le nom du type reste présent dans le résumé et dans le tableau.
L’outil ne récupère jamais ce fichier importé : une ligne import ne change rien à la sortie et aucune requête ne quitte la page. Voyez l’exemple comme un croquis structurel à confronter au schéma réel, pas comme une charge utile à envoyer telle quelle à un serveur.
Les commentaires sont ignorés, // comme /* */, et les caractères à l’intérieur d’une chaîne littérale ne sont pas interprétés : une valeur par défaut telle que [default = "{"] est donc lue correctement. Un message imbriqué devient une entrée à part entière sous un nom pointé, et le message parent ne liste que les champs déclarés directement chez lui.
Quelques lignes sont écartées volontairement : les déclarations reserved, les plages extensions, les options de fichier comme option java_package = "com.acme"; et les lignes import. Elles n’apparaissent ni dans le résumé, ni dans le tableau, ni dans les compteurs — la sortie ne décrit que messages, énumérations, champs et RPC.
Un texte sans déclaration de message, d’énumération ou de service s’arrête sur « No message, enum or service declaration was found in this .proto text. », et un bloc non fermé sur le nom du bloc, comme « Unclosed message block: User ». L’analyse par motifs implique aussi l’absence de validation de niveau protoc : un numéro de champ en double, l’étiquette 0 et une étiquette de la plage réservée 19000–19999 sont listés sans broncher.
La sortie énumère tout ce qu’elle trouve et grandit donc avec le fichier : 305 Ko contenant 600 messages ont produit 12 200 lignes en environ un tiers de seconde, et 1,5 Mo avec 3 000 messages et 60 200 lignes ont pris moins de deux secondes dans Chrome. Une ligne d’énumération montre ses 12 premières valeurs puis des points de suspension, alors que le résumé les imprime toutes.