Entrée

Sortie

Qu'est-ce que JSON vers MessagePack ?

Tu as un fichier de config JSON qui doit passer par un WebSocket au budget serré — MessagePack va le réduire de 30 à 60 % par rapport au même payload en JSON, sans pour autant abandonner le côté schemaless et "juste un objet" qui rend JSON agréable à manipuler. Cette page encode le JSON que tu colles à gauche en flux d'octets msgpack à droite, servi en base64 par défaut et basculable en hex en un clic.

L'encodage tourne entièrement dans ton navigateur via la librairie officielle @msgpack/msgpack, donc le JSON ne quitte jamais l'onglet. En interne, on parse l'entrée avec JSON.parse (le parser décrit par la RFC JSON), on passe l'objet à msgpackEncode, et on transforme le Uint8Array renvoyé en chaîne transportable — base64 (selon la RFC 4648) ou hex en minuscules.

Utilise base64 quand tu intègres les octets dans du JSON, un en-tête HTTP ou une colonne de base de données. Utilise l'hex quand tu compares un échantillon octet par octet à la spec du format msgpack ou à un log serveur. Mêmes octets, rendu différent.

Comment utiliser l'encodeur JSON vers MessagePack

Trois étapes. La conversion se fait automatiquement à la frappe — pas de bouton à cliquer.

Colle ton JSON ou charge l'exemple

Dépose ton JSON dans l'éditeur de gauche. Clique sur JSON d'exemple pour un petit payload de commande qui exerce les cas qui comptent — chaînes, entiers, flottants et un tableau imbriqué. L'encodeur traite l'entrée selon le système de types standard de MessagePack : les entiers prennent la plus petite forme fixint/int8/int16/int32/int64 possible, les flottants deviennent des float64, les chaînes sont encodées en fixstr/str8/16/32 selon leur longueur, les tableaux utilisent fixarray/array16/32, et les maps utilisent fixmap/map16/32. Exemple d'entrée :

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

Un JSON de 90 octets comme celui-ci s'encode typiquement en ~55 octets de msgpack — un tiers de moins, avant la moindre couche gzip par-dessus.

Bascule entre hex et base64

Le format de sortie est en base64 par défaut, parce que c'est ce que tu colles habituellement dans une config ou que tu envoies sur le réseau. Clique sur Sortie hex pour passer en hex minuscules si tu fais un diff contre un encodeur côté serveur ou si tu veux lire à l'œil les octets de type (par ex. 0x82 pour un fixmap de 2). Bascule autant de fois que tu veux — les octets sous-jacents sont les mêmes.

Copie et envoie

Clique sur Copier pour mettre la sortie dans ton presse-papiers. Glisse-la directement dans un SET Redis, dans une trame texte WebSocket, dans un corps HTTP avec Content-Type: application/x-msgpack, ou dans une colonne bytea Postgres (décode d'abord le base64). Pour faire le chemin inverse, colle-la dans notre page MessagePack vers JSON.

Quand tu vas vraiment t'en servir

Réduire les trames WebSocket

Les apps temps réel avec des mises à jour bavardes à la seconde sentent la différence de taille. Une mise à jour de position ou un tick d'order book qui pèse 220 octets en JSON tombe à ~140 octets en msgpack — sur des milliers de trames par seconde, ça compte. Convertis ici un message d'exemple, colle les octets dans ton harnais de test et vérifie que le récepteur les décode pareil.

Compacter des valeurs en cache

Les caches comme Redis te facturent chaque octet stocké et chaque octet lu. Encoder les objets en cache en msgpack plutôt qu'en texte JSON-stringifié réduit le stockage et le réseau à chaque hit. Sers-toi de cette page pour vérifier à quoi ressemble un objet donné en octets avant de figer l'encodage dans ton sérialiseur.

Envoyer des nombres typés

JSON n'a qu'un seul type numérique et traite 42 exactement comme 42.0. MessagePack distingue entier et flottant sur le fil — utile quand le récepteur est dans un langage fortement typé comme Go, Rust ou C# et que tu ne veux pas faire un aller-retour par une chaîne. Colle un nombre JSON et inspecte l'octet de type dans la sortie hex pour confirmer qu'il a bien été encodé en int, pas en float.

Déboguer un décodeur

Tu as un service qui "devrait" sortir du msgpack mais le consommateur s'étrangle sur les octets ? Encode le même JSON ici, compare la sortie de ton service à la nôtre octet par octet en mode hex, et la divergence te dit exactement quel champ ou quel type est faux. L'encodeur de référence suit la spec publiée à la lettre.

Questions fréquentes

Le JSON quitte-t-il jamais mon navigateur ?

Non. Le JSON est parsé par le JSON.parse intégré au navigateur, encodé par la librairie @msgpack/msgpack en JavaScript côté client, puis rendu en base64 ou hex dans le panneau de droite — aucun appel serveur, aucune télémétrie sur l'entrée, rien n'est loggé. Tu peux ouvrir DevTools et constater que l'onglet réseau reste muet pendant que tu tapes. Sûr pour des configs propriétaires et des données client.

Pourquoi la sortie est-elle plus grosse que prévu ?

En général, deux raisons. D'abord, base64 gonfle le nombre d'octets d'environ 33 % — si tu compares msgpack-en-base64 à du texte JSON directement, tu ne compares pas la taille réelle sur le fil. Bascule en hex (qui gonfle x2) ou, mieux, regarde la longueur en octets : dans DevTools, atob(output).length te donne la vraie taille. Ensuite, msgpack ne bat JSON que quand les données contiennent beaucoup de nombres, de booléens ou de chaînes courtes répétées. Un blob composé à 90 % de longues chaînes uniques fera à peu près la même taille dans les deux formats.

Comment sont gérés les entiers, flottants et grands nombres ?

Le JSON.parse de JavaScript transforme chaque nombre en flottant 64 bits, donc au moment où les données arrivent à l'encodeur, on a déjà perdu la distinction entier vs flottant. La librairie est raisonnable là-dessus : une valeur entière dans la plage des safe-int est encodée en int (en utilisant la plus petite variante — fixint, int8, int16, int32 ou int64). Tout le reste est encodé en float64. Si tu as besoin d'entiers 64 bits exacts (comme des Snowflake IDs), passe-les dans ton JSON en chaînes, puis convertis-les côté récepteur.

Puis-je encoder des blobs binaires (octets de fichier) avec ça ?

Pas directement via JSON, non — JSON n'a pas de type bin, donc un Uint8Array fait un aller-retour par cette UI sous forme de chaîne base64 et est ré-encodé en str msgpack, pas en bin. Si tu as besoin de vrais types bin ou ext msgpack (les deux grosses fonctionnalités exclusives à msgpack), tu dois construire l'objet en code et appeler encode directement avec un Uint8Array à la place. Le panneau JSON couvre les 90 % des cas où tes données ont déjà la forme d'un JSON.

Quelle est la différence entre la sortie hex et base64 ?

Ce sont deux façons d'écrire les mêmes octets en texte. Hex, c'est deux caractères par octet (donc 0x82 devient la chaîne "82") — pratique pour lire à l'œil les octets de type de la spec. Base64, c'est quatre caractères pour trois octets selon la RFC 4648 — plus dense, et la façon standard d'embarquer du binaire dans du JSON, des JWT ou des en-têtes HTTP. Choisis ce qui convient à l'endroit où tu colles la sortie.

Est-ce que msgpack est vraiment plus rapide que JSON, ou juste plus petit ?

Plus petit, c'est généralement le gain le plus important. Côté vitesse encode/decode, le JSON.parse moderne est tellement optimisé que msgpack fait jeu égal ou ne gagne que 10-20 % en JS. Le bénéfice sérialisation se voit en aval : payloads plus petits = moins de temps réseau et moins de travail pour le récepteur si c'est un langage où parser du JSON coûte plus cher que parser du msgpack (suivez mon regard, Python). Règle rapide : choisis msgpack si le goulot est la bande passante ou le stockage ; reste sur JSON si c'est la lisibilité et l'outillage.

Autres outils MessagePack

L'encodage, c'est un sens. Ceux-ci couvrent le reste de l'aller-retour :