Eingabe

Ausgabe

Was ist JSON zu MessagePack?

Du hast eine JSON-Config, die gleich über einen knapp bemessenen WebSocket gehen muss — MessagePack drückt sie um 30-60% gegenüber demselben Payload als JSON, und das ohne das schemalose "ist halt ein Objekt"-Gefühl aufzugeben, das JSON so angenehm macht. Diese Seite kodiert das links eingefügte JSON rechts als msgpack-Byte-Stream, standardmäßig als base64 dargestellt und mit einem Klick auf hex umschaltbar.

Die Kodierung läuft komplett im Browser über die offizielle @msgpack/msgpack-Library, das JSON verlässt also nie den Tab. Unter der Haube parsen wir den Input mit JSON.parse (dem in der JSON-RFC beschriebenen Parser), übergeben das Objekt an msgpackEncode und wandeln das zurückgelieferte Uint8Array in einen transportfreundlichen String um — base64 (gemäß RFC 4648) oder hex in Kleinbuchstaben.

Nimm base64, wenn du die Bytes in JSON, einen HTTP-Header oder ein Datenbankfeld einbettest. Nimm hex, wenn du eine Stichprobe Byte für Byte gegen die msgpack-Wire-Spec oder ein Server-Log abgleichst. Gleiche Bytes, andere Darstellung.

So benutzt du den JSON-zu-MessagePack-Encoder

Drei Schritte. Die Konvertierung läuft beim Tippen automatisch — kein Button zum Klicken.

JSON einfügen oder Beispiel laden

Wirf dein JSON in den linken Editor. Klick auf Beispiel-JSON für einen kleinen Bestell-Payload, der die wichtigen Fälle abdeckt — Strings, Integers, Floats und ein verschachteltes Array. Der Encoder behandelt den Input nach dem Standard-Typsystem von MessagePack: Integers landen in der kleinsten passenden Form fixint/int8/int16/int32/int64, Floats werden zu float64, Strings je nach Länge zu fixstr/str8/16/32, Arrays nutzen fixarray/array16/32 und Maps fixmap/map16/32. Beispiel-Eingabe:

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

Ein 90-Byte-JSON wie dieses kodiert sich typischerweise auf ~55 Byte msgpack — ein Drittel kleiner, bevor du überhaupt eine gzip-Schicht draufpackst.

Hex oder Base64 umschalten

Das Ausgabeformat ist standardmäßig base64, weil das meistens in Configs eingefügt oder über die Leitung geschickt wird. Klick auf Hex-Ausgabe, um auf hex in Kleinbuchstaben zu wechseln, falls du einen Diff gegen einen serverseitigen Encoder machst oder die Typ-Bytes mit dem Auge prüfen willst (z.B. 0x82 für ein fixmap mit 2 Einträgen). Schalte so oft du willst um — die zugrunde liegenden Bytes sind dieselben.

Kopieren und losschicken

Klick auf Kopieren, um die Ausgabe in die Zwischenablage zu legen. Wirf sie direkt in ein Redis-SET, einen WebSocket-Text-Frame, einen HTTP-Body mit Content-Type: application/x-msgpack oder eine Postgres-bytea-Spalte (vorher base64 dekodieren). Für die Gegenrichtung füg sie in unsere MessagePack zu JSON-Seite ein.

Wann du das wirklich brauchst

WebSocket-Frames schrumpfen

Echtzeit-Apps mit gesprächigen Sekunden-Updates spüren den Größenunterschied. Ein Positions-Update oder Order-Book-Tick mit 220 Byte als JSON fällt auf ~140 Byte als msgpack — bei Tausenden Frames pro Sekunde summiert sich das. Konvertiere hier eine Beispiel-Nachricht, füg die Bytes in dein Test-Harness ein und prüf, ob der Empfänger sie genauso dekodiert.

Cache-Werte komprimieren

Caches wie Redis berechnen dir jedes gespeicherte und jedes gelesene Byte. Cache-Objekte als msgpack statt als JSON-stringifizierten Text zu kodieren spart bei jedem Hit Speicher und Netzwerk. Mit dieser Seite kannst du vorab prüfen, wie ein bestimmtes Objekt als Bytes aussieht, bevor du dich in deinem Serializer auf die Kodierung festlegst.

Typisierte Zahlen senden

JSON hat genau einen Zahlentyp und behandelt 42 wie 42.0. MessagePack unterscheidet auf der Leitung zwischen Integer und Float — praktisch, wenn der Empfänger eine streng typisierte Sprache wie Go, Rust oder C# ist und du nicht über einen String hin- und herwillst. Füg eine JSON-Zahl ein und schau dir das Typ-Byte in der Hex-Ausgabe an, um zu bestätigen, dass sie als int und nicht als float kodiert wurde.

