Protocol Buffers デコーダー

ステップ 1 / 333%

エンコード済みの Protocol Buffers メッセージをアップロードせず、スキーマを推測したふりもせずに解析できます。このブラウザ内デコーダーでは、16進数、Base64、Base64URL、生の UTF-8、バイナリファイルの入力形式を明示的に選択します。有効な protobuf の全ワイヤタイプを読み取り、64ビット整数の精度を保ち、不正な箇所のオフセットを示し、曖昧な長さ区切りバイトについて完全に成立する解釈をすべて表示します。ペイロードはブラウザ内に留まり、データ中に記載されたサービスへアクセスすることもありません。

使い方

  1. 1

    エンコード形式を正確に選ぶ

    hex、Base64、Base64URL、生の UTF-8、バイナリファイルから選びます。入力形式が自動で推測されることはありません。

  2. 2

    ワイヤフィールドを調べる

    タグ、フィールド番号、ワイヤ値をデコードし、スキーマ型を決めつけずに有効なネスト候補や packed 候補を展開します。

  3. 3

    レポートを書き出す

    スキーマなしの JSON、数式インジェクション対策済み CSV、または読みやすいテキストレポートをダウンロードできます。

スキーマなしの Protobuf デコーダーで確定できること

Protocol Buffers に保存されるのはフィールドのタグと値の並びであり、元の .proto 宣言ではありません。protobuf の公式エンコーディングガイドでは、フィールド番号を3ビット左へシフトし、ワイヤタイプと組み合わせてタグを作ると定義されています。これは field_number × 8 + wire_type と同じです。そのため、このデコーダーで確定できるのは、フィールド番号、ワイヤタイプ、バイト境界、そして構造上成立するエンコーディングです。varint が uint64、int64、sint64、bool、enum のどれとして宣言されたかは、同じバイト列を共有し得るため確定できません。

入力モードは必ず明示的に選択します。Hex では ASCII の空白と、先頭に1つだけ付けた 0x を受け付けます。Base64 と Base64URL は、長さ、パディング、未使用のパディングビットまで別々に検証し、標準の文字集合と URL セーフな文字集合は混在できません。生テキストとは、ブラウザの TextEncoder が生成する正確な UTF-8 バイト列を指し、バックスラッシュによるエスケープは解釈しません。ファイル入力ではファイルのバイトをそのまま使います。

ワイヤタイプと解釈

ワイヤタイプ エンコードされた値 レポートに表示する内容
0 Varint 正確な符号なし整数、2の補数による符号付き整数、ZigZag 値。Boolean は 0 または 1 の場合のみ
1 リトルエンディアンの8バイト 正確な fixed64、sfixed64 と double 候補
2 長さと、それに続くバイト Hex、Base64、有効な場合の厳密な UTF-8、完全に成立するすべての nested/packed 候補
3 / 4 グループ開始/終了タグ 同じフィールド番号で対応するグループの子要素。終了タグは独立レコードではなく区切り
5 リトルエンディアンの4バイト 正確な fixed32、sfixed32 と float 候補

JavaScript の通常の number 型では、すべての64ビット整数を正確に表せません。このデコーダーはワイヤ解析全体に BigInt を使い、正確な整数を10進文字列へ変換して表示・出力します。NaN、無限大、負のゼロなどの特殊な浮動小数点値も文字列として出力するため、JSON によって別の値へ暗黙変換されません。

長さ区切り値の曖昧さ

ワイヤタイプ2は、文字列、生バイト、埋め込みメッセージ、packed された反復スカラー値に使われます。スキーマがなければ、同じバイト列が複数の役割で同時に有効な場合があります。たとえば 2a 03 01 02 03 は、3バイトを持つフィールド5です。この3バイトは packed varint [1, 2, 3] として有効ですが、単なるバイト列でもあります。デコーダーは両方を表示し、どちらが有力かを順位付けしません。

nested message 候補は、長さ区切りの本体全体が完全なメッセージとして解析できた場合にのみ表示します。packed varint、fixed32、fixed64 の候補も、その解釈ですべてのバイトを消費できた場合に限ります。厳密な UTF-8 候補は、置換文字を使わずに全体をデコードできる必要があります。これらは構造上の可能性を示すものであり、宣言されたフィールド型を特定するものではありません。

現代のスキーマでは通常、埋め込みメッセージが推奨されますが、グループもワイヤ文法に従って処理します。start-group タグは同じフィールド番号を持つ end-group タグで閉じる必要があります。ルート直下の終了タグ、番号が一致しない終了タグ、終了タグの欠落があると、その正確なバイトオフセットでデコードを停止します。エラー前に完全にデコードできたフィールドは表示したままにし、不足バイトや不明値を偽のゼロへ置き換えることはありません。

上限、フレーミング、安全な処理

このデコーダーが受け付けるのは、最大10 MiBのフレームなしメッセージ1件です。長さプレフィックス付きストリーム、gRPC フレーム、delimited-message ファイル、その他の転送用エンベロープは分割しません。先にフレーミングを取り除き、1件のメッセージを入力してください。レコード総数、再帰の深さ、表示行数、候補検証の処理量にも上限があります。これらの制限は、公式の大規模データに関するガイドと実装上の上限の考え方に沿っています。protobuf は効率的でも、ブラウザの解析タブではメモリと処理量を制限する必要があります。

フィールド番号は1から536,870,911までです。19,000~19,999は、公式のフィールド番号ガイドで実装用に予約されているため警告します。ワイヤタイプ6と7は無効です。

解析とエクスポートはローカルで行われます。複数ステップ表示では、サイズを制限したペイロードをこのタブの sessionStorage に最長2時間保持することがあります。最初からやり直すと削除されます。URL に入れたり、当社のサーバーへ送信したりすることはありません。JSON 出力はこのツール独自の形式のデコードレポートであり、ProtoJSON ではありません。CSV には UTF-8 BOM を付け、数式に見えるセルには接頭辞を加えて、表計算ソフトで開く際の安全性を高めます。レポート自体には機密情報が含まれ得るため、共有前に確認してください。

よくある質問

いいえ。ワイヤ形式にはフィールド番号とエンコーディングが残りますが、異なるスカラー型が同じバイト列を使うことがあります。名前、コメント、スキーマ設計の意図の大部分は含まれません。

いいえ。入力検証、解析、絞り込み、書き出しはブラウザ内で実行されます。ペイロードを当社のサーバーへ送信したり、URL に含めたりしません。

長さ区切りの値は、バイト、UTF-8テキスト、埋め込みメッセージ、packed 値のいずれとしても有効になり得ます。スキーマがない場合、推測するより完全に成立する候補をすべて示す方が正確です。

その位置のタグ、varint、固定幅値、宣言された長さ、またはグループ境界が不完全か無効です。それ以前の完全なフィールドは部分レポートに残ります。

直接はできません。このデコーダーは protobuf メッセージを1件読み取り、gRPC、varint 長、その他の転送用フレーミングを除去しません。先に1件分のペイロードを取り出してください。

関連ツール

このツールは他の言語でも利用できます