Dekoder Protocol Buffers

Co może potwierdzić dekoder Protobuf bez schematu

Protocol Buffers przechowuje sekwencję tagów pól i wartości, a nie pierwotne deklaracje .proto. Oficjalny przewodnik po kodowaniu protobuf definiuje tag jako (field_number << 3) | wire_type. Dekoder może więc potwierdzić numer pola, typ wire, granice bajtów i strukturalnie możliwe kodowania. Nie ustali, czy varint zadeklarowano jako uint64, int64, sint64, bool czy enum, ponieważ różne deklaracje mogą mieć identyczne bajty.

Tryb wejścia jest zawsze wybierany jawnie. Zapis szesnastkowy dopuszcza białe znaki ASCII i co najwyżej jeden początkowy prefiks 0x. Base64 i Base64URL są sprawdzane osobno, łącznie z długością, paddingiem i niewykorzystanymi bitami dopełnienia; nie wolno mieszać alfabetu standardowego z URL-safe. Surowy tekst oznacza dokładnie bajty UTF-8 utworzone przez przeglądarkowy TextEncoder, sekwencje ucieczki z ukośnikiem wstecznym nie są interpretowane. Plik jest odczytywany bajt w bajt.

Typy wire i interpretacje

Zwykły typ Number w JavaScript nie reprezentuje dokładnie każdej liczby 64-bitowej. Parser używa BigInt i konwertuje dokładne liczby całkowite na ciągi dziesiętne do wyświetlania i eksportu. Specjalne wartości zmiennoprzecinkowe, takie jak NaN, nieskończoności i ujemne zero, także są eksportowane jako tekst, aby JSON nie zmienił ich po cichu.

Niejednoznaczność wartości poprzedzonych długością

Typ wire 2 służy do zapisu ciągów, surowych bajtów, wiadomości osadzonych i spakowanych powtarzanych wartości skalarnych. Bez schematu jeden ciąg bajtów może pełnić kilka ról. Na przykład 2a 03 01 02 03 to pole 5 z trzema bajtami. Są one prawidłowymi spakowanymi varintami [1, 2, 3], ale też zwykłymi bajtami. Dekoder pokazuje obie możliwości bez wskazywania bardziej prawdopodobnej.

Kandydat na wiadomość zagnieżdżoną pojawia się tylko wtedy, gdy cała zawartość tworzy kompletną wiadomość. Kandydaty packed varint, fixed32 i fixed64 również wymagają zużycia wszystkich bajtów. Ścisły kandydat UTF-8 musi dekodować całą sekwencję bez znaków zastępczych. To możliwości strukturalne, nie deklarowany typ pola.

Grupy są obsługiwane zgodnie z gramatyką wire, chociaż nowoczesne schematy zwykle wybierają wiadomości osadzone. Tag początku grupy musi mieć tag końcowy z tym samym numerem pola. Koniec na poziomie głównym, inny numer lub brak zamknięcia powoduje błąd krytyczny przy dokładnym offsecie. Wcześniejsze kompletne pola pozostają widoczne; brakujące bajty i nieznane wartości nigdy nie stają się fałszywym zerem.

Limity, framing i bezpieczna obsługa

Dekoder przyjmuje jedną wiadomość bez framingu o rozmiarze do 10 MiB. Nie rozdziela strumienia z prefiksem długości, ramek gRPC, plików z rozdzielonymi wiadomościami ani kopert transportowych. Najpierw usuń framing, a potem zdekoduj jedną wiadomość. Parser ogranicza liczbę rekordów, głębokość rekursji, widoczne wiersze i pracę nad kandydatami zgodnie z duchem oficjalnych wskazówek o dużych zbiorach danych i limitach implementacji.

Numery pól muszą mieścić się w zakresie od 1 do 536 870 911. Zakres 19 000–19 999 wywołuje ostrzeżenie, ponieważ oficjalne zalecenia dotyczące numerów pól rezerwują go dla implementacji. Typy wire 6 i 7 są nieprawidłowe.

Analiza i eksport odbywają się lokalnie. Widok wieloetapowy może przechowywać ograniczony payload w sessionStorage tej karty przez maksymalnie dwie godziny; rozpoczęcie od nowa go usuwa. Nic nie trafia do adresu URL ani przez nasze serwery. JSON jest raportem dekodowania we własnym formacie tego narzędzia, a nie ProtoJSON. CSV zaczyna się od BOM UTF-8 i neutralizuje komórki przypominające formuły, aby bezpieczniej otwierać je w arkuszu. Raport może nadal zawierać poufne dane aplikacji, sprawdź go przed udostępnieniem.