Protokolle / Binärserialisierung
Hex-Bytes ab dem Frame-Header einfügen. Beispiele zeigen Maskierung, Fragmente und einen unvollständigen Frame.
Ab dem Header: 81 05 48 65 6c 6c 6f. Ganze Bytes mit Leerraum, Komma oder Doppelpunkt trennen; 0x je Byte.
Frame-Bytes eingeben oder ein Beispiel wählen.
Alle Eingaben werden in diesem Tab verarbeitet, nicht versendet oder gespeichert.
Frame-Bytes eingeben oder ein Beispiel wählen.
Mit einem Logeintrag allein lässt sich die Nachrichtengrenze oft nicht erkennen. Hier können Sie WebSocket-Frames dekodieren und jeden Anfang mit dem Mitschnitt vergleichen. Ein Ping zwischen zwei Fragmenten bleibt ein eigener Frame, statt versehentlich als Textteil behandelt zu werden.
Ein WebSocket Frame Decoder benötigt die Bytes nach dem HTTP-Upgrade einschließlich Frame-Header. Browser-Ereignisse liefern normalerweise bereits die Anwendungsdaten. Ein kompletter TCP-Mitschnitt oder der Text aus einem message-Ereignis ist deshalb kein passender Ersatz.
WebSocket-Frames dekodieren heißt hier, mit Headergröße und Payload-Länge bis zum nächsten Anfang weiterzugehen. Bei einem späteren Abbruch bleiben vorherige vollständige Frames sichtbar. Der Export wird gesperrt, damit ein Teilbefund nicht als vollständiger Bericht weitergegeben wird.
Die WebSocket Maskierung wiederholt einen Schlüssel aus vier Bytes über die Nutzdaten. Die Ansicht trennt Drahtdarstellung und XOR-Ergebnis. Bei jedem Frame beginnt die Berechnung mit dessen eigenem Schlüssel von vorn; die Länge bleibt unverändert.
Client-Frames benötigen eine Maske, Server-Frames dürfen sie nicht tragen. Ohne Richtungsangabe entfällt nur diese Prüfung. Das Werkzeug trennt keinen gemischten Dialog; verwenden Sie einen geordneten Ausschnitt aus einer Richtung.
Pro Payload erscheinen höchstens 256 Bytes. Das ist eine Anzeigegrenze. Fehlende Bytes gegenüber der deklarierten Länge sind dagegen ein Strukturfehler mit Position und Mengenangabe. Nur dieser verhindert den vollständigen Export.
Automatisch wird nach 350 ms ohne Änderung gerechnet. Ausgeschaltet erscheinen der Analyseknopf und Ctrl/Cmd+Enter. Änderungen sperren alte Exporte sofort. Beispiel und Leeren zeigen zuerst den Ersatzumfang; Rückgängig stellt Eingabe und Ergebnis gemeinsam wieder her.
Der Parser liest den kurzen Wert sowie Erweiterungen mit 16 oder 64 Bit in Netzwerkreihenfolge. Große Angaben werden vor Speicherzuweisungen als exakte Ganzzahlen geprüft. Eine unnötig lange Kodierung bleibt mit Warnung sichtbar.
Close, Ping und Pong werden einzeln ausgewiesen. Bei Close bilden zwei Bytes den Statuscode, der Rest den UTF-8-Grund. Ungültige FIN-Werte, Steuerlängen und Codes werden gemeldet. Daraus folgt keine Aussage über einen erfolgreichen Verbindungsabschluss.
Ein vollständiger einzelner Textframe wird streng als UTF-8 geprüft. Lesbare Binärdaten bleiben eine Vorschau. Fortsetzungsrahmen und Erweiterungen erhalten keine vermeintlich vollständige Textdarstellung. Ein an der Vorschaugrenze geteilter Codepunkt wird nicht beschädigt ausgegeben.
Fehlende Header, Längenfelder, Maskenschlüssel oder Nutzdaten stoppen die Analyse mit Byte-Offset sowie Zeile und Spalte. RSV und reservierte Opcodes bleiben dagegen als Warnungen erhalten, sofern die strukturellen Grenzen bestimmbar sind.
Ein Client verändert die Drahtbytes mit einem vier Byte langen Schlüssel, damit kontrollierbare Daten keine Zwischenstationen täuschen. Dasselbe wiederholte XOR stellt den Inhalt her. Da der Schlüssel im Frame steht, ist dies keine Verschlüsselung. Serverframes sind im Basisprotokoll unmaskiert.
Die Werte markieren ein nachfolgendes Längenfeld von zwei beziehungsweise acht Bytes in Big-Endian. Sie sind nicht die tatsächlichen Payload-Größen. Beim 64-Bit-Feld muss das oberste Bit null sein. Header und Maskenschlüssel zählen nicht zur Nutzdatenlänge.
Ja, sofern die Frames aus derselben Richtung in ihrer ursprünglichen Reihenfolge vorliegen. Auch leere Payloads und eingeschobene Steuerframes bleiben einzeln sichtbar. Einen unvollständigen Frame müssen Sie vor dem Berichtsexport ergänzen oder den Ausschnitt korrigieren.
Eine leere Payload enthält keinen Code. Andernfalls bilden die ersten zwei Bytes den Status, gefolgt von einem UTF-8-Grund. Ein einzelnes Byte, unzulässige Codes oder ungültiges UTF-8 erzeugen Warnungen. Ein leerer Close wird nicht automatisch zu einem normalen Abschluss umgedeutet.
Nein. HTTP-Upgrade-Anfragen und Antworten liegen vor dem Frameformat. Extrahieren Sie zuerst die anschließenden Rohframes. Das Werkzeug entfernt keine TCP/IP- oder TLS-Hüllen, baut keine Verbindung auf und bestätigt keinen Server-Handshake.
Eine unerwartete Berechnung entdeckt?
WebSocket-Frames dekodieren hilft, Schlüssel und Offsets abzugleichen und den ersten unvollständigen Frame einzugrenzen, bevor Sie Ihren Anwendungscode ändern.