JSON-Pfad-Extraktor

So funktioniert es

1. Fügen Sie Ihr JSON ein: Geben Sie ein beliebiges JSON-Objekt oder -Array in das Eingabefeld ein.
2. JSONPath-Ausdruck eingeben: Tippen Sie einen Pfad wie $.store.book[*].author oder $..name, um die benötigten Daten zu wählen.
3. Extrahierte Ergebnisse ansehen: Übereinstimmende Werte erscheinen sofort im Ausgabe-Bereich. Kopieren oder exportieren Sie das Ergebnis.

Warum den JSONPath-Extraktor nutzen?

Bei der Arbeit mit komplexen API-Antworten oder tief verschachteltem JSON ist das manuelle Extrahieren bestimmter Werte langsam und fehleranfällig. JSONPath ist die Abfragesprache für JSON, vergleichbar mit XPath für XML. Damit zielen Sie mit einem prägnanten Pfad-Ausdruck genau auf die Daten, die Sie brauchen, sei es ein einzelner verschachtelter Wert, alle Elemente in einem Array oder gefilterte Datensätze, die einer Bedingung entsprechen. Dieses Tool macht JSONPath-Erkundung interaktiv, ohne Code zu schreiben.

Funktionen

• JSONPath-Grundlagen: Punktnotation, Klammernotation, Wildcards (*), rekursiver Abstieg (..), Array-Indizes und die Eigenschaft .length. Filterausdrücke wie [?()] werden derzeit nicht unterstützt.
• Live-Auswertung: Die Ergebnisse aktualisieren sich, während Sie Ihren JSONPath-Ausdruck eingeben.
• Formatierte Ausgabe: Extrahierte Werte werden als hübsch formatiertes JSON angezeigt.
• Mehrere Treffer: Gibt alle übereinstimmenden Knoten aus dem JSON-Dokument zurück.
• Fehlerberichte: Klare Meldungen, wenn der Pfad-Ausdruck ungültig ist oder keine Treffer liefert.

Häufige Fragen

Was ist JSONPath?

JSONPath ist eine Abfragesprache für JSON-Dokumente, analog zu XPath für XML. Ein Pfad wie $.users[*].name wählt das Feld name aus jedem Objekt im users-Array. Sie wird häufig für API-Tests, Datentransformation und JSON-Verarbeitung eingesetzt.

Wie filtere ich Array-Elemente nach einer Bedingung?

Verwenden Sie einen Filterausdruck: $.items[?(@.price < 50)] gibt alle Elemente zurück, deren Preis unter 50 liegt. Das @-Symbol verweist auf das aktuell ausgewertete Element.

Wird rekursive Suche unterstützt?

Ja. Der Operator .. sucht rekursiv durch alle Ebenen. Beispielsweise findet $..name alle name-Schlüssel an beliebiger Stelle in der JSON-Struktur, unabhängig von der Verschachtelungstiefe.

Von einem Blogbeitrag zu RFC 9535: der 17-jährige Weg zu einem JSONPath-Standard

Stefan Gössner schlug JSONPath in einem einzigen Blogbeitrag im Februar 2007 vor und adaptierte die XPath-Idee für JSON. Er veröffentlichte eine JavaScript-Referenzimplementierung, skizzierte die Syntax (die Wurzel $, Punkt- und Klammer-Kind-Operatoren, .. für rekursiven Abstieg, * für Wildcard, [Start:Ende:Schritt] für Array-Slicing, [?(...)] für Filterausdrücke) und das weitere Ökosystem folgte. Implementierungen vermehrten sich: jsonpath für JavaScript, JsonPath für Java, jq (Stephen Dolan, 2012), das JSONPath-verwandt aber sein eigenes Ding ist, jsonpath-ng für Python, JMESPath (AWS, 2014) als strengerer Rivale. Das Problem: jede Implementierung driftete ab. Filtersyntax, Rekursionssemantik, Regex-Matching, Wurzel-Bezeichner, alle subtil unterschiedlich zwischen Bibliotheken. Eine Vergleichsstudie von 2023 von Carsten Bormann et al. testete 41 verschiedene JSONPath-Implementierungen gegen dieselbe Eingabe und erhielt 41 verschiedene Ergebnismengen für denselben Ausdruck. Die IETF JSONPath Working Group trat 2020 zusammen, um dies zu beheben. RFC 9535 «JSONPath: Query Expressions for JSON» wurde im Februar 2024 veröffentlicht und wurde der erste formale Standard für JSONPath, 17 Jahre nach Gössners Originalbeitrag. RFC 9535 kodifiziert die Syntax, definiert ein normalisiertes Ausgabeformat, erfordert Unicode-Normalisierung für String-Vergleiche und fügt eine Konformitätstest-Suite hinzu.

JSONPath-Syntax-Spickzettel

Die sieben Operatoren, die die meisten Real-World-Abfragen abdecken:

• $ Wurzel. Jeder Pfad beginnt hier. $ allein gibt das gesamte Dokument zurück.
• .name Kind nach Name. $.store.book wählt das book-Feld in store aus. Namen mit Leerzeichen oder Sonderzeichen benötigen Klammer-Notation: $['book title'].
• [0] Array-Index. $.book[0] erstes Element. $.book[-1] letztes Element (RFC 9535-Ergänzung).
• [Start:Ende:Schritt] Array-Slice. Python-Stil: $.book[1:3] Elemente 1 und 2, $.book[::2] jedes zweite Element. Schritt kann negativ sein zum Umkehren.
• * Wildcard. $.book[*].title der Titel jedes Buchs. Funktioniert auch als Eigenschafts-Wildcard: $.store.* alle direkten Kinder von store.
• .. rekursiver Abstieg. $..title findet jedes title-Feld in jeder Tiefe. Mächtig aber langsam bei großen Dokumenten.
• [?(...)] Filterausdruck. $.book[?(@.price < 10)] alle Bücher, deren Preis unter 10 ist. @ bedeutet «das aktuelle Element». RFC 9535 nennt dies ? und standardisiert die Vergleichsoperatoren == != < <= > >= plus Boolean && ||. Der Schnellmodus dieses Viewers wertet Filterausdrücke nicht aus, verwende eine Bibliothek wie jsonpath-plus, wenn du sie brauchst.

Wo du tatsächlich zu JSONPath greifst

• kubectl-Ausgabefilterung. kubectl get pods -o jsonpath='{.items[*].metadata.name}' ist in Kubernetes enthalten und ein täglich genutzter JSONPath-Konsument. Die Kubernetes-Variante lässt das führende $ weg und hat einige Eigenheiten, die zu beachten sind, wenn du in diesem Ökosystem lebst.
• API-Tests mit Postman oder Insomnia. Test-Assertions wie pm.expect(jsonData.items[0].status).to.eql('active') werden normalerweise unter der Haube als JSONPath ausgedrückt.
• Grafana / Observability-Dashboards. JSON-Datenquellen-Panels fragen Metriken mit JSONPath ab; OpenTelemetry-Sammler verwenden eine JSONPath-ähnliche Syntax, um Span-Attribute zu extrahieren.
• Schnelle CLI-Extraktion. Kombiniere dieses Tool mit curl | jq für Live-API-Exploration: prototypisiere den Pfad im Viewer, übersetze dann zu jq-Syntax für Shell-Skripte. (jq verwendet Punkt-Notation, ist aber nicht strikt JSONPath.)
• ETL und Data Engineering. Airflow XCom-Mappings, dbt Seed-Dateien und SQL JSON-Spaltenextraktion verwenden alle JSONPath-ähnliche Ausdrücke, um in verschachtelte Payloads zu greifen.
• Token-Inspektion. Tauche in ein dekodiertes JWT ein: $.payload.iss für den Aussteller, $..roles[*] für jede Rolle, die irgendwo im Claim-Baum gewährt wird.
• Webhook-Handler-Design. Bevor du den Handler-Code schreibst, füge eine echte Webhook-Payload ein und prototypisiere die Pfade, die die Felder herausziehen, die dein System interessieren. Spart einen Hin- und Rückweg zum Upstream-Service.

Fehler, die zubeißen

