JSON-Maskierung / Demaskierung
Escapen Sie Sonderzeichen in einem String für sicheres JSON-Embedding, oder unescape Sie einen escapten JSON-String zurück in einfachen Text.
Funktionsweise
- Ihren String einfügen: Geben Sie den Text ein, den Sie escapen möchten, das kann Rohtext mit Anführungszeichen, Zeilenumbrüchen, Backslashes oder beliebigen Sonderzeichen sein.
- Escape oder Unescape wählen: Wählen Sie, ob Sie Text zum Einbetten in JSON escapen oder einen JSON-String zurück in lesbaren Text unescapen möchten.
- Das Ergebnis kopieren: Die escape- oder unescape-Ausgabe erscheint sofort. Kopieren Sie sie zur Verwendung in Ihrem Code oder Ihren Daten.
Warum den JSON-String-Escape verwenden?
JSON-Strings haben strenge Escaping-Regeln, doppelte Anführungszeichen müssen zu \" werden, Zeilenumbrüche zu \n, Backslashes zu \\ und Tabs zu \t. Diese Zeichen nicht korrekt zu escapen, verursacht JSON-Parse-Fehler, die APIs, Konfigurationsdateien und Datenpipelines unterbrechen. Dieses Tool behandelt das gesamte Escaping und Unescaping automatisch, eliminiert manuelles Suchen-und-Ersetzen und verhindert subtile Bugs durch verpasste Escape-Sequenzen.
Funktionen
- Vollständige Escape-Abdeckung: Behandelt Anführungszeichen, Backslashes, Zeilenumbrüche, Tabs, Wagenrückläufe und Unicode-Escape-Sequenzen.
- Bidirektional: Sowohl escapen (Text → JSON-String) als auch unescapen (JSON-String → Text) in einem Tool.
- Sofortige Ergebnisse: Die Ausgabe aktualisiert sich beim Tippen ohne Verzögerung.
- In die Zwischenablage kopieren: Ein-Klick-Kopieren des escapten oder unescapten Ergebnisses.
- Datenschutz zuerst: Die gesamte Verarbeitung läuft lokal, sensible Strings verlassen niemals Ihr Gerät.
Häufig gestellte Fragen
Welche Zeichen behandelt das JSON-Escaping?
JSON erfordert Escaping für: doppelte Anführungszeichen ("), Backslash (\), Schrägstrich (/), Zeilenumbruch (\n), Wagenrücklauf (\r), Tab (\t), Form-Feed (\f), Backspace (\b) und Unicode-Zeichen über U+FFFF. Dieses Tool behandelt sie alle.
Warum ist mein JSON-Parse-Fehler durch Escaping verursacht?
Häufige Ursachen sind nicht-escapte doppelte Anführungszeichen innerhalb eines String-Werts, wörtliche Zeilenumbrüche innerhalb eines Strings (müssen \n sein) und nicht-escapte Backslashes. Fügen Sie Ihren defekten String hier ein, um ihn korrekt zu escapen.
Schließt das die umgebenden Anführungszeichen ein?
Standardmäßig escaped das Tool den Inhalt ohne umschließende Anführungszeichen, sodass Sie das Ergebnis in Ihren JSON-String einfügen können. Aktivieren Sie die Option „Anführungszeichen einbeziehen", wenn Sie die Ausgabe in doppelte Anführungszeichen einschließen möchten.
Die JSON-String-Spezifikation, in einer Tabelle
RFC 8259 (Dezember 2017, von Tim Bray) ist der aktuelle JSON-Standard und ersetzt RFC 7159 und das ursprüngliche RFC 4627. Abschnitt 7 der Spezifikation listet genau auf, welche Zeichen innerhalb eines String-Literals escaped werden MÜSSEN:
| Zeichen | Escape | Codepunkt | Bedeutung |
|---|---|---|---|
" | \" | U+0022 | Anführungszeichen (beendet den String) |
\ | \\ | U+005C | Backslash (startet einen Escape) |
\b | \b | U+0008 | Rückschritt |
\f | \f | U+000C | Seitenvorschub |
\n | \n | U+000A | Zeilenvorschub (LF) |
\r | \r | U+000D | Wagenrücklauf (CR) |
\t | \t | U+0009 | Tab |
/ | \/ | U+002F | Schrägstrich (optional, aber nützlich für HTML-Einbettung) |
| control | \uXXXX | U+0000–U+001F | jedes C0-Steuerzeichen, das oben nicht abgedeckt ist |
Äquivalente Regeln finden sich in ECMA-404 (2. Edition, Dezember 2017), synchron mit der IETF-Spezifikation gehalten. JSON hat keine oktalen (\012) oder hexadezimalen (\x41) Escapes, diese sind JavaScript-only; JSON unterstützt nur die acht oben benannten Escapes plus \uXXXX.
Der \uXXXX-Escape und die Surrogatpaar-Falle
JSONs \uXXXX-Sequenzen codieren UTF-16-Code-Einheiten, keine Unicode-Codepunkte. Das ist wichtig für Emoji und Zeichen der ergänzenden Ebene. Ein einzelnes Emoji wie 😀 (U+1F600) wird nicht als \u1F600 (das ist nicht einmal eine legale vierstellige Hex-Form) escaped, sondern als Surrogatpaar: \uD83D\uDE00, zwei aufeinanderfolgende Escapes, die das hohe und niedrige Surrogat codieren. Der hohe Surrogatbereich ist U+D800–U+DBFF; der niedrige ist U+DC00–U+DFFF; zusammen decken sie U+10000 bis U+10FFFF ab (die ergänzenden Ebenen).
Dies ist die häufigste Quelle für Emoji-Escape-Bugs. RFC 8259 Abschnitt 7 sagt ausdrücklich: «Um ein erweitertes Zeichen zu escapen, das nicht in der Basic Multilingual Plane liegt, wird das Zeichen als 12-Zeichen-Sequenz dargestellt, die das UTF-16-Surrogatpaar codiert.» Ein Vierer-Familien-Emoji wie 👨👩👧👦, das technisch vier Basis-Emoji plus drei Nullbreiten-Verbinder ist, wird als 30+ Zeichen in einem JSON-String escaped. Die Byte-Zählung schwillt entsprechend an: 25 UTF-8-Bytes roh, ~58 Bytes nach JSON-Escape.
JSON innerhalb von HTML, URL, SQL und CSV
JSON-Escaping allein reicht nicht aus, wenn das JSON in ein anderes Format eingebettet ist. Jeder Kontext fügt seine eigene Schicht hinzu.
JSON innerhalb von HTML. Die klassische Falle ist <script>const data = {{ payload | json }};</script>, wenn der Payload den literalen Teilstring </script> enthält. Der HTML-Parser schließt das Script-Tag mitten im String und der Rest des JSON wird als sichtbarer Text auf der Seite gerendert. Die Lösung ist der optionale \/-Escape: <\/script> ist JSON-gültig und HTML-sicher. Das Cross-Site-Scripting-Cheat-Sheet von OWASP empfiehlt, in JSON, das zur HTML-Einbettung bestimmt ist, immer <, >, & und ' zu escapen.
JSON innerhalb eines URL-Query-Strings. Zwei Schichten: zuerst JSON-Escape, dann Percent-Encoding. {"name":"Bob"} wird zu %7B%22name%22%3A%22Bob%22%7D. Das Vergessen des Percent-Encodings ist Ursache Nr. 1 für fehlerhafte JSON-in-URL-Bugs.
JSON innerhalb von SQL. In einer PostgreSQL-jsonb-Spalte gespeichert wird der Wert nativ geparst, kein weiteres Escapen nötig. Aber in einem SQL-String-Literal eingebettetes JSON (INSERT INTO t (data) VALUES ('{"key":"value"}')) benötigt SQL-String-Escaping zusätzlich zu JSON: verdoppelte einfache Anführungszeichen (''), oder besser, verwenden Sie parametrisierte Abfragen.
JSON innerhalb von CSV-Zellen. CSVs Anführungszeichen unterscheiden sich von JSONs (CSV verwendet verdoppelte Anführungszeichen "", keine Backslash-Sequenzen). Das Einbetten von JSON in eine CSV-Zelle benötigt beide Schichten: zuerst JSON-Escape des Strings, dann CSV-Escape des Ergebnisses (in "..." einwickeln, jedes interne " verdoppeln).
Laufzeit-APIs in mehreren Sprachen
| Sprache | Codieren | Decodieren | Notizen |
|---|---|---|---|
| JavaScript | JSON.stringify | JSON.parse | Nativ seit IE 8 (2009). Verfügbar in jedem Browser und Node. |
| Python | json.dumps | json.loads | ensure_ascii=False verzichtet auf \uXXXX-Escape für nicht-ASCII. |
| PHP | json_encode | json_decode | Nativ seit PHP 5.2 (Nov 2006). Flag JSON_UNESCAPED_UNICODE seit 5.4. |
| Java | ObjectMapper.writeValueAsString | readTree | Jackson ist seit ~2009 der De-facto-Standard. |
| Go | json.Marshal | json.Unmarshal | Standardbibliothek encoding/json. |
| Rust | serde_json::to_string | serde_json::from_str | Das serde_json-Crate, allgegenwärtig. |
Woher JSON kam und was Crockford weggelassen hat
JSON wurde erstmals von Douglas Crockford im Jahr 2001 bei State Software formalisiert, ursprünglich um JavaScript-Objekte für asynchronen Datenaustausch zu serialisieren. Die erste öffentliche Erwähnung war auf der Website JSON.org im Jahr 2003. Crockford spezifizierte es formell als RFC 4627 im Juli 2006, zum Teil um einen konkurrierenden Patentversuch etwa zur gleichen Zeit zu bekämpfen. Der Standard erhielt mit RFC 8259 im Dezember 2017 den Status STD 90.
JSONs größte Designentscheidung war, es zu einer Teilmenge von JavaScript zu machen, sodass jedes JSON-Dokument in einem JS-Interpreter eval'd werden könnte und den richtigen Wert ergibt. Das machte die Browser-Adoption reibungslos, schloss aber einige JS-Eigenheiten dauerhaft ein: kein Integer-Typ (alle Zahlen sind IEEE-754-Doubles), kein Datumstyp, kein NaN oder Infinity. Große Ganzzahlen über 2⁵³−1 benötigen eine String-Serialisierung ("id": "9007199254740993"), um stille Präzisionsverluste zu vermeiden.
Crockford ließ absichtlich Dinge weg, die Sie vielleicht vermissen: Kommentare («Ich habe Kommentare aus JSON entfernt, weil ich sah, dass Leute sie zum Speichern von Parsing-Direktiven verwendeten, eine Praxis, die die Interoperabilität zerstört hätte», Mai 2012), nachgestellte Kommas und Schemasprache (später als JSON Schema hinzugefügt, separat gepflegt, aktueller Entwurf 2020-12). Die Community-Variante JSON5 stellt Kommentare und nachgestellte Kommas wieder her, ist aber nicht RFC-konform; sie wird hauptsächlich in Konfigurationsdateien (.babelrc, .swcrc) verwendet, die Menschen bearbeiten.
Häufige Anwendungsfälle
- Daten in HTML-Attribute einbetten, einen String mit
",<,>einfügen und eine sichere Form fürdata-*-Attribute oder Inline-script-Tags erhalten. - API-Request-Bodies von Hand zusammenstellen, wenn man einen Endpoint curl't und der Payload Anführungszeichen oder Zeilenumbrüche enthält.
- Log-Zeilen-Payloads aufbauen, bei denen die Nachricht das Shell-Quoting plus das JSON-Parsing auf der anderen Seite überleben muss.
- Legacy-Daten migrieren von CSV / XML / TSV zu JSON, manueller Anführungszeichen-Escape-Durchgang.
- Server-Antworten debuggen, bei denen der Wert
\u-Sequenzen enthält, entescapen, um zu sehen, was er tatsächlich ist. - Tests schreiben, erwartete JSON-Ausgabe einfügen und für die Aufnahme in eine Testbehauptung escapen.
- Template-Engines (Jinja2, Nunjucks, Liquid, ERB), die JSON in JavaScript oder HTML einbetten.
Häufige Fehler
- Verwenden von JavaScript-Escapes, die nicht JSON-gültig sind.
\x41für «A» und\012für Zeilenumbruch sind in JS-String-Literalen gültig, aber in JSON ungültig. JSON erlaubt nur die acht benannten Escapes plus\uXXXX. - Verwenden einfacher Anführungszeichen für JSON-Strings.
'hello'funktioniert in JavaScript, ist aber ungültiges JSON. JSON-Strings MÜSSEN doppelte Anführungszeichen verwenden. - Unquoted Object-Keys.
{name: "Bob"}funktioniert in JavaScript, ist aber ungültiges JSON. Keys MÜSSEN String-Literale in doppelten Anführungszeichen sein. - Nachgestellte Kommas.
[1,2,3,]funktioniert in JS, ist aber ungültiges JSON. RFC 8259 verbietet sie ausdrücklich. - Inline-Kommentare.
// foound/* foo */sind in Standard-JSON ungültig. Verwenden Sie JSON5, wenn Sie Kommentare benötigen; erwarten Sie, dass nicht jeder Parser es akzeptiert. - Ein Emoji als einzelnes
\uXXXXmanuell escapen. Emoji über U+FFFF benötigen ein UTF-16-Surrogatpaar, zwei\uXXXX-Escapes hintereinander.
Weitere häufig gestellte Fragen
Soll ich den Schrägstrich / immer escapen?
Nein, der Schrägstrich / ist in JSON unescaped erlaubt; der Escape \/ ist optional. Die Ausnahme ist, wenn JSON innerhalb eines HTML-<script>-Tags eingebettet ist: das Escapen von / als \/ verhindert, dass der literale Teilstring </script> das Tag vorzeitig schließt. Einige Encoder (JSON_HEX_TAG in PHP, benutzerdefinierte JS-Ersetzungen) tun dies; die meisten nicht.
Warum escaped JSON.stringify meine nicht-ASCII-Zeichen?
Tut es standardmäßig nicht. JSON.stringify("café") in JavaScript erzeugt "café" mit dem literalen é. Was Sie möglicherweise sehen, ist eine andere Bibliothek: Pythons json.dumps hat standardmäßig ensure_ascii=True und escaped alles außerhalb ASCII als \uXXXX; PHPs json_encode verhält sich ähnlich, es sei denn, Sie übergeben JSON_UNESCAPED_UNICODE. Beide Verhaltensweisen sind gültiges JSON, aber Dateigröße und Lesbarkeit unterscheiden sich.
Kann JSON Binärdaten speichern?
Nicht direkt. JSON-Strings sind Sequenzen von Unicode-Zeichen, keine Bytes. Der Standard-Workaround besteht darin, das Binär zuerst mit Base64 zu kodieren und dann den resultierenden ASCII-String als normalen JSON-Wert zu speichern. Die codierten Daten sind ~33% größer als die rohen Bytes. Für sehr große Binärdaten verwenden Sie ein Binärformat wie BSON, MessagePack oder CBOR, oder speichern Sie die Bytes separat und referenzieren Sie sie per URL.
Warum zeigen einige Werkzeuge \u00e9 statt é?
Beide sind gültiges JSON für dasselbe Zeichen. "caf\u00e9" und "café" decodieren zu identischen Strings. Einige Encoder escapen Nicht-ASCII für maximale Cross-Encoding-Sicherheit (die Ausgabe ist reines ASCII, sodass die Codierung des Konsumenten egal ist), andere bewahren das ursprüngliche UTF-8 für die Lesbarkeit. Wählen Sie basierend darauf, was Ihr JSON verbraucht.
Wird mein Text irgendwohin hochgeladen?
Nein. Das Werkzeug verwendet die nativen JSON.stringify- und JSON.parse-APIs des Browsers vollständig clientseitig. Es gibt keinen Netzwerkaufruf, keine Analytik, kein Logging. Sicher zum Escapen von API-Token, internen Daten oder allem, was Sie nicht in ein serverseitiges Escape-Tool einfügen würden.