Zum Hauptinhalt springen
ToolsByUs

JSON-Escapes auflösen

Dieses Tool macht das Escaping von Zeichenketten rückgängig: Aus \" wird wieder ein Anführungszeichen, aus \n ein Zeilenumbruch und aus \uXXXX das zugehörige Zeichen – so wird das Dokument wiederhergestellt, das in ein anderes eingebettet war. Das Tool ist absichtlich tolerant gegenüber Fragmenten, die aus Logzeilen kopiert wurden und denen meist die äußeren Anführungszeichen fehlen.

Nur lokal
Maskierte Zeichenfolge
0 B1 ZeileZ. 1, Sp. 1
Wiederhergestelltes Dokumentschreibgeschützt
0 B1 Zeile

Wie funktioniert JSON-Escapes auflösen?

Sie kommen fast immer über eine Logdatei zu diesem Tool. Irgendetwas hat einen Request-Body geloggt, indem es das gesamte JSON-Dokument in ein einzelnes Zeichenkettenfeld gepackt hat, und was Sie vor sich haben, ist eine dichte Zeile voller \" dort, wo Anführungszeichen stehen sollten, mit \n statt Zeilenumbrüchen und \\ überall dort, wo ein Windows-Pfad auftauchte. Technisch ist das lesbar, praktisch nicht.

Unescaping ist das Gegenstück zum Escaping und mechanisch simpel: den Text durchgehen und jedes Mal, wenn ein Backslash auftaucht, das Zeichen danach mitnehmen und ausgeben, wofür das Paar steht. Die eigentliche Kunst liegt darin, mit unvollkommener Eingabe umzugehen, und fast immer ist sie unvollkommen.

Ein strenger JSON-Parser würde das meiste verwerfen, was Leute hier einfügen. Die umgebenden Anführungszeichen hat das Fragment meist beim Kopieren verloren, weil jemand den interessanten Teil markiert hat. Es kann an der Längenbegrenzung eines Logfelds abgeschnitten sein. Es kann einen Backslash enthalten, der gar kein gültiges JSON-Escape ist, weil das Programm, das ihn erzeugt hat, für ein anderes Ziel escapen musste. Ein Parser, der all das ablehnt, ist korrekt und nutzlos.

Dieses Tool ist also mit Absicht tolerant. Fehlende äußere Anführungszeichen sind in Ordnung und werden gemeldet, statt verlangt zu werden. Ein unbekanntes Escape wie \q behält beide Zeichen und löst eine Warnung aus. Ein Backslash am Ende bleibt erhalten. Eine unvollständige \u-Sequenz wird unverändert belassen. In jedem Fall wird der Rest des Dokuments trotzdem wiederhergestellt, denn eine teilweise wiederhergestellte Nutzlast nützt weit mehr als eine Fehlermeldung.

Unicode wird richtig behandelt. Ein \uXXXX-Escape wird zu seinem Zeichen, und einem hohen Surrogat, auf das ein niedriges folgt, wird das eine Zeichen wieder zugewiesen, das beide gemeinsam kodieren – ohne diesen Schritt käme jeder Emoji und jedes seltenere CJK-Zeichen als zwei Ersatzkästchen heraus.

Nach dem Unescaping wird das Ergebnis geprüft: Ist es gültiges JSON, wird es formatiert, was fast immer das ist, was Sie eigentlich wollten. Ist es das nicht, wird es als Klartext samt Parse-Fehler gezeigt, damit Sie sehen können, ob das Dokument im Log abgeschnitten wurde oder schon kaputt ankam.

Escapte Zeichenkette

"{\"name\":\"Ada\",\"note\":\"line one\nline two\"}"

Wiederhergestelltes Dokument

{
  "name": "Ada",
  "note": "line one
line two"
}

Welche Optionen und Sonderfälle unterstützt JSON-Escapes auflösen?

Technische Referenz und Optionen
ParameterTypStandardVerhalten & Sonderfälle
\" \\ \/escape—Anführungszeichen, Backslash und Schrägstrich. Der Escaped-Schrägstrich ist in JSON zwar erlaubt, aber optional, weshalb er in der Ausgabe mancher Generatoren erscheint und in anderen nicht.
\n \r \t \b \fescape—Die benannten Steuerzeichen. \n ist das eine, das den Unterschied zwischen einer unübersichtlichen Textwand und einem lesbaren Dokument ausmacht.
\uXXXXescape—Ein UTF-16-Code-Unit. Ein hoher Surrogat, gefolgt von einem niedrigen, wird zu dem einen Zeichen, das es kodiert, wieder zusammengesetzt; ohne das kommen alle Emojis und viele CJK-Zeichen als zwei kaputte Kästen zurück.
Umschließende Anführungszeichenoptionalentfernt, wenn vorhandenEin Fragment, das aus einer Log-Zeile kopiert wurde, hat diese normalerweise verloren. Ob sie vorhanden waren, wird gemeldet, aber nicht verlangt.
Unbekannte Escape-Sequenzbeibehalten + Warnung—\q und Ähnliches behalten beide Zeichen. Ein strenger Parser lehnt das ganze Dokument ab; beim Weitergehen wird der Rest wiederhergestellt, was das Ziel war.
Einzelner Surrogatbeibehalten + Warnung—Ein hoher Surrogat ohne niedriges Gegenstück kann kein Zeichen bilden. Er wird erhalten und markiert, da er normalerweise bedeutet, dass die Quelle mitten im Zeichen abgeschnitten wurde.
FormatierenBooleschtrueFügt Einrückungen hinzu, wenn der wiederhergestellte Text gültiges JSON ist. Wenn er es nicht ist, wird der rohe Text mit dem Parse-Fehler angezeigt, was ein abgeschnittenes Log-Feld von einem bereits kaputten Dokument unterscheidet.

Häufig gestellte Fragen

Meine Logzeile ist doppelt escapet. Muss ich das Tool zweimal ausführen?

Ja. Doppel-Escaping entsteht, wenn eine bereits escapte Zeichenkette erneut escapet wird – eine Nutzlast wurde als Zeichenkette geloggt, und diese Logzeile wurde dann von einem Aggregator erneut als Zeichenkette geloggt. Sie sehen \\\" dort, wo \" stehen sollte. Führen Sie die Ausgabe erneut durch das Tool, und die zweite Schicht fällt ab. Wenn nach einem Durchlauf alles gleich aussieht, haben Sie das Ende erreicht.

Warum ist das Ergebnis immer noch kein gültiges JSON?

Meistens eine Abschneidung. Logfelder haben Längenbegrenzungen, das Dokument wird also oft mitten in der Zeichenkette oder mitten im Objekt abgeschnitten, und wer es fehlerfrei dekodiert, erhält etwas, das sich nicht parsen lässt, weil es tatsächlich unvollständig ist. Der Parse-Fehler nennt Zeile und Spalte, an denen er abbricht – was normalerweise genau am Abschneidepunkt liegt.

Was ist mit meinen Emojis passiert?

Wenn sie überlebt haben, wurde das Surrogatpaar korrekt wieder zusammengefügt. Zeigt ein Tool stattdessen zwei Kästchen, hat es jede \uXXXX-Hälfte einzeln dekodiert – Zeichen außerhalb der Basic Multilingual Plane werden als zwei Codeeinheiten kodiert und müssen verbunden werden. Dieses Tool verbindet sie und warnt, wenn es eine einzelne Hälfte findet, was auf eine Abschneidung hindeutet.

Kann ich Text einfügen, der kein JSON ist?

Ja. Das Unescaping arbeitet auf Textebene, ein escaptes SQL-Statement, ein escaptes HTML-Fragment oder ein escapter Shellbefehl lässt sich also problemlos dekodieren. Das Tool meldet lediglich, dass das Ergebnis kein gültiges JSON ist, und zeigt es als Klartext, statt es zu formatieren.

Wird die Logzeile, die ich einfüge, irgendwohin gesendet?

Nein. Das Unescaping läuft in Ihrem Browser. Das ist hier wichtiger als bei den meisten Tools: Die Logzeilen, die Leute dekodieren, sind häufig Request-Bodies aus der Produktion mit Tokens, Sitzungs-IDs und Kundendaten – und wer so eine Zeile in ein serverseitiges Tool einfügt, kopiert sie in ein zweites Access-Log.

Ändert das Unescaping die Zeichen oder nur, wie sie geschrieben sind?

Nur, wie sie geschrieben sind. \u00e9 und é sind zwei Schreibweisen desselben Zeichens, und das Unescaping schreibt die Schreibweise um – heraus kommt exakt der Text, den die escapte Form kodiert hat. Deshalb sieht die Ausgabe manchmal auch identisch mit der Eingabe aus: Eine Logzeile, in der nichts escapet ist, hat nichts zu ändern.

ToolsByUs-Team · Wie wir unsere Tools prüfen