Decodificatore Protocol Buffers

Cosa può dimostrare un decodificatore Protobuf senza schema

Protocol Buffers memorizza una sequenza di tag e valori di campo, non le dichiarazioni .proto originali. La guida ufficiale alla codifica protobuf definisce ogni tag come (field_number << 3) | wire_type. Il decodificatore può quindi stabilire numero di campo, wire type, confini dei byte e codifiche strutturalmente possibili. Non può stabilire se un varint sia stato dichiarato uint64, int64, sint64, bool o enum, perché dichiarazioni diverse possono condividere gli stessi byte.

La modalità di input è sempre esplicita. L’esadecimale ammette spazi ASCII e al massimo un 0x iniziale. Base64 e Base64URL vengono convalidati separatamente, compresi lunghezza, padding e bit di riempimento inutilizzati; non è possibile mescolare gli alfabeti standard e URL-safe. Testo grezzo indica gli esatti byte UTF-8 prodotti dal TextEncoder del browser: le sequenze di escape con barra inversa non vengono interpretate. Per i file si usano i byte esatti.

Wire type e interpretazioni

Il normale tipo Number di JavaScript non rappresenta esattamente ogni intero a 64 bit. Il parser usa BigInt ovunque e converte gli interi esatti in stringhe decimali per visualizzazione ed esportazione. Anche NaN, infinito e zero negativo vengono esportati come stringhe, evitando conversioni silenziose da parte di JSON.

Capire l’ambiguità dei valori length-delimited

Il wire type 2 serve per stringhe, byte grezzi, messaggi incorporati e scalari ripetuti packed. Senza schema, una sequenza può essere valida in più ruoli. Ad esempio, 2a 03 01 02 03 è il campo 5 con tre byte: sono varint packed validi [1, 2, 3], ma anche semplici byte. Il decodificatore mostra entrambe le possibilità senza privilegiarne una.

Un candidato a messaggio annidato compare solo se l’intero corpo length-delimited forma un messaggio completo. Anche i candidati varint, fixed32 e fixed64 packed compaiono soltanto se consumano tutti i byte. Un candidato UTF-8 rigoroso deve decodificare tutta la sequenza senza caratteri sostitutivi. Sono possibilità strutturali, non il tipo dichiarato del campo.

I gruppi vengono gestiti secondo la grammatica wire, anche se gli schemi moderni preferiscono messaggi incorporati. Un tag di inizio deve chiudersi con un tag finale dello stesso campo. Una chiusura alla radice, un numero diverso o una chiusura mancante causa un errore fatale all’offset esatto. I campi completi precedenti restano visibili; byte mancanti e valori ignoti non diventano mai uno zero fittizio.

Limiti, framing e gestione sicura

Il decodificatore accetta un solo messaggio privo di framing, fino a 10 MiB. Non separa stream con prefisso di lunghezza, frame gRPC, file di messaggi delimitati o envelope di trasporto. Rimuovi prima il framing e poi decodifica un messaggio. Il parser limita record totali, profondità ricorsiva, righe visibili e lavoro sui candidati, in linea con le indicazioni ufficiali su grandi quantità di dati e limiti di implementazione.

I numeri di campo devono essere compresi tra 1 e 536.870.911. L’intervallo 19.000–19.999 genera un avviso perché la guida ufficiale ai numeri di campo lo riserva alle implementazioni. I wire type 6 e 7 non sono validi.

Analisi ed esportazione avvengono localmente. La vista a più passaggi può conservare un payload limitato nel sessionStorage della scheda per un massimo di due ore; ricominciare lo elimina. Nulla finisce nell’URL o passa tramite i nostri server. Il JSON è esplicitamente un report di decodifica nel formato proprio di questo strumento, non ProtoJSON. Il CSV inizia con un BOM UTF-8 e neutralizza le celle simili a formule per un’apertura più sicura nei fogli di calcolo. I report possono comunque contenere dati riservati: controllali prima di condividerli.