• Implementierungs-Drift. Ein Pfad, der in einer Bibliothek funktioniert, kann unterschiedliche Ergebnisse oder keine Ergebnisse in einer anderen produzieren. Vor RFC 9535 war nichts standardisiert. Suche nun nach «RFC 9535-konform» in der Doku deiner Bibliothek (die IETF-Testsuite wird mit der RFC veröffentlicht).
• Filter-Anführungszeichen. $.book[?(@.title=="Foo")] erfordert doppelte Anführungszeichen innerhalb des Filters in RFC 9535; viele ältere Bibliotheken akzeptieren auch einfache Anführungszeichen 'Foo'. Sie zu vermischen ist eine häufige Ursache für «Syntax-Fehler» in der Produktion.
• Rekursiver Abstieg ist gierig. $..* gibt jeden Wert im Dokument zurück, einschließlich verschachtelter Objekte und Arrays selbst, nicht nur Blätter. Bei großen Dokumenten kann dies Sekunden dauern. Verenge zuerst den Pfad, dann steige ab.
• Integer-vs-String-Schlüssel. JSON hat nur String-Schlüssel, auch wenn sie numerisch aussehen. $.users.123 und $.users[123] bedeuten in einigen Bibliotheken unterschiedliche Dinge: das erste sucht nach einer Eigenschaft, die wörtlich "123" heißt, das zweite kann als Array-Index 123 interpretiert werden.
• Negative Slices. $.book[-1:] bedeutet «das letzte Element» in RFC 9535 und den meisten Implementierungen, aber vor 2024 behandelten einige Bibliotheken negative Indizes als Fehler. Wenn du ältere Parser ansprichst, verwende absolute Indizes.
• Vergessen von $. Ein Pfad ohne führendes $ ist in RFC 9535 ungültig. Einige Implementierungen akzeptieren .store.book als Kurzform, andere lehnen es ab. Präfixiere immer mit $.
• Performance. Rekursiver Abstieg .. auf einem 10-MB-Dokument kann O(n) pro Match sein. Für Data-Warehouse-Spalten oder heiße Schleifen, extrahiere einmal vor mit $.., cache das Ergebnis, dann gehe das gecachte Array durch. Führe niemals einen komplexen JSONPath bei jeder Anfrage aus.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Am besten für Ad-hoc-Abfragen und Konfigurationsdateien. Die Syntax ist von XPath vertraut, der Standard ist frisch, mehrere Sprachbibliotheken unterstützen ihn.
• jq. Eine vollständige Datentransformations-Sprache, nicht nur eine Pfad-Abfrage. Fügt map/filter/reduce, String-Funktionen, Mathematik, Formatierung hinzu. Besser, wenn du Daten umformen musst, nicht nur extrahieren. Hat seine eigene Syntax mit Punkt-Notation, weicht aber auf Filter-Ebene von JSONPath ab.
• JMESPath. Eine Alternative von 2014, die von AWS CLI verwendet wird (aws ec2 describe-instances --query "..."). Strenger und funktionaler als JSONPath, hat eine echte Grammatik vom ersten Tag an, unterstützt Projektionen und Pipe-Operatoren. Weniger verbreitet außerhalb des Amazon-Ökosystems.
• JSON Pointer (RFC 6901). Ein Standard von 2013 zum Adressieren eines einzelnen Werts: /store/book/0/title. Kann keine Wildcards, Filter oder Rekursion. Verwendet von JSON Patch (RFC 6902), JSON Schema $ref und der Kubernetes-Patch-API. Wähle dies, wenn du exaktes Adressieren brauchst, nicht Abfragen.

Weitere häufig gestellte Fragen

Ist JSONPath dasselbe wie XPath?

Inspiriert davon, nicht identisch. XPath wurde 1999 vom W3C für XML finalisiert, JSONPath wurde 2007 von Gössner skizziert, um dieselbe Idee zu JSON zu bringen. Die größten Unterschiede: JSONPath verwendet . und [] statt /, JSONPath hat kein Konzept von XML-Namespaces oder -Attributen, JSONPath wurde viel später standardisiert (2024 vs 1999), also war es jahrelang eine De-facto-Syntax mit vielen inkompatiblen Implementierungen.

Warum liefert derselbe JSONPath unterschiedliche Ergebnisse in verschiedenen Tools?

Weil JSONPath bis RFC 9535 (Februar 2024) nicht standardisiert war. Davor traf jede Implementierung ihre eigenen Entscheidungen über Filtersyntax, Regex-Unterstützung, Wurzel-Bezeichner, Escape-Regeln und Edge Cases (leere Arrays, fehlende Schlüssel, Typ-Koerzion in Filtern). Eine Studie der IETF Working Group von 2023 testete 41 Implementierungen mit derselben Eingabe und erhielt 41 verschiedene Ergebnismengen. RFC 9535 behebt dies für neue und aktualisierte Bibliotheken; ältere Bibliotheken werden divergieren, bis sie migrieren. Überprüfe immer, ob deine Bibliothek «RFC 9535-Konformität» beansprucht.

Kann ich JSON mit JSONPath ändern oder nur lesen?

RFC 9535 definiert JSONPath strikt als Abfrage-Sprache: sie gibt Werte aus einem Dokument zurück, sie mutiert nicht. Um JSON zu ändern, verwende JSON Patch (RFC 6902), das JSON-Pointer-Pfade und add/remove/replace/copy/move/test-Operationen verwendet. Einige Bibliotheken kombinieren beides (z.B. jsonpath-plus in JavaScript hat eine apply()-Mutations-Erweiterung), aber das ist kein Standard-JSONPath.

Unterstützt JSONPath reguläre Ausdrücke in Filtern?

RFC 9535 fügte zwei Regex-Funktionen hinzu: match(node, regex) entspricht der gesamten Zeichenfolge, search(node, regex) entspricht einem beliebigen Teilstring. Beispiel: $.book[?(match(@.isbn, "^978-"))]. Der Regex-Geschmack ist I-Regexp (RFC 9485, ein Profil von XML-Schema-Regex), nicht PCRE oder JavaScript-Regex. Ältere Bibliotheken verwendeten den Regex-Geschmack ihrer Host-Sprache, was Regex-Abfragen besonders nicht-portabel macht.

Wird mein JSON irgendwohin gesendet, wenn ich dieses Tool verwende?

Nein. Die Pfadauswertung läuft vollständig in der JavaScript-Engine deines Browsers. Öffne den Netzwerk-Tab in DevTools und führe eine Abfrage aus, du wirst null ausgehende Anfragen während der Auswertung sehen. Sicher für API-Antworten mit Geheimnissen, Datenbank-Dumps mit PII oder Konfigurationsdateien mit Anmeldedaten.