本文へスキップ
AZ Tools

Protobuf デコーダ(.proto 不要)

protobuf のペイロードはそれ単体では何も明かしません。ワイヤ上にフィールド名はなく、番号とワイヤ型だけが載るため、gRPC 呼び出しや API キャプチャから得た不透明な本文は、それを生成した .proto がなければ読めません。そして他人のサービスをデバッグしているときは、たいていその .proto がありません。 このデコーダはワイヤ形式を直接読みます。各フィールドは番号・ワイヤ型・値とともに返り、ネストしたメッセージはその場で展開され、符号化があいまいな場合は勝手に決めずあいまいだと伝えます。このあいまいさは実在します。varint は符号なし整数かもしれず、ジグザグ符号化された符号付き整数かもしれず、真偽値かもしれません。長さ指定フィールドは文字列、ネストしたメッセージ、packed な繰り返し数値、あるいは生のバイト列でありえます。最も可能性の高い読み方を示し、ほかの候補を隣に並べます。 ネストしたメッセージの判定は意味の推測ではありません。すべてのキーが妥当なフィールド番号で、すべての長さがちょうど末尾で終わるときにだけ、メッセージとして提示します。処理はすべてブラウザ内で行われ、ペイロードはアップロードされません。

base64 か hex の protobuf ペイロードを貼り付けると復号します。

使い方

  1. ペイロードを base64 か hex で貼り付けます。形式は自動判定され、指定もできます。
  2. ツリーを読みます。各行はフィールド番号、ワイヤ型、値です。
  3. 灰色の文字で示される別の読み方も確認します。
  4. ネストしたメッセージは親フィールドの下にインデントされます。
  5. キャプチャした本文のファイルをドロップすればそのまま復号できます。

よくある質問

なぜフィールド名が出ないのですか
送信されないからです。protobuf はワイヤにフィールド番号とワイヤ型だけを載せ、名前は両端の .proto ファイルにあります。それが符号化を小さくしている理由であり、スキーマなしのデコーダがメッセージの構造は示せても名前を示せない理由でもあります。
ネストしたメッセージかどうかはどう判断しますか
そのバイト列をメッセージとして解析し、完全に整合する場合だけ採用します。すべてのキーが妥当なフィールド番号とワイヤ型で、すべての長さがバッファの末尾でちょうど終わることが条件です。短い文字列が偶然この検査を通ることがあるため、バイト列が有効なテキストでもある場合はあいまいだと表示します。
数値の別の読み方とは何ですか
ワイヤ上の varint は int32/int64/uint、ジグザグの sint、または bool でありえます。fixed64 は double、fixed64、sfixed64 でありえます。ペイロードにはこれらを区別する情報がないため、最も一般的な読み方を先に示し、ほかを隣に並べます。
gRPC の本文も復号できますか
gRPC のフレームは各メッセージの前に圧縮フラグ 1 バイトと長さ 4 バイトを付けます。その 5 バイトを取り除けば残りはここで復号できます。圧縮されたフレームは先に展開が必要です。
group はどうなりますか
group は proto2 の廃止されたワイヤ型 3 と 4 で、今ではほとんど見かけません。見つけた場合は入れ子を推測せず、印だけを報告します。
ペイロードはアップロードされますか
いいえ。バイト列はブラウザ内で復号され、サーバーに送信されるものはありません。

関連ツール