Einen Decoder debuggen

Du hast einen Service, der "eigentlich" msgpack liefern sollte, aber der Consumer würgt an den Bytes? Kodiere dasselbe JSON hier, vergleich die Ausgabe deines Service mit unserer im Hex-Modus Byte für Byte, und die Abweichung sagt dir genau, welches Feld oder welcher Typ falsch ist. Der Referenz-Encoder folgt der veröffentlichten Spec exakt.

Häufige Fragen

Verlässt das JSON jemals meinen Browser?

Nein. Das JSON wird vom eingebauten JSON.parse des Browsers geparst, von der @msgpack/msgpack-Library in clientseitigem JavaScript kodiert und im rechten Bereich als base64 oder hex gerendert — kein Server-Aufruf, keine Telemetrie über die Eingabe und nichts wird geloggt. Du kannst die DevTools öffnen und nachsehen, dass der Network-Tab beim Tippen still bleibt. Sicher für proprietäre Configs und Kundendaten.

Warum ist die Ausgabe größer als erwartet?

Meistens zwei Gründe. Erstens: base64 bläht die Byte-Anzahl um etwa 33% auf — wenn du base64-msgpack direkt mit JSON-Text vergleichst, vergleichst du nicht die tatsächliche Wire-Größe. Schalte auf hex um (das bläht 2x auf) oder schau noch besser auf die Byte-Länge: in den DevTools liefert dir atob(output).length die echte Größe. Zweitens: msgpack schlägt JSON nur dann, wenn die Daten viele Zahlen, Booleans oder wiederholte kurze Strings enthalten. Ein Blob, der zu 90% aus langen, eindeutigen Strings besteht, wird in beiden Formaten ungefähr gleich groß.

Wie werden Integers, Floats und große Zahlen behandelt?

JavaScripts JSON.parse macht aus jeder Zahl einen 64-Bit-Float, also ist die Int-vs-Float-Unterscheidung schon weg, bevor die Daten beim Encoder ankommen. Die Library handhabt das vernünftig: Ein Wert, der ganzzahlig und im Safe-Int-Bereich ist, wird als int kodiert (in der kleinsten passenden Variante — fixint, int8, int16, int32 oder int64). Alles andere wird als float64 kodiert. Wenn du exakte 64-Bit-Integers brauchst (z.B. Snowflake IDs), schick sie im JSON als Strings durch und konvertier sie auf der Empfängerseite.

Kann ich damit binäre Blobs (z.B. Datei-Bytes) kodieren?

Direkt über JSON nein — JSON hat keinen bin-Typ, also macht ein Uint8Array über diese UI eine Runde als base64-String und wird wieder als msgpack-str kodiert, nicht als bin. Wenn du echte msgpack-bin- oder ext-Typen brauchst (die zwei großen msgpack-only-Features), musst du das Objekt im Code zusammenbauen und encode direkt mit einem Uint8Array drinnen aufrufen. Der JSON-Bereich deckt die 90%-Fälle ab, in denen die Daten ohnehin schon JSON-förmig sind.

Was ist der Unterschied zwischen hex- und base64-Ausgabe?

Zwei Arten, dieselben Bytes als Text aufzuschreiben. Hex sind zwei Zeichen pro Byte (also wird aus 0x82 der String "82") — gut, um die Typ-Bytes der Spec mit dem Auge zu lesen. Base64 sind vier Zeichen pro drei Bytes nach RFC 4648 — dichter und der Standardweg, Binärdaten in JSON, JWTs oder HTTP-Headern unterzubringen. Nimm das, was zu der Stelle passt, an die du die Ausgabe einfügst.

Ist msgpack tatsächlich schneller als JSON oder einfach nur kleiner?

Kleiner ist meistens der größere Gewinn. Bei der Encode-/Decode-Geschwindigkeit ist modernes JSON.parse so optimiert, dass msgpack in JS gleichzieht oder nur 10-20% gewinnt. Der Serialisierungs-Vorteil zeigt sich weiter unten in der Pipeline: kleinere Payloads bedeuten weniger Netzwerk-Zeit und weniger Arbeit für den Empfänger, falls er in einer Sprache läuft, in der JSON-Parsen teurer ist als msgpack-Parsen (gemeint bist du, Python). Faustregel: Nimm msgpack, wenn der Engpass Bandbreite oder Speicher ist; bleib bei JSON, wenn es Lesbarkeit und Tooling sind.

Weitere MessagePack-Tools

Kodieren ist nur eine Richtung. Diese Tools decken den Rest der Hin- und Rückfahrt ab: