Decodificador de Protocol Buffers

Qué puede demostrar un decodificador Protobuf sin esquema

Protocol Buffers almacena una secuencia de tags de campo y valores, no las declaraciones .proto originales. La guía oficial de codificación de protobuf define cada tag como (field_number << 3) | wire_type. Por eso, este decodificador sí puede determinar el número de campo, el tipo wire, los límites de bytes y las codificaciones estructuralmente posibles. No puede asegurar si un varint se declaró como uint64, int64, sint64, bool o enum, porque esas declaraciones pueden compartir los mismos bytes.

El modo de entrada siempre es explícito. El formato hexadecimal admite espacios ASCII y, como máximo, un 0x inicial. Base64 y Base64URL se validan por separado, incluida la longitud, el padding y los bits de relleno no utilizados; no se pueden mezclar los alfabetos estándar y seguro para URL. Texto sin procesar significa exactamente los bytes UTF-8 generados por TextEncoder en el navegador: las secuencias de escape con barra invertida no se interpretan. La entrada de archivo usa sus bytes exactos.

Tipos wire e interpretaciones

El tipo numérico habitual de JavaScript no representa todos los enteros de 64 bits con exactitud. Este decodificador usa BigInt en todo el parser y convierte los enteros exactos a cadenas decimales para mostrarlos y exportarlos. Los valores especiales de coma flotante, como NaN, los infinitos y el cero negativo, también se exportan como cadenas para que JSON no los convierta silenciosamente en otro valor.

Cómo entender la ambigüedad delimitada por longitud

El tipo wire 2 se usa para cadenas, bytes sin procesar, mensajes embebidos y valores escalares repetidos empaquetados. Sin esquema, una secuencia de bytes puede ser válida en varios papeles al mismo tiempo. Por ejemplo, 2a 03 01 02 03 es el campo 5 con tres bytes. Estos son varints empaquetados válidos [1, 2, 3], pero también pueden ser bytes corrientes. El decodificador muestra ambas opciones sin calificar ninguna como más probable.

Solo se muestra un candidato a mensaje anidado cuando todo el cuerpo delimitado por longitud se analiza como un mensaje completo. Los candidatos a varint, fixed32 y fixed64 empaquetados también aparecen únicamente si la interpretación consume todos los bytes. Un candidato UTF-8 estricto exige decodificar la secuencia completa sin caracteres de sustitución. Estas comprobaciones describen posibilidades estructurales, no el tipo declarado del campo.

Los grupos se procesan conforme a la gramática wire, aunque los esquemas modernos suelen preferir mensajes embebidos. Un tag de inicio de grupo debe cerrarse con otro de fin que tenga el mismo número de campo. Un fin en la raíz, un número distinto o la ausencia de cierre causa un error fatal con el offset exacto. Los campos completos anteriores siguen visibles; los bytes que faltan y los valores desconocidos nunca se convierten en un cero ficticio.

Límites, framing y manejo seguro

El decodificador acepta un único mensaje sin framing de hasta 10 MiB. No separa streams con prefijo de longitud, frames gRPC, archivos de mensajes delimitados ni envoltorios de transporte. Retira primero ese framing y decodifica un solo mensaje. El parser limita los registros totales, la profundidad recursiva, las filas visibles y el trabajo dedicado a candidatos. Estas medidas siguen el criterio de la documentación oficial sobre conjuntos de datos grandes y límites de implementación: protobuf es eficiente, pero una pestaña de diagnóstico también necesita límites de memoria y trabajo.

Los números de campo deben estar entre 1 y 536.870.911. El intervalo 19.000–19.999 genera un aviso porque la guía oficial de números de campo reserva ese rango de implementación. Los tipos wire 6 y 7 no son válidos.

El análisis y la exportación ocurren localmente. La vista por pasos puede conservar un payload limitado en el sessionStorage de esta pestaña durante un máximo de dos horas; empezar de nuevo lo elimina. Nada se coloca en la URL ni se envía a nuestros servidores. La salida JSON es expresamente un informe de decodificación con el formato propio de esta herramienta, no ProtoJSON. El CSV comienza con una marca BOM UTF-8 y antepone un carácter a las celdas que parecen fórmulas para abrirlas con más seguridad en una hoja de cálculo. Aun así, los informes pueden contener datos confidenciales de la aplicación: revísalos antes de compartirlos.