Декодер Protocol Buffers

Что может доказать декодер Protobuf без схемы

Protocol Buffers хранит последовательность тегов и значений полей, а не исходные объявления .proto. Официальное руководство по кодированию protobuf определяет тег как номер поля, сдвинутый на три бита и объединённый с wire-типом, что эквивалентно field_number × 8 + wire_type. Поэтому декодер может достоверно определить номер поля, wire-тип, границы байтов и структурно допустимые кодировки. Но он не может доказать, что varint был объявлен как uint64, int64, sint64, bool или enum: эти объявления могут иметь одинаковое представление в байтах.

Режим ввода всегда выбирается явно. Hex допускает пробельные символы ASCII и не более одного префикса 0x в начале. Base64 и Base64URL проверяются отдельно, включая длину, заполнение и неиспользованные биты заполнения; смешивать стандартный и URL-безопасный алфавиты нельзя. Исходный текст означает точные байты UTF-8, созданные браузерным TextEncoder: последовательности с обратной косой чертой не интерпретируются. При загрузке файла используются его точные байты.

Wire-типы и варианты трактовки

Обычный тип number в JavaScript не может точно представить все 64-битные целые числа. Декодер использует BigInt во всём wire-парсере и преобразует точные целые числа в десятичные строки для отображения и экспорта. Особые значения с плавающей точкой, включая NaN, бесконечности и отрицательный ноль, также экспортируются строками, чтобы JSON незаметно не заменил их другим значением.

Неоднозначность полей с длиной

Wire-тип 2 используется для строк, необработанных байтов, вложенных сообщений и упакованных повторяющихся скалярных значений. Без схемы одна последовательность байтов может одновременно допускать несколько трактовок. Например, 2a 03 01 02 03, это поле 5 с тремя байтами. Эти байты допустимы как упакованные varint [1, 2, 3], но одновременно остаются обычными байтами. Декодер показывает оба варианта и не считает один из них более вероятным.

Вариант вложенного сообщения появляется, только если всё содержимое поля с длиной полностью разбирается как корректное сообщение. Варианты упакованных varint, fixed32 и fixed64 также появляются лишь при полном потреблении всех байтов. Для строгого варианта UTF-8 вся последовательность должна декодироваться без символов замены. Эти проверки показывают структурные возможности, а не объявленный тип поля.

Группы обрабатываются по правилам wire-грамматики, хотя современные схемы обычно предпочитают вложенные сообщения. Тег начала группы должен закрываться тегом конца группы с тем же номером поля. Конечный тег в корне, несовпадающий тег или отсутствие закрытия останавливают декодирование на точном смещении. Полностью разобранные до ошибки поля остаются видимыми; недостающие байты и неизвестные значения никогда не превращаются в ложный ноль.

Ограничения, фрейминг и безопасная обработка

Декодер принимает одно сообщение без фрейминга размером до 10 MiB. Он не разделяет поток с префиксом длины, gRPC-фрейм, файл delimited-message или транспортную оболочку. Сначала удалите фрейминг, затем декодируйте одно сообщение. Парсер также ограничивает общее число записей, глубину рекурсии, количество видимых строк и объём анализа вариантов. Эти меры следуют принципам официальных рекомендаций о больших наборах данных и ограничениях реализаций: protobuf эффективен, но диагностической вкладке браузера всё равно нужны ограничения памяти и вычислений.

Номер поля должен находиться в диапазоне от 1 до 536 870 911. Декодер предупреждает о номерах 19 000–19 999, потому что официальное руководство по номерам полей резервирует этот диапазон для реализации. Wire-типы 6 и 7 недопустимы.

Разбор и экспорт выполняются локально. Многошаговый режим может хранить ограниченную полезную нагрузку в sessionStorage этой вкладки до двух часов; при запуске заново она удаляется. В URL ничего не помещается и на наши серверы не отправляется. JSON-вывод представляет собой отчёт о декодировании в собственном формате этого инструмента, а не ProtoJSON. CSV начинается с UTF-8 BOM, а похожие на формулы ячейки получают префикс для более безопасного открытия в таблицах. Отчёты всё же могут содержать конфиденциальные данные приложения, поэтому проверяйте их перед передачей.