Inndata (.proto-skjema)

Utdata (formatert .proto)

Hva dette verktøyet gjør

Du limer inn et Protocol Buffers-skjema med blandet innrykk, sammenklemte feltdeklarasjoner eller tilfeldige tomme linjer fra et copy-paste, og du vil at det skal se ut som resten av kodebasen. Denne formatereren skriver om filen med to mellomrom innrykk per klammenivå, nøyaktig ett mellomrom rundt =, ett mellomrom etter ,, og maks én sammenhengende tom linje mellom blokker. Kommentarer — både //-linjekommentarer og /* ... */-blokkommentarer — blir akkurat der du satte dem.

Den parser ikke og validerer ikke skjemaet, noe som betyr at den fungerer på lett ødelagt input der buf format eller editorens "Format Document" kanskje ikke får det til. Hvis .proto-filen din har en syntaksfeil et eller annet sted, blir resten av filen formatert rundt den uansett. Baksiden: den kan ikke omarrangere felter, normalisere import-rekkefølge eller plukke bort ubrukte options slik en ekte parser-basert formaterer kunne. Til det kjører du buf format i build-pipelinen din.

Alt kjører i nettleseren din — ingen opplasting, ingen rate limit, intet skjema sendes noe sted. Praktisk når skjemaet inneholder interne pakkenavn, typenavn eller annet du ikke vil sende til en tredjeparts-API. Funker på enhver filstørrelse nettleseren klarer å holde i minnet; selv titusenvis av linjer formateres på godt under et sekund.

Slik bruker du det

Tre steg. Utdataene oppdateres ca. 300 ms etter at du slutter å skrive.

Lim inn .proto-skjemaet ditt

Slipp skjemaet inn i den venstre editoren. syntax, package, import-direktiver, message-blokker, nøstede enum-er, oneof, map<K, V> — alt håndteres. Blandede linjeskift (CRLF) normaliseres til LF på veien ut.

Formatereren omarrangerer ingenting — felter, importer og options blir i den rekkefølgen du skrev dem. Vil du ha kanonisk rekkefølge, kjør buf format etterpå.

Les den formaterte utdataen

Til høyre: samme skjema, innrykket med 2 mellomrom per {-nivå. Linjer som starter med } trekkes ut et nivå før de skrives. Flere sammenhengende tomme linjer slås sammen til én. Etterhengende mellomrom fjernes. Kommentarer beholdes ord for ord, inkludert relativ posisjon.

Bruk resultatet

Kopier tilbake til editoren din eller last ned som formatted.proto. For protoc er utdata byte-for-byte ekvivalent med inndata — kun whitespace endres — så du kan slippe det inn igjen uten å bekymre deg om wire format eller forskjeller i generert kode. Verifiser ved å kjøre protoc --descriptor_set_out=before.pb input.proto og det samme på den formaterte utdataen: descriptors vil matche.

Når det faktisk sparer tid

Rydde opp i .proto limt inn fra chat eller dokumentasjon

En kollega limer inn et skjemafragment i Slack, innrykket er ødelagt, og du vil ha det i repoet ditt. Slipp det inn her, kopier den formaterte versjonen, lim inn i filen din. Raskere enn "merk alt, fanebytte"-dansen i editoren.

Standardisere legacy-.proto i et gammelt repo

Du har arvet et Protobuf-repo der hver fil bruker ulik innrykk. Kjør hver fil gjennom denne formatereren, push som én enkelt normaliserings-commit, og slå deretter på buf format i CI for å holde det sånn.

Sjekke en generert .proto raskt

Noen kodegeneratorer (JSON Schema → Protobuf, OpenAPI → Protobuf) spytter ut gyldige, men stygge skjemaer. Formater utdataen, kikk på den, og bestem om du holder på generatoren eller redigerer for hånd.

Når du ikke kan installere protoc eller buf

Du sitter på en låst maskin, på et gjestenett, eller bare reviewer en PR i nettleseren. Den nettleserbaserte formatereren gir deg den samme lesbare utdataen uten at du må installere Protocol Buffers-verktøykjeden.

Vanlige spørsmål

Sendes skjemaet mitt noe sted?

Nei. Formatereren kjører helt og holdent i nettleseren som JavaScript. Ingenting om skjemaet — message-navn, pakkestier, kommentarer — forlater maskinen din. Åpne DevTools og kikk på Network-fanen mens du limer inn; du vil se null requests.

Beholdes kommentarer?

Ja — både //-enkeltlinjekommentarer og /* ... */-blokkommentarer blir akkurat der du satte dem. Kommentarer på en egen linje beholder sin relative posisjon; trailing-kommentarer i slutten av en feltlinje henger igjen på det feltet. Den linjebaserte tilnærmingen ble valgt akkurat for at kommentarer skulle overleve intakt.

Hvordan skiller dette seg fra buf format?

buf format parser skjemaet inn i et syntakstre og skriver det ut på nytt. Det gir sterkere garantier — kanonisk option-rekkefølge, ensartet enum-bokstavkasus osv. — men det krever at skjemaet parses rent. Denne formatereren er linjebasert, så den fungerer på lett ødelagt input som buf ville avvist, og den tvinger ikke fram kanonisk rekkefølge. For ferdig kode, kjør buf format. For skjemaer midt i redigering eller fragmenter fra tredjepart, bruk denne.

Endrer den skjemaets semantikk?

Nei — kun whitespace endres. protoc ville produsert samme FileDescriptorProto fra både inndata og utdata. Du kan verifisere med protoc --descriptor_set_out=before.pb input.proto mot det samme på den formaterte filen; binær-descriptors er identiske bortsett fra eventuelle source-info-span-endringer (det er reflection-metadata, ikke wire format).

Og innrykksbredden — kan jeg gå bort fra 2 mellomrom?

Utdataene er fastsatt til 2 mellomrom per klammenivå, i tråd med konvensjonen i den offisielle Protocol Buffers-stilguiden. Trenger du 4 mellomrom eller tabber, kjør utdataene gjennom sed eller editorens tab-konvertering. Å holde formatererens utdata kanonisk hindrer konfigurasjonsdrift mellom team.

Håndterer den CRLF-linjeskift?

Ja — inndata med CRLF (\r\n) normaliseres til LF (\n) på veien ut. Trenger du CRLF i den lagrede filen, vil editoren din kode om ved lagring basert på sin egen linjeskift-innstilling.

Relaterte verktøy

Hvis du jobber med Protobuf-skjemaer, passer disse godt sammen:

Protobuf-formaterer