Entrée (schéma .proto)

Sortie (Go)

Ce que fait cet outil

Go est le langage natif de protobuf — la plupart des services gRPC en production sont écrits avec. Normalement, on génère du Go depuis un .proto via protoc-gen-go ou buf, ce qui suppose d'installer la toolchain, configurer un générateur et lancer une étape de build. Ce convertisseur fait la même chose dans votre navigateur — collez, copiez, déposez dans votre repo.

Le mapping des types suit ce que protoc-gen-go émet : string → string, bool → bool, bytes → []byte, les types entiers se mappent vers leurs équivalents int32/int64/uint32/uint64 (pas de perte de précision comme en JavaScript), double → float64, float → float32. Les champs de message singuliers sont des pointeurs (selon la convention des bindings Go officiels de protobuf), repeated T devient []T, map<K, V> devient map[K]V.

Les noms de champ reçoivent le traitement canonique Go en PascalCase, avec les acronymes courants en majuscules (order_id → OrderID, api_url → APIURL) selon le style de revue Go. Chaque champ reçoit des struct tags prêts à coller : protobuf:"varint,3,opt,name=status,proto3" pour le format wire et json:"status,omitempty" pour le marshalling JSON. La conversion est locale — votre .proto ne quitte jamais le navigateur. Pour du code de production, vous devrez quand même exécuter le vrai codegen pour obtenir les méthodes, descripteurs et plomberie de reflection — mais pour des esquisses, revues et scripts ponctuels, c'est plus rapide.

Comment l'utiliser

Trois étapes. La sortie est du Go prêt à coller qui compile tel quel avec la bibliothèque standard.

Collez votre schéma .proto

Déposez le schéma dans l'éditeur de gauche. syntax = "proto3"; en haut est OK mais optionnel. Le parser gère les blocs message imbriqués, les déclarations enum, oneof, map<K, V> et les options de champ. Les imports sont reconnus mais ignorés.

Les noms de champ se convertissent automatiquement de snake_case en PascalCase. Le convertisseur met en majuscules les suffixes d'acronymes courants (Id → ID, Url → URL) pour que la sortie passe revive / golint sans broncher.

Lisez la sortie

À droite : du Go avec un type X struct par message et un bloc type X int32 + const par enum. package proto en haut est un placeholder — remplacez-le par le vrai nom de votre package.

Branchez-le dans votre projet

Déposez le fichier dans votre projet, corrigez la déclaration package et importez. Pour du vrai code gRPC, vous voudrez quand même lancer protoc-gen-go pour récupérer les méthodes marshal/unmarshal. Cette sortie est destinée à du traitement JSON typé, des esquisses de structs et des revues — les méthodes du format wire protobuf ne sont pas générées ici.

Quand ça fait vraiment gagner du temps

Esquisser un service Go à partir d'un .proto existant

Vous montez un service Go qui consomme des messages Protobuf venant d'une autre équipe. Vous voulez les formes des structs pour les signatures de handlers et les réponses JSON sans monter tout le pipeline de codegen. Collez, déposez dans types.go, vous êtes typé.

Relire un changement d'API Protobuf pour un consommateur Go

Un coéquipier backend a ajouté des champs à un message. Collez le nouveau .proto, faites un diff de la sortie Go contre votre types.go actuel, laissez une revue ciblée. Plus rapide que de lancer la toolchain juste pour regarder le changement.

Vérification cross-langage

Vous avez un .proto consommé à la fois par des clients Go et TypeScript. Utilisez ceci côte à côte avec le convertisseur Protobuf vers TypeScript pour confirmer que les deux langages verront des noms et types de champs compatibles après l'encodage JSON.

Scripts d'intégration ponctuels

Vous écrivez un script Go de 50 lignes qui tape sur un endpoint gRPC-gateway. Monter protoc, buf et une config de générateur pour un seul script, c'est trop. Générez les structs ici, déposez-les, livrez le script.

Questions courantes

Est-ce un remplaçant de protoc-gen-go ?

Non. protoc-gen-go émet les méthodes binaires marshal/unmarshal, les descripteurs de fichier et la plomberie de reflection nécessaire au vrai gRPC. Ce convertisseur n'émet que les formes de struct et les tags. Si vous écrivez un vrai service gRPC, lancez le codegen officiel. Si vous voulez juste des types pour des réponses JSON, des scripts faits main ou des esquisses — c'est plus rapide.

Pourquoi les champs typés message sont des pointeurs ?

Ça reflète ce que fait protoc-gen-go pour les champs message en proto3 — ce sont des pointeurs pour que la zero value soit nil (distinguable d'un message présent mais vide). Les champs scalaires restent en valeur car leurs zero values sont elles-mêmes valides (chaîne vide, 0, false). Si pour une raison quelconque vous préférez non-pointeur, faites un find-replace sur les astérisques dans la sortie.

Comment les enums sont-ils émis ?

En typedefs Go int32 avec un bloc const, conformément aux conventions de protoc-gen-go. Chaque valeur d'enum devient une constante Go en PascalCase de ce type. Les assignations numériques viennent directement du .proto.

Et les struct tags protobuf ?

Chaque champ reçoit un tag protobuf:"..." avec le wire type (varint, fixed32, fixed64, bytes), le numéro de champ, le label (opt/rep), le nom et le marqueur proto3. Plus un tag json:"name,omitempty" avec le nom snake_case d'origine. Les tags pour map<K, V> sont simplifiés — pour une compatibilité stricte avec le format wire, lancez le vrai codegen.

Comment les noms de champ sont-ils convertis ?

snake_case → PascalCase, avec les suffixes d'acronymes courants en majuscules : order_id → OrderID, api_url → APIURL, data_json → DataJSON. Ça correspond aux conventions du style de revue Go pour que la sortie passe le lint sans nettoyage manuel.

Et si mon schéma importe un autre .proto ?

Les directives import sont reconnues et ignorées — les types de message inter-fichiers sont rendus avec leur nom feuille (foo.Bar → Bar) que Go ne résoudra que si ce type existe aussi dans le même package. Soit vous collez les messages importés en ligne, soit vous prévoyez de corriger les références dans la sortie.

Outils associés

Si vous travaillez avec Protobuf, JSON et Go, ceux-ci vont bien ensemble :

Convertisseur Protobuf vers Go