入力

出力

JSON から MessagePack とは？

帯域がカツカツの WebSocket に流す予定の JSON 設定がある — MessagePack なら同じペイロードを JSON で送るより 30〜60% 小さくできて、しかも JSON が扱いやすい理由である「スキーマレスでただのオブジェクト」感を捨てずに済みます。このページは左側に貼った JSON を右側で msgpack のバイトストリームにエンコードし、デフォルトでは base64 として表示、ワンクリックで hex に切り替えられます。

エンコードは公式の @msgpack/msgpack ライブラリを使ってすべてブラウザ内で実行されるので、JSON はタブの外に出ません。内部では JSON RFC が定める JSON.parse で入力をパースし、得られたオブジェクトを msgpackEncode に渡し、返ってきた Uint8Array を転送しやすい文字列 — base64（RFC 4648 準拠）または小文字 hex に変換します。

JSON や HTTP ヘッダー、DB のフィールドにバイトを埋め込むなら base64。msgpack のワイヤ仕様やサーバーログとサンプルをバイト単位で見比べるなら hex。同じバイトの別表現にすぎません。

JSON から MessagePack エンコーダの使い方

3 ステップ。入力に合わせて自動変換 — クリックするボタンはありません。

JSON を貼るかサンプルを読み込む

左のエディタに JSON を入れます。サンプル JSON を押すと、文字列・整数・浮動小数点・ネストされた配列など押さえておきたいケースを網羅した小さな注文ペイロードが入ります。エンコーダは入力を MessagePack 標準の型システムとして扱います: 整数は最小の fixint/int8/int16/int32/int64 形式に、浮動小数点は float64 に、文字列は長さに応じて fixstr/str8/16/32 に、配列は fixarray/array16/32 に、マップは fixmap/map16/32 にエンコードされます。入力例:

{
  "orderId": "ORD-7421",
  "items": [{ "sku": "SKU-101", "qty": 2 }],
  "total": 89.50
}

こうした 90 バイトの JSON は、たいてい msgpack で〜55 バイトに収まります — gzip をかける前で 1/3 ほど小さくなる計算です。

Hex と Base64 を切り替える

出力フォーマットはデフォルトで base64 です — 設定に貼ったり通信に流したりする用途で一番よく使うからです。サーバー側エンコーダと diff を取りたい、あるいは型バイトを目視で確認したい（例: fixmap of 2 なら 0x82）場合は Hex 出力 を押して小文字 hex に切り替えてください。何度切り替えても、裏側のバイトは同じです。

コピーして送る

コピー を押して出力をクリップボードに移します。Redis の SET や WebSocket のテキストフレーム、Content-Type: application/x-msgpack を付けた HTTP ボディ、Postgres の bytea カラム（先に base64 をデコード）にそのまま入れられます。逆方向に変換したいときは MessagePack から JSON ページに貼り付けてください。

実際にこれを使う場面

WebSocket フレームを縮める

毎秒のように更新が飛ぶリアルタイムアプリでは、サイズの差がはっきり効きます。JSON で 220 バイトの位置更新や板情報のティックは msgpack だと〜140 バイト — 毎秒数千フレームとなれば積み重なります。サンプルメッセージをここで変換し、テストハーネスにバイトを貼って受信側が同じように復号できるか確認しましょう。

キャッシュの値を圧縮する

Redis のようなキャッシュは保存バイトと読み取りバイトの両方で課金します。キャッシュ対象を JSON 文字列ではなく msgpack でエンコードすれば、毎ヒットでストレージとネットワークが節約できます。シリアライザに採用する前に、特定オブジェクトがバイト列でどう見えるかをこのページで下見しましょう。

型情報付きの数値を送る

JSON には数値型がひとつしかなく、42 も 42.0 も同じ扱いです。MessagePack はワイヤ上で整数と浮動小数点を区別する — 受信側が Go や Rust、C# のような強く型付けされた言語で、文字列を経由したくないときに便利です。JSON の数値を貼って hex 出力で型バイトを確認すれば、float ではなく int としてエンコードされたことが裏取りできます。

デコーダのデバッグ

"msgpack のはず" のサービスを叩いたら、コンシューマーがバイトに詰まる？同じ JSON をここでエンコードし、サービスの出力と hex モードでバイト単位で見比べれば、どのフィールド・どの型がズレているかが一発でわかります。リファレンスエンコーダは公開仕様に厳密に従っています。

よくある質問

JSON はブラウザから出ていきますか？

いいえ。JSON はブラウザ組み込みの JSON.parse でパースされ、クライアントサイド JavaScript の @msgpack/msgpack ライブラリでエンコードされ、右ペインに base64 または hex として表示されます — サーバー呼び出しもなければ、入力に対するテレメトリもなく、何もログに残しません。DevTools を開けばタイプしている間ネットワークタブが静かなままなのを確認できます。社外秘の設定や顧客データでも安心です。

出力が思ったより大きいのはなぜ？

理由はだいたい 2 つです。第一に、base64 は約 33% バイトを膨らませます — base64 の msgpack を JSON テキストと直接比べているなら、ワイヤ上の本当のサイズを比べていません。hex（こちらは 2 倍に膨らみます）に切り替えるか、もっと言えばバイト長を見るのが正解です。DevTools で atob(output).length を実行すれば本当のサイズが出ます。第二に、msgpack が JSON に勝つのは数値・真偽値・繰り返しの短い文字列が多いデータだけです。長くてユニークな文字列ばかりが 90% を占めるブロブは、どちらの形式でもほぼ同じサイズになります。

整数・浮動小数点・大きな数はどう扱われますか？

JavaScript の JSON.parse はあらゆる数値を 64 ビット浮動小数点に変換するため、エンコーダにデータが届く頃には int と float の区別が失われています。ライブラリはこのあたりをうまく処理します: 値が整数で safe-int の範囲内なら int としてエンコード（fixint, int8, int16, int32, int64 の最小サイズを選択）、それ以外は float64 でエンコードします。Snowflake ID のように厳密な 64 ビット整数が必要な場合は、JSON 上では文字列として渡し、受信側で変換してください。

バイナリブロブ（ファイルバイトなど）をこれでエンコードできますか？

JSON 経由では直接できません — JSON には bin 型がないので、Uint8Array はこの UI を base64 文字列として往復し、msgpack の str として再エンコードされ、bin にはなりません。本物の msgpack bin や ext 型（msgpack だけにある 2 大機能）が必要なら、コードでオブジェクトを組み立てて Uint8Array を入れた状態で直接 encode を呼ぶ必要があります。JSON ペインはデータがすでに JSON の形をしている 9 割のケース向けです。

hex と base64 の出力の違いは？

同じバイト列をテキストで書き表す 2 通りの方法です。Hex は 1 バイトあたり 2 文字（0x82 なら文字列 "82"）— 仕様の型バイトを目視で読むのに便利。Base64 は RFC 4648 に従い 3 バイトを 4 文字で表現 — より高密度で、JSON や JWT、HTTP ヘッダーにバイナリを埋め込む標準的な方法です。出力を貼り付ける先に合うほうを選んでください。

msgpack は JSON より本当に速いですか、それとも単に小さいだけ？

小さいことがたいてい一番効きます。エンコード/デコードの速度では、最近の JSON.parse は十分に最適化されていて、JS では msgpack が並ぶか 10〜20% 勝つ程度です。シリアライズの利点は下流で出ます: ペイロードが小さければネットワーク時間が短くなり、JSON のパースが msgpack のパースより重い言語（Python、君のことだよ）を使う受信側の負荷も減ります。指針: ボトルネックが帯域やストレージなら msgpack、可読性やツール周りなら JSON のままで OK。

その他の MessagePack ツール

エンコードは片方向だけ。残りの往復はこれらでカバーします: