Wejście (schemat .proto)

Wyjście (próbka JSON)

Co robi to narzędzie

Masz schemat Protocol Buffers i potrzebujesz przykładu JSON tego, jak wygląda jedna z tych wiadomości — do test fixture, przykładu OpenAPI, zaślepionej odpowiedzi gRPC, czego tam chcesz. Ręczne wpisywanie kształtu JSON z długiego pliku .proto jest żmudne i pełne pomyłek. Ten konwerter czyta schemat, bierze ostatnio zadeklarowany message (typowy "zewnętrzny" typ) i emituje obiekt JSON pasujący pole-po-polu.

Wyjście używa oficjalnych domyślnych wartości proto3: pusty string dla string i bytes, 0 dla typów liczbowych, false dla bool, [] dla repeated, {} dla map oraz stała enum o wartości zerowej dla pól enum. Zagnieżdżone wiadomości są rozwijane rekurencyjnie. 64-bitowe liczby całkowite wychodzą jako stringi JSON, zgodnie ze specyfikacją mapowania JSON proto3 — nie wciśniesz int64 do Number w JS bez utraty precyzji.

Wszystko dzieje się lokalnie w przeglądarce — żadnego uploadu .proto, żadnego schematu wysyłanego na serwer, żadnego wywołania inferencji. Tylko ręcznie napisany parser, który ogarnia dyrektywy syntax/package/import, komentarze (liniowe i blokowe), zagnieżdżone bloki message i enum, oneof, map<K, V>, repeated, optional oraz opcje pól (czytane, ale ignorowane). Jeśli potrzebujesz pełnego runtime w stylu protobufjs, to inny temat — ale do "daj mi kształt JSON z tego schematu" to szybsze.

Jak używać

Trzy kroki. Wyjściowy JSON jest gotowy do wklejenia w fixture, blok przykładu lub body żądania od razu.

Wklej swój schemat .proto

Rzuć schemat do lewego edytora. syntax = "proto3"; na górze jest OK, ale opcjonalne — parser ma to gdzieś. Komentarze, deklaracje package i instrukcje import są wszystkie czysto pomijane. Jeśli masz wiele wiadomości, parser bierze ostatnią message najwyższego poziomu (typowy zewnętrzny/złożony typ) jako root.

Chcesz konwertować inną wiadomość? Przesuń tę, której chcesz, na sam dół pliku. Schemat może zawierać typy zagnieżdżone, enumy i bloki oneof — wszystko się rozwiąże.

Wciśnij Convert

Kliknij zielony przycisk Convert. Parser tokenizuje schemat, buduje drzewo wiadomości i przechodzi po wiadomości root, emitując domyślne wartości proto3 dla każdego pola. Zagnieżdżone wiadomości są rozwijane inline. Pola repeated dają jednoelementową tablicę jako podpowiedź kształtu elementu — pusta tablica nie pokazałaby struktury.

Użyj JSON-a

Skopiuj wynik do test fixture, do bloku przykładu w OpenAPI, do moka gRPC-Web, lub gdzie tylko potrzebujesz kształtu request/response. Klucze pasują dokładnie do nazw pól z .proto — przełącz na camelCase później, jeśli twój codegen tak robi.

Kiedy faktycznie oszczędza czas

Stubowanie odpowiedzi gRPC do testów

Twój handler serwisowy zwraca odpowiedź Protobuf. Test jednostkowy potrzebuje fixture JSON pasującego do kształtu wiadomości. Wklej <code>.proto</code>, weź JSON, wrzuć do folderu fixtures. Koniec z ręcznym wpisywaniem 30 pól i pomijaniem jednego.

Przykłady OpenAPI dla gRPC-gateway

Używasz grpc-gateway lub podobnego, aby wystawiać usługi Protobuf jako REST? Każda operacja chce przykładu JSON. Konwertuj każdą wiadomość .proto na szkielet JSON i wklej pod kluczem example w swoim spec.

Punkt wyjścia dla JSON Schema

Chcesz walidować żądania JSON pasujące do kontraktu <code>.proto</code>. Najpierw konwertuj na próbkę JSON, podaj ją narzędziu typu JSON-Schema-from-sample i masz schemat startowy w kilka sekund.

Wypełnianie ciał żądań w klientach API

Testujesz API gRPC z transkodowaniem HTTP w Postman lub curl? Wklej .proto, skopiuj szkielet JSON do body żądania, wypełnij wartości, które naprawdę chcesz wysłać.

Częste pytania

Czy mój schemat .proto jest gdziekolwiek wysyłany?

Nie. Parsing odbywa się w całości w przeglądarce przez JavaScript. Nic ze schematu — nazwy wiadomości, nazwy pól, ścieżki package — nie opuszcza twojego komputera. Otwórz DevTools i zerknij na zakładkę Network, klikając Convert. Zero żądań.

Obsługuje proto2 tak samo jak proto3?

W większości tak. Parser radzi sobie z tokenami składni proto2 jak required i optional, ale wartości wyjściowe używają domyślnych wartości proto3 (to, co specyfikuje mapowanie JSON proto3). Jeśli masz plik proto2 z jawnymi wartościami domyślnymi przez [default = ...], te wartości nie są stosowane na wyjściu.

Jak wybiera, którą wiadomość konwertować?

Używa ostatniej message najwyższego poziomu zadeklarowanej w pliku. W rzeczywistych schematach typ zewnętrzny/złożony zwykle jest deklarowany po swoich zależnościach, więc to pasuje do tego, czego chcesz. Jeśli wybierze złą, zmień kolejność w pliku tak, by twoja wiadomość była ostatnia.

Dlaczego wartości int64 są stringami na wyjściu?

Bo JSON ma tylko IEEE-754 double, które tracą precyzję powyżej 2^53. Oficjalne mapowanie JSON proto3 wymaga, aby int64, uint64, fixed64, sfixed64, sint64 były kodowane jako stringi JSON. Trzymamy się tej konwencji.

A co z oneof, map i repeated?

Wszystkie trzy działają. Pola oneof są parsowane jak zwykłe pola (obiekt JSON zawiera wszystkie zamiast wybierać jedno — typowo kasujesz te, których nie chcesz). map<K, V> emituje pusty obiekt {}. repeated emituje jednoelementową tablicę pokazującą kształt elementu — możesz duplikować lub usuwać, by pasowało do twoich rzeczywistych danych.

Czy podąża za importami?

Nie. Instrukcje import są rozpoznawane i pomijane. Typy wiadomości między plikami rozwiązują się do null na wyjściu. Jeśli potrzebujesz rozwiązywania międzyplikowego, wklej odpowiednie wiadomości z importowanych plików do tego samego wejścia.

Jak duży schemat może obsłużyć?

Dziesiątki tysięcy linii, bez problemu. Wszystko jest lokalne, więc nie ma uploadu, rate limitu ani opóźnienia sieci.

Powiązane narzędzia

Jeśli walczysz z Protobuf, JSON i schematami, te dobrze się uzupełniają:

Konwerter Protobuf na JSON