Protocol-Buffers-Decoder

Was ein Protobuf-Decoder ohne Schema belegen kann

Protocol Buffers speichert eine Folge von Feld-Tags und Werten, nicht die ursprünglichen .proto-Deklarationen. Der offizielle Leitfaden zur Protobuf-Codierung definiert jeden Tag als (field_number << 3) | wire_type. Damit kann dieser Decoder Feldnummer, Wire-Typ, Bytegrenzen und strukturell mögliche Codierungen sicher bestimmen. Ob ein Varint als uint64, int64, sint64, bool oder Enum deklariert wurde, lässt sich nicht beweisen, da dieselben Bytes zu mehreren Deklarationen passen können.

Der Eingabemodus ist immer ausdrücklich gewählt. Hex erlaubt ASCII-Leerraum und höchstens ein führendes 0x. Base64 und Base64URL werden getrennt geprüft, einschließlich Länge, Padding und ungenutzter Padding-Bits; Standard- und URL-sicheres Alphabet dürfen nicht vermischt werden. Roher Text bezeichnet genau die UTF-8-Bytes des browserseitigen TextEncoder, Backslash-Escapes werden nicht ausgewertet. Bei Dateien werden die exakten Bytes gelesen.

Wire-Typen und Deutungen

Der gewöhnliche JavaScript-Zahlentyp kann nicht jede 64-Bit-Ganzzahl exakt darstellen. Deshalb verwendet der Parser durchgehend BigInt und wandelt exakte Ganzzahlen für Anzeige und Export in Dezimalstrings um. Besondere Gleitkommawerte wie NaN, Unendlichkeiten und negative Null werden ebenfalls als Strings exportiert, damit JSON sie nicht unbemerkt verändert.

Mehrdeutige längencodierte Werte verstehen

Wire-Typ 2 dient für Strings, Rohbytes, eingebettete Nachrichten und gepackte wiederholte Skalarwerte. Ohne Schema kann dieselbe Bytefolge mehrere Rollen erfüllen. 2a 03 01 02 03 ist beispielsweise Feld 5 mit drei Bytes. Diese sind gültige gepackte Varints [1, 2, 3], zugleich aber auch gewöhnliche Bytes. Der Decoder zeigt beide Möglichkeiten, ohne eine davon als wahrscheinlicher einzustufen.

Ein Kandidat für eine verschachtelte Nachricht erscheint nur, wenn sich der gesamte längencodierte Inhalt als vollständige Nachricht lesen lässt. Kandidaten für gepackte Varints, fixed32 und fixed64 werden ebenfalls nur angezeigt, wenn ihre Deutung alle Bytes verbraucht. Strenges UTF-8 muss vollständig ohne Ersatzzeichen decodierbar sein. Diese Prüfungen zeigen strukturelle Möglichkeiten, nicht den deklarierten Feldtyp.

Gruppen werden gemäß Wire-Grammatik verarbeitet, auch wenn moderne Schemas meist eingebettete Nachrichten verwenden. Ein Start-Tag muss mit einem End-Tag derselben Feldnummer schließen. Ein End-Tag auf Wurzelebene, eine abweichende Nummer oder ein fehlender Abschluss erzeugt einen fatalen Fehler an der exakten Byteposition. Vorher vollständig decodierte Felder bleiben sichtbar; fehlende Bytes und unbekannte Werte werden nie zu einer erfundenen Null.

Grenzen, Framing und sicherer Umgang

Der Decoder verarbeitet genau eine ungeframte Nachricht bis 10 MiB. Er zerlegt weder längenpräfixierte Streams noch gRPC-Frames, Dateien mit getrennten Nachrichten oder Transporthüllen. Entfernen Sie zuerst das Framing und decodieren Sie dann eine Nachricht. Grenzen für Datensätze, Rekursionstiefe, sichtbare Zeilen und Kandidatenarbeit schützen Speicher und Browser-Tab. Sie folgen dem Gedanken der offiziellen Hinweise zu großen Datenmengen und Implementierungsgrenzen.

Feldnummern müssen zwischen 1 und 536.870.911 liegen. Für 19.000–19.999 erscheint eine Warnung, weil die offizielle Feldnummern-Richtlinie diesen Implementierungsbereich reserviert. Wire-Typen 6 und 7 sind ungültig.

Decodierung und Export laufen lokal. Die mehrstufige Ansicht kann begrenzte Nutzdaten bis zu zwei Stunden im sessionStorage dieses Tabs halten; „Neu beginnen“ löscht sie. Nichts landet in der URL oder wird an unsere Server gesendet. Die JSON-Ausgabe ist ausdrücklich ein Decodierbericht im eigenen Format dieses Tools, kein ProtoJSON. CSV-Dateien beginnen mit einer UTF-8-BOM und entschärfen formelartige Zellen für sichereres Öffnen in Tabellenkalkulationen. Berichte können dennoch vertrauliche Anwendungsdaten enthalten, prüfen Sie sie vor dem Teilen.