MessagePack の hex または base64 文字列をここに貼ってください。入力中にデコードします。msgpack hex/base64 を貼り付け

MessagePack ビューアの役割

Cloudflare Worker のログに出てきた hex の塊を眺めて「これ中身何？」と思ったことがあるなら、まさにそのためのページです。MessagePack はバイナリのシリアライズ形式で、出力は 83a76f72646572496478a84f52442d37343231... みたいな見た目になります。回線上はコンパクトですが、目で読むのは無理です。左ペインに hex（または base64 — 自動判定します）を貼ると、右ペインがデコード後の JSON ツリーを表示します。

デコードはローカルで、公式の @msgpack/msgpack ライブラリを使います。Node やブラウザのアプリの大半が同じものを使っています。フォーマットは公開されている MessagePack ワイヤーフォーマット仕様に準拠しているので、msgpack-python、msgpack-c、msgpack-java など仕様を満たす実装で生成したペイロードはそのまま読めます。アップロードはありません。バイトはブラウザの外に出ないので、blob に customer: 'Ava Chen' や社内の subscriberId: 'SUB-1001' が入っていても安心です。

デコードは 300ms の debounce 付きなので、貼って、編集して、貼り直して、をボタンなしで繰り返せます。Convert ボタンもスピナーもなし。打つと出ます。

MessagePack ペイロードの読み方

3 ステップです。ログからコピーした hex 文字列、Kafka メッセージから抜いた base64 フィールド、デバッガから貼った生バイトのいずれにも使えます。

左ペインに hex か base64 を貼る

エンコード済みの MessagePack を左のエディタに落としてください。自動判定します。空白・カンマ・0x プレフィックス・\x エスケープを取り除いた上で hex として正しく読めれば hex として扱い、それ以外は base64（RFC 4648）を試します。どちらでも構いません。hex でエンコードした注文の例：

83a76f72646572496478a84f52442d37343231a56974656d739282a3736b75a7534b552d313031a37174790282a3736b75a7534b552d323434a37174790182a8637573746f6d6572a841766120436865 6e

この blob は、SKU-101 x2 と SKU-244 x1 の 2 行を含む、顧客 Ava Chen の注文にデコードされます。

右側でデコード済み JSON を読む

右ペインは読み取り専用で、デコード済みペイロードを整形した JSON で表示します。インデントは JSON.stringify(obj, null, 2) と同じです。map はオブジェクト、array は配列、整数や浮動小数は数値、バイナリは Uint8Array としてバイト長付きで表示されます。タイムスタンプ拡張型は ISO 文字列として表示されます。

クリックなしで反復する

入力を編集すると 300ms の間を置いて JSON が更新されます。バイトが正しい MessagePack でない場合は、デコード成功のフリをせずに何が壊れたか（バッファ切り詰め、想定外の型バイトなど）を表示します。サンプル msgpack ボタンで動作確認用の Order ペイロードを読み込めます。

実際に使う場面

ログ内の MessagePack メッセージを覗く

サービスが構造化ログに msgpack エンコードしたペイロードを hex で書き込んでいる（base64 より短いことが多いので）。本番で何か壊れたとき、ログ行から hex をコピーしてここに貼れば、プロデューサーが実際に何を送ったかが即わかります。orderId ORD-7421、正しいアイテム、誤った customer フィールド、何でも。

Redis や Kafka のペイロードをデバッグする

ホットパスでは JSON ではなく MessagePack を使うバックエンドが多いです。30〜50% 小さく、パースも速いからです。Redis から値を取り出したり、kcat -e で Kafka トピックを覗くと、バイト列は base64 で出てきます。それをここに貼って、プロデューサーとコンシューマーがスキーマで合意できているか確認できます。

言語間ラウンドトリップを検証する

Python で msgpack.packb(...) エンコードし、Go で msgpack.Unmarshal(...) デコードする。Go 側で型が違うと出たら、Python 側のバイトを hex で吐かせてこのビューアに通してください。それでバグがエンコーダー側かデコーダー側かが判断できます。午後ずっと議論する前に。

保存した MessagePack ファイルを読む

Jupyter notebook のエクスポート、ゲームのセーブ、解析ダンプなどで <code>.msgpack</code> ファイルがある。<code>xxd -p</code> をかけて hex を取り、貼って、読む。1 件のレコードを見るためだけに新しい Python REPL でライブラリを組むより速いです。

よくある質問

データはブラウザの外に出ますか？

いいえ。デコードはこのタブ内で完結し、ページに同梱した @msgpack/msgpack ライブラリで行います。fetch も、アップロードも、バイト内容のテレメトリもありません。タブを閉じればデータは消えます。とはいえ URL バーは公共スペース扱いで、ペイロードを貼らないでください。クリップボードに秘密が残っていたらクリアしてください。

hex の代わりに base64 を貼ってもいい？

はい。ビューアが自動判定します。空白・カンマ・0x プレフィックス・Python 風の \x エスケープを取り除いた上で hex として読めれば hex 扱い、そうでなければ標準 base64 を試します。同じペイロードならどちらでも通ります。短いメッセージは hex、大きめのものは base64 でログに残すケースが多いです。

バイナリ、タイムスタンプ、拡張型はどう扱われますか？

バイナリ（bin ファミリ）は Uint8Array にデコードされ、JSON ツリーでは { "0": 134, "1": 12, ... } の形で表示されます（標準 JSON にネイティブのバイト型がないため。Uint8Array のドキュメントは MDN を参照）。タイムスタンプ拡張型はネイティブの Date オブジェクトにデコードされ、ISO 8601 文字列としてシリアライズされます。それ以外の拡張型は { type, data } のタプルで届きます。型コードと生バイトが見えます。

デコード結果がサーバーが送った内容と違うのはなぜ？

よくある原因は 2 つです。1 つ目：入力が切り詰められている。ログの切り詰めで末尾数バイトが落ちることがあり、msgpack は長さプレフィックス付きフィールドに依存するため、末尾欠損は紛らわしいエラーや部分的な出力になります。2 つ目：プロデューサーがカスタム拡張型を使っていて、受け手がそれを知らない。構造があり得ない見た目なら、公式仕様とバイトを照らし合わせてください。

巨大なペイロードもデコードできますか？

数 MB の hex なら最近のブラウザで普通に貼れます。それを超えると入力側の Ace エディタがもたつき始めます。そこまで来たら、Node スクリプトでファイルをライブラリで直接読むほうが速いです。ボトルネックはデコーダーではなくエディタです。

サンプルみたいな hex はどう作ればいい？

Python なら import msgpack; msgpack.packb(obj).hex()。JS なら Array.from(encode(obj)).map(b => b.toString(16).padStart(2, '0')).join('')。Go なら fmt.Sprintf("%x", msgpack.Marshal(obj))。たいていの言語に一行で書ける書き方があります。出てきた hex はそのままここに貼れます。

その他の MessagePack ツール

見るだけが用途じゃありません。往復変換と近い形式はこちら：