Protocol Buffers-avkodare

Steg 1 / 333%

Granska ett kodat Protocol Buffers-meddelande utan att ladda upp det eller låtsas känna till dess schema. Den webbläsarbaserade avkodaren tar uttryckligen emot hexadecimaldata, Base64, Base64URL, rå UTF-8-text eller en binärfil. Den går igenom alla giltiga wire-typer, håller 64-bitars heltal exakta, rapporterar byte-offset för felaktiga data och visar alla fullständiga tolkningar av tvetydiga längdavgränsade värden. Payloaden stannar i webbläsaren och tjänster som nämns i datan kontaktas aldrig.

Så fungerar det

  1. 1

    Välj exakt kodning

    Välj hex, Base64, Base64URL, rå UTF-8-text eller binärfil. Verktyget försöker aldrig gissa indataformatet.

  2. 2

    Granska wire-fälten

    Avkoda taggar, fältnummer och wire-värden och fäll ut varje giltig nästlad eller packed kandidat utan att tilldela en schematyp.

  3. 3

    Exportera rapporten

    Hämta en schemalös JSON-rapport, formelsäker CSV eller lättläst textrapport.

Vad en schemalös Protobuf-avkodare kan fastställa

Protocol Buffers lagrar en följd av fälttaggar och värden, inte de ursprungliga .proto-deklarationerna. Den officiella guiden till protobuf-kodning definierar varje tagg som (field_number << 3) | wire_type. Avkodaren kan därför fastställa fältnummer, wire-typ, bytegränser och strukturellt möjliga kodningar. Den kan inte avgöra om en varint deklarerades som uint64, int64, sint64, bool eller enum, eftersom de kan dela samma byte.

Indataläget väljs alltid uttryckligen. Hex tillåter ASCII-blanksteg och högst ett inledande 0x. Base64 och Base64URL valideras separat, inklusive längd, padding och oanvända paddingbitar; standardalfabet och URL-säkert alfabet får inte blandas. Rå text betyder exakt de UTF-8-byte som webbläsarens TextEncoder skapar, backslash-escapes tolkas inte. Filinmatning använder filens exakta byte.

Wire-typer och tolkningar

Wire-typ Kodat värde Vad rapporten visar
0 Varint Exakta osignerade värden, signerade tvåkomplementsvärden och ZigZag; booleskt endast för 0 eller 1
1 Åtta little-endian-byte Exakta fixed64- och sfixed64-heltal samt en double-kandidat
2 Längd följd av byte Hex och Base64, strikt UTF-8 när giltigt samt alla fullständiga nästlade eller packed kandidater
3 / 4 Gruppens start- och sluttaggar Underfält i gruppen med samma fältnummer; sluttaggen avgränsar och är ingen separat post
5 Fyra little-endian-byte Exakta fixed32- och sfixed32-heltal samt en float-kandidat

JavaScripts vanliga Number-typ kan inte representera alla 64-bitars heltal exakt. Parsern använder därför BigInt genomgående och gör exakta heltal till decimalsträngar för visning och export. NaN, oändligheter och negativ noll exporteras också som strängar så att JSON inte ändrar dem tyst.

Förstå tvetydiga längdavgränsade värden

Wire-typ 2 används för strängar, råa byte, inbäddade meddelanden och packed upprepade skalärvärden. Utan schema kan samma byteföljd ha flera roller. 2a 03 01 02 03 är exempelvis fält 5 med tre byte. De är giltiga packed varints [1, 2, 3], men också vanliga byte. Avkodaren visar båda utan att rangordna dem.

En nästlad meddelandekandidat visas bara om hela kroppen kan tolkas som ett fullständigt meddelande. Packed varint-, fixed32- och fixed64-kandidater visas bara om tolkningen förbrukar alla byte. Strikt UTF-8 måste avkoda hela sekvensen utan ersättningstecken. Kontrollerna visar strukturella möjligheter, inte fältets deklarerade typ.

Grupper hanteras enligt wire-grammatiken även om moderna scheman oftast använder inbäddade meddelanden. En starttagg måste avslutas med en sluttagg med samma fältnummer. Ett slut på rotnivå, fel nummer eller saknad avslutning ger ett allvarligt fel vid exakt byte-offset. Tidigare fullständiga fält ligger kvar; saknade byte och okända värden blir aldrig en påhittad nolla.

Gränser, framing och säker hantering

Avkodaren tar ett oframat meddelande upp till 10 MiB. Den delar inte längdprefixade strömmar, gRPC-frames, filer med avgränsade meddelanden eller transporthöljen. Ta först bort framing och avkoda sedan ett meddelande. Parsern begränsar poster, rekursionsdjup, synliga rader och kandidatarbete enligt andemeningen i de officiella råden om stora datamängder och implementationsgränser.

Fältnummer måste ligga mellan 1 och 536 870 911. Intervallet 19 000–19 999 ger en varning eftersom den officiella fältnummerguiden reserverar området för implementationer. Wire-typerna 6 och 7 är ogiltiga.

Analys och export sker lokalt. Flerstegsvyn kan lagra en begränsad payload i flikens sessionStorage i högst två timmar; att börja om raderar den. Inget läggs i webbadressen eller skickas till våra servrar. JSON-resultatet är en avkodningsrapport i verktygets eget format, inte ProtoJSON. CSV börjar med en UTF-8-BOM och oskadliggör formelliknande celler för säkrare öppning i kalkylblad. Rapporter kan ändå innehålla konfidentiella data, kontrollera dem innan de delas.

Vanliga frågor

Nej. Wire-formatet bevarar fältnummer och wire-kodningar, men olika deklarerade skalärtyper kan ha samma byte. Namn, kommentarer och det mesta av schemats avsikt saknas.

Nej. Indatavalidering, parsning, filtrering och export körs i webbläsaren. Payloaden skickas inte till våra servrar och placeras inte i webbadressen.

Ett längdavgränsat värde kan vara byte, UTF-8-text, ett inbäddat meddelande eller packed värden. Utan schema är det sannare att visa alla fullständiga kandidater än att gissa.

Där var en tagg, varint, ett värde med fast bredd, en deklarerad längd eller gruppgräns ofullständig eller ogiltig. Tidigare fullständiga fält finns kvar i delrapporten.

Inte direkt. Avkodaren läser ett protobuf-meddelande och tar inte bort gRPC-, varintlängds- eller annan transportframing. Extrahera först payloaden för ett meddelande.

Relaterade verktyg

Verktyget finns på andra språk