入力

出力

MessagePack バリデーターとは?

MessagePack を吐き出すサービスと連携していて、ワイヤフォーマットに何度も泣かされる — バイト数が合わない、末尾に変なバイトが残る、パーサーがどのフィールドで死んだか手がかりも残さず落ちる。このツールは MsgPack ペイロードの hex または base64 ダンプを取り、本物のデコーダーに通して、実際に何が出てきたかを教えてくれます。

入力は @msgpack/msgpack のデコーダーに通します。パースできれば、バイト数、トップレベルの型 (map、array、string、int…)、キーや配列の長さを表示するので、頭の中のスキーマと突き合わせて確認できます。失敗したら、パーサーのエラーメッセージをそのまま見せます — 大抵は壊れたオフセットを正確に指してくれます。

hex と base64 は自動判定されます。空白、カンマ、0x プレフィックス、\xNN のエスケープも許容されるので、Wireshark のキャプチャ、サーバーログ、Python の repr() ダンプから直接貼り付けられます。データはブラウザの外には出ません — デコーダーはローカルで動きます。

MessagePack バリデーターの使い方

貼り付けるだけ。バリデーターはキー入力ごとに動作するので (300ms のデバウンス付き)、ボタンを押す必要はありません。

hex または base64 の MsgPack を貼る

エンコード済みのペイロードを左側のペインに落とします。サンプル MsgPack を押すと、hex でエンコードされた小さな注文オブジェクトが読み込まれます — 有効な結果がどう見えるか確認したいときに便利です。デコーダーは MessagePack の仕様に従うので、準拠したエンコーダーが生成したものはきれいにラウンドトリップします。例 (int 1 ひとつだけの hex):

これは正の fixint 1 のワイヤバイトです。もっと大きなペイロード (map、array、string) は 0x80〜0x9f (fixmap/fixarray) や 0xa0〜0xbf (fixstr) のようなフォーマットバイトで始まります。

検証レポートを読む

右ペインは自動で埋まります。成功すると、検出された入力フォーマット (hex または RFC 4648 ベースの base64)、エンコード済みバイト数、トップレベルの型、キー/配列の数、さらにデコード済み値の JSON プレビュー (パネルが見やすいように 2KB で切り詰め) が表示されます。

失敗を調査する

パース失敗時、右ペインには ✗ Invalid MessagePack に続いてデコーダーのエラー文字列が表示されます。よくあるもの: "Insufficient bytes" (hex が途中で切れている)、"Unrecognized type byte" (誤って JSON やテキストを貼った、または入力が壊れている)、"Extra bytes were found" (長さプレフィックスやフレーミングバイトが混ざっている)。背後のバイト列は Uint8Array として頭の中で扱ってください — 失敗のほとんどはエンコードのバグではなく、フレーミングか長さの問題です。

実際にこれを使う場面

キャッシュミスのデバッグ

Redis のキーに MessagePack でエンコードされた注文 (orderId: 'ORD-7421'、items、顧客) が入っていて、コンシューマーがデシリアライズで例外を投げているとします。redis-cli --no-raw GET の hex を貼って、ワイヤフォーマットがそもそも有効かを確認し、トップレベルの型がデコーダーの期待と合っているかを見ます。

ワイヤキャプチャの検証

Wireshark や tcpdump でフレームをキャプチャしてバイトをエクスポートし、フレーミングを手で追う前に中の MsgPack が整っているか知りたい。貼り付けて、型とバイト数を一目見て、次に進みます。

プロデューサーの動作確認

Go や Rust で独自のエンコーダーを書きましたか? 既知のフィクスチャ ({sku: 'SKU-101', qty: 2}) をエンコードして hex でダンプし、ここに貼ります。書いたのと同じ map として読み返せれば、エンコーダーは MessagePack 形式に準拠しています。

バグ報告前のプリフライト

上流ライブラリに issue を立てる前に、ペイロードが本当に有効な MsgPack かをまず確認しましょう — "ライブラリのバグ" 報告の半分は不正な入力です。ここで 30 秒貼り付けるだけで、やり取りを 1 往復節約できます。

よくある質問

ペイロードはブラウザの外に出ますか?

いいえ。デコードはこのページ上で @msgpack/msgpack デコーダーを使って JavaScript で実行されます。何もアップロードもログもバックエンド送信もされません — タブを閉じればデータは消えます。デスクトップの hex ビューアと同じモデルが、ブラウザ内で動いているだけです。

バイナリファイルのアップロードに対応していますか? それとも hex/base64 だけ?

hex と base64 のみです。ブラウザはファイルピッカーなしにファイルのバイトをページに渡せませんし、ほとんどのコピペワークフローはすでに hex (xxd、hexdump -C、デバッガのツールチップなど) か base64 (REST API レスポンス、ログ行など) を生成しています。生の .msgpack ファイルがあるなら、まず xxd -p file.msgpack か base64 file.msgpack を実行してください。

hex と base64 はどう見分けるのですか?

hex を先に判定します: 入力 (空白、カンマ、0x プレフィックス、\xNN エスケープを取り除いたあと) がすべて hex 文字で偶数長なら hex として扱います。それ以外は atob に渡して base64 として扱います。レポートの "Detected input format" 行でどちらの経路を取ったかが分かります — deadbeef のように両方のエンコーディングで有効なあいまいな文字列のときに役立ちます。

なぜ時々 "Extra bytes were found" と出るのですか?

MessagePack ストリームはちょうど 1 つのトップレベル値であるべきです。長さプレフィックス付きフレーム (フレーミング転送プロトコルが付ける 4 バイトのビッグエンディアン長など) や 2 つの連結ペイロードを貼ると、デコーダーは最初の値を読んで残りについて文句を言います。フレーミングを取り除くか、個々のメッセージに分割してください。

MessagePack の拡張型 (timestamp、カスタム型) もデコードできますか?

デフォルトの @msgpack/msgpack デコーダーは組み込みの timestamp 拡張型 (-1) を最初から扱い、プレビューでは JS の Date として表示します。カスタム拡張型 (0 から 127) は汎用の {type, data} 形にデコードされます — バリデーターは引き続きペイロードを有効と報告しますが、内容を解釈するには独自の ExtensionCodec が必要です。

これと MessagePack Viewer の違いは?

Viewer は閲覧用 — 各キーと値をツリー状に分解して表示します。このバリデーターは "そもそも有効か?" の問いに答えるもの — 素早い yes/no と、バイト数とトップレベルの型を返します。バリデーターでパースが通り、型が正しいと分かったら、Viewer に切り替えて実際の中身を読んでください。

その他の MessagePack ツール

ペイロードが有効と確認できたら、これらのツールで残りの作業を進められます: