Entrée (JSON)

Sortie (schéma .proto)

Ce que fait cet outil

Tu as un payload JSON réel — un exemple de réponse d’API, un body de webhook, une ligne d’un store NoSQL — et tu veux le modéliser comme un message Protocol Buffers ? Taper le schéma à la main, c’est lent et facile à louper, surtout avec des objets et tableaux imbriqués. Ce convertisseur parcourt le JSON, infère les types Protobuf pour chaque champ et sort un schéma proto3 propre que tu peux poser direct dans ton projet.

L’inférence de types suit ce que tu écrirais toi-même : string pour les chaînes, bool pour les booléens, int32 pour les entiers qui rentrent en 32 bits, int64 pour les autres, double pour les nombres non entiers, repeated <T> pour les tableaux d’un type d’élément uniforme (un message imbriqué réutilisé pour les tableaux d’objets) et des blocs message imbriqués pour les objets imbriqués. JSON ne sait pas distinguer une struct d’une map, donc tous les objets sortent en messages imbriqués — remplace par map<K, V> à la main si tes données sont vraiment une map.

Les noms de champs passent du camelCase ou kebab-case au snake_case conventionnel en Protobuf. Les numéros de champ sont assignés 1, 2, 3, … dans l’ordre de déclaration. La sortie est du proto3 valide — colle-la dans un fichier .proto, lance protoc ou buf, et tu as du code généré dans le langage de ton choix. La conversion tourne entièrement dans ton navigateur — aucun JSON, aucun nom de champ, aucune valeur n’est envoyée nulle part.

Comment l’utiliser

Trois étapes. Marche avec n’importe quel objet JSON bien formé — réponses d’API, entrées de log, fichiers de fixtures, peu importe.

Colle ton JSON

Mets le JSON dans l’éditeur de gauche. La racine doit être un objet ({ ... }) — emballe un tableau dans un objet d’abord si tes données partent d’un tableau, p. ex. { "items": [...] }. Utilise des données réalistes : plus l’échantillon est représentatif, mieux les types inférés colleront à ce que tu veux à long terme.

Si ton JSON a des clés sans guillemets, des virgules finales ou d’autres bizarreries, fais-le passer par le JSON Fixer d’abord — Protobuf a besoin d’un objet propre pour bosser.

Clique sur Convertir

Clique sur le bouton vert Convertir. Le convertisseur parcourt chaque clé du JSON, choisit un type Protobuf, construit des blocs message imbriqués pour les objets imbriqués et sort le schéma avec syntax = "proto3"; en haut. Les numéros de champ sont assignés dans l’ordre source.

Utilise le .proto

Copie le schéma dans un fichier .proto de ton repo. Vérifie les types inférés — pour les champs où l’échantillon JSON était vide (tableau vide, null), tu verras un commentaire signalant que le type a été deviné. Ajuste si besoin, puis lance protoc ou buf generate pour produire du code dans ton langage.

Quand ça fait vraiment gagner du temps

Modéliser une API tierce en Protobuf

Un fournisseur renvoie du JSON. Ton service stocke du Protobuf. Prends une vraie réponse, colle-la ici, récupère un schéma de départ pour le type, puis affine. Plus rapide que lire la doc et taper 50 champs à la main.

Migrer un service basé sur JSON vers gRPC

Tu déplaces un microservice HTTP+JSON vers gRPC. Chaque forme de requête et de réponse a besoin d’un .proto. Convertis chaque payload capturé en schéma Protobuf, colle-les dans un seul fichier, et le contrat est ébauché.

Démarrer un module Buf

Tu mets en place un nouveau module Buf et tu as besoin de schémas réalistes pour démarrer ? Convertis tes fixtures JSON existantes et utilise la sortie comme graine pour tes fichiers .proto — bien plus rapide que de les taper à partir de zéro.

Écrire des fixtures de test pour du code Protobuf

Ton équipe a des données de test en JSON. Le nouveau code consomme du Protobuf. Génère le <code>.proto</code> à partir du JSON, puis laisse ton codegen construire les types — tes fixtures et ton code restent synchronisés.

Questions courantes

Mon JSON est-il envoyé quelque part ?

Non. Le convertisseur tourne entièrement dans ton navigateur en JavaScript. Ton JSON — clés, valeurs, ce qui est sensible — ne quitte jamais ta machine. Ouvre les DevTools et regarde l’onglet Network pendant que tu cliques Convertir. Zéro requête.

Comment choisit-il entre int32, int64 et double ?

Pour les valeurs entières, il vérifie si la valeur rentre dans un intervalle signé 32 bits (-2^31 à 2^31-1). Si oui, int32. Sinon, int64. Les nombres non entiers deviennent toujours double. Si tu sais que tes données sont non signées ou que tu veux une largeur précise comme fixed32, édite la sortie — vois la table des types scalaires pour tous les types numériques disponibles et leurs compromis d’encodage sur le câble.

Quand un objet devient-il une map plutôt qu’un message imbriqué ?

Toujours un message imbriqué — jamais une map. JSON ne distingue pas une struct d’une map, donc deviner l’un ou l’autre se trompe environ une fois sur deux. Si tes données sont en fait une map clé-valeur (p. ex. métadonnées, headers, feature flags), ouvre la sortie et remplace message Foo { ... } par map<string, V> foo = N; à la main. Le correctif est mécanique et évident dès que tu vois tes données.

Et les null et tableaux vides ?

Les deux produisent un commentaire en sortie signalant que le type a été deviné depuis un échantillon dégénéré. null retombe sur string avec une note "nullable". Les tableaux vides retombent sur repeated string avec une note "empty array". Remplace ces types par ce que tu attends vraiment.

Pourquoi les tableaux de types mixtes sortent-ils en repeated string ?

Protobuf ne supporte pas les listes hétérogènes directement. Si ton tableau JSON a des types mixtes (des chaînes, des nombres), il n’y a pas d’équivalent Protobuf propre — il te faut soit google.protobuf.Value, un oneof, soit refondre la forme des données. Le convertisseur le signale avec un commentaire pour que tu décides.

Gère-t-il du JSON profondément imbriqué ?

Oui. Chaque objet imbriqué devient un message imbriqué avec un nom dérivé en PascalCase. La profondeur d’imbrication n’est bornée que par la profondeur de pile, pas par le convertisseur — même les réponses d’API très imbriquées se convertissent proprement.

Puis-je faire un aller-retour JSON ↔ Protobuf avec ces deux outils ?

À peu près. JSON vers Protobuf te donne un schéma ; Protobuf vers JSON te donne un échantillon. Les formes correspondent pour les champs où l’échantillon JSON avait une valeur représentative. Là où le JSON avait null ou des tableaux vides, le type Protobuf inféré est une supposition et l’aller-retour ne sera exact qu’après que tu auras corrigé le type.

Outils liés

Si tu jongles avec du JSON et des schémas, ceux-ci se complètent bien :

Convertisseur JSON vers Protobuf