Does JSON Path Extractor work with large files?

Yes, since it runs in your browser, it can handle reasonably large inputs. Performance depends on your device's capabilities.

モバイルデバイスで使用できますか？

Yes, this tool works on any device with a modern browser including phones and tablets.

Does it support recursive search?

Yes. The .. operator searches recursively through all levels. For example, $..name finds all name keys anywhere in the JSON structure, regardless of nesting depth.

Are my JSON documents uploaded to a server?

No. Path evaluation runs entirely in your browser, pasted JSON never leaves your device. Safe for API responses, database exports, or configuration data containing sensitive values.

このツールはオフラインで動作しますか？

Yes, once the page has loaded, the tool works entirely in your browser without needing an internet connection. All processing is done locally with JavaScript.

JSONパス抽出

JSONを貼り付けて、$.store.book[0].titleのようなパス式を入力して値を抽出します。

JSON入力パス式

結果

JSONとパスを入力して、抽出をクリックしてください。

仕組み

JSONを貼り付け: 入力フィールドにJSONオブジェクトまたは配列を入力します。
JSONPath式を入力: $.store.book[*].authorまたは$.users[?(@.age > 18)]のようなパスを入力して、必要なデータを選択します。
抽出された結果を表示: 一致する値が出力パネルに瞬時に表示されます。結果をコピーするかエクスポートします。

なぜJSONPath抽出ツールを使うのか?

複雑なAPIレスポンスや深くネストされたJSONで作業する場合、特定の値を手動で抽出するのは遅く、エラーが発生しやすいです。JSONPathはJSONのクエリ言語です, XML用のXPathに似ています。簡潔なパス式を使用して、単一のネストされた値、配列のすべての要素、条件に一致するフィルター済みレコードなど、必要なデータを正確にターゲットにできます。このツールは、コードを書かずにJSONPath探索をインタラクティブにします。

機能

完全なJSONPathサポート: ドット記法、ブラケット記法、ワイルドカード(*)、再帰下降(..)、フィルター(?())、配列スライス。
ライブ評価: JSONPath式を入力するにつれて結果が更新されます。
フォーマットされた出力: 抽出された値は、きれいにフォーマットされたJSONとして表示されます。
複数の一致: JSONドキュメントからすべての一致するノードを返します。
エラーレポート: パス式が無効または一致が生成されない場合の明確なメッセージ。

よくある質問

JSONPathとは?

JSONPathはJSONドキュメントのクエリ言語で、XML用のXPathに類似しています。$.users[*].nameのようなパスは、users配列の各オブジェクトのnameフィールドを選択します。APIテスト、データ変換、JSON処理に広く使用されています。

条件によって配列要素をフィルターするには?

フィルター式を使用します: $.items[?(@.price < 50)]は価格が50未満のすべての項目を返します。@記号は、評価される現在の要素を参照します。

再帰検索をサポートしていますか?

はい。..演算子はすべてのレベルで再帰検索を実行します。例えば、$..nameは、ネストの深さに関係なく、JSON構造のどこにあるすべてのnameキーを見つけます。

ブログ投稿からRFC 9535へ:JSONPath標準への17年の道のり

Stefan Gössnerは2007年2月の単一のブログ投稿でJSONPathを提案し、XPathのアイデアをJSONに適応させました。彼はJavaScriptリファレンス実装を公開し、構文($ルート、ドットおよび角括弧の子オペレータ、再帰的下降のための..、ワイルドカードのための*、配列スライシングのための[start:end:step]、フィルタ式のための[?(...)])をスケッチし、より広いエコシステムが追随しました。実装は急増しました:JavaScript用jsonpath、Java用JsonPath、JSONPath隣接でも独自のjq(Stephen Dolan、2012)、Python用jsonpath-ng、より厳格なライバルのJMESPath(AWS、2014)。問題:すべての実装が漂流しました。フィルタ構文、再帰意味論、regexマッチング、ルート識別子、すべてライブラリ間で微妙に異なりました。Carsten Bormann et al.による2023年の比較研究は、同じ入力に対して41の異なるJSONPath実装をテストし、同じ式に対して41の異なる結果セットを取得しました。IETF JSONPathワーキンググループは2020年にこれを修正するために招集されました。RFC 9535「JSONPath: Query Expressions for JSON」は2024年2月に公開され、Gössnerのオリジナル投稿から17年後、JSONPathの最初の正式な標準となりました。RFC 9535は構文を成文化し、正規化された出力形式を定義し、文字列比較のためのUnicode正規化を要求し、適合性テストスイートを追加します。

JSONPath構文チートシート

実世界のクエリのほとんどをカバーする7つのオペレータ:

$ルート。すべてのパスはここから始まる。$単独でドキュメント全体を返す。
.name名前による子。 $.store.bookはstore内のbookフィールドを選択。スペースや特殊文字を含む名前は角括弧表記が必要:$['book title']。
[0]配列インデックス。 $.book[0]最初の要素。$.book[-1]最後の要素(RFC 9535追加)。
[start:end:step]配列スライス。Pythonスタイル:$.book[1:3]要素1と2、$.book[::2]1つおきの要素。stepは逆順のために負にできる。
*ワイルドカード。 $.book[*].titleすべての本のタイトル。プロパティワイルドカードとしても機能:$.store.* storeのすべての直接の子。
..再帰的下降。 $..titleは任意の深さのすべてのtitleフィールドを見つける。強力だが大きなドキュメントでは遅い。
[?(...)]フィルタ式。 $.book[?(@.price < 10)]価格が10未満のすべての本。@は「現在の要素」を意味する。RFC 9535はこれを?と名付け、比較オペレータ== != < <= > >=とブール&& ||を標準化する。このビューアのクイックモードはフィルタ式を評価しない、必要ならjsonpath-plusのようなライブラリを使う。

実際にJSONPathに手を伸ばす場所

kubectl出力フィルタリング。 kubectl get pods -o jsonpath='{.items[*].metadata.name}'はKubernetesに同梱され、日常的に使われるJSONPath消費者。Kubernetesフレーバーは先頭の$を落とし、そのエコシステムに住むなら注目に値するいくつかの癖がある。
PostmanまたはInsomniaを使ったAPIテスト。 pm.expect(jsonData.items[0].status).to.eql('active')のようなテストアサーションは通常、内部でJSONPathとして表現される。
Grafana / 可観測性ダッシュボード。JSONデータソースパネルはJSONPathを使ってメトリクスをクエリ;OpenTelemetryコレクタはスパン属性を抽出するためにJSONPath様の構文を使う。
クイックCLI抽出。ライブAPI探索のためにこのツールをcurl | jqと組み合わせる:ビューアでパスをプロトタイプし、それからシェルスクリプト用にjq構文に変換。(jqはドット表記を使うが厳密にはJSONPathではない。)
ETLとデータエンジニアリング。Airflow XComマッピング、dbtシードファイル、SQL JSONカラム抽出はすべて、ネストされたペイロードに手を伸ばすためにJSONPath様の式を使う。
トークン検査。デコードされたJWTを掘り下げる:発行者用$.payload.iss、クレームツリーのどこかで付与されたすべての役割用$..roles[*]。
Webhookハンドラ設計。ハンドラコードを書く前に、本物のウェブフックペイロードを貼り付け、システムが気にするフィールドを取り出すパスをプロトタイプする。上流サービスとのラウンドトリップを節約する。

噛むミス

実装ドリフト。あるライブラリで動くパスが別のライブラリでは異なる結果またはまったく結果を生まない可能性がある。RFC 9535以前は何も標準化されていなかった。今はライブラリのドキュメントで「RFC 9535準拠」を探す(IETFテストスイートはRFCと一緒に公開される)。
フィルタの引用符。 $.book[?(@.title=="Foo")]はRFC 9535ではフィルタ内に二重引用符を要求する;多くの古いライブラリは単一引用符'Foo'も受け入れる。それらを混在させることが本番環境での「構文エラー」の一般的な原因。
再帰的下降は貪欲。 $..*はドキュメント内のすべての値を返す、ネストされたオブジェクトと配列自体を含み、葉だけでない。大きなドキュメントでは数秒かかる可能性がある。まずパスを絞り、それから下降する。
整数 vs 文字列キー。JSONは文字列キーしか持たない、数値に見えても。$.users.123と$.users[123]はいくつかのライブラリで異なる意味:前者は文字通り"123"と名付けられたプロパティを探し、後者は配列インデックス123として解釈される可能性がある。
負のスライス。 $.book[-1:]はRFC 9535とほとんどの実装で「最後の要素」を意味するが、2024年以前は一部のライブラリが負のインデックスをエラーとして扱った。古いパーサをターゲットにする場合は、絶対インデックスを使う。
$を忘れる。先頭の$のないパスはRFC 9535で無効。一部の実装は.store.bookを短縮形として受け入れ、他は拒否する。常に$をプレフィックスにする。
パフォーマンス。10 MBドキュメントでの再帰的下降..はマッチごとにO(n)になる可能性がある。データウェアハウスのカラムまたはホットループの場合、$..で一度事前抽出し、結果をキャッシュし、それからキャッシュされた配列をウォークする。複雑なJSONPathをリクエストごとに実行することは決してしない。

JSONPath vs jq vs JMESPath vs JSON Pointer

JSONPath(RFC 9535)。アドホックなクエリと設定ファイルに最適。構文はXPathから馴染みがあり、標準は新鮮で、複数の言語ライブラリがサポート。
jq。パスクエリだけでなく、完全なデータ変換言語。map/filter/reduce、文字列関数、数学、フォーマットを追加。データを再形成する必要がある場合、単に抽出するだけでなく、より良い。ドット表記の独自の構文を持つが、フィルタレベルでJSONPathから分岐する。
JMESPath。AWS CLI(aws ec2 describe-instances --query "...")で使用される2014年の代替。JSONPathより厳格で機能的、初日から本物の文法を持ち、プロジェクションとパイプ演算子をサポート。Amazonのエコシステム外ではあまり一般的でない。
JSON Pointer(RFC 6901)。単一の値をアドレス指定するための2013年の標準:/store/book/0/title。ワイルドカード、フィルタ、または再帰はできない。JSON Patch(RFC 6902)、JSON Schema $ref、Kubernetesパッチ APIで使用される。クエリではなく、正確なアドレス指定が必要なときにこれを選ぶ。

その他のよくある質問

JSONPathはXPathと同じですか?

それに触発された、同じではない。XPathは1999年にW3CによってXML用に最終化され、JSONPathは2007年にGössnerによって同じアイデアをJSONに持ち込むためにスケッチされた。最大の違い:JSONPathは/の代わりに.と[]を使う、JSONPathにはXMLネームスペースや属性の概念がない、JSONPathはずっと後で標準化された(2024 vs 1999)、なので長年それは多くの非互換な実装を持つデファクト構文だった。

なぜ同じJSONPathが異なるツールで異なる結果を出すのか?

JSONPathがRFC 9535(2024年2月)まで標準化されていなかったから。それ以前、すべての実装はフィルタ構文、regexサポート、ルート識別子、エスケープルール、エッジケース(空の配列、欠落キー、フィルタでの型強制)について独自の選択をしていた。2023年のIETFワーキンググループ研究は同じ入力で41の実装をテストし、41の異なる結果セットを得た。RFC 9535は新しい及び更新されたライブラリのためにこれを修正する;古いライブラリは移行するまで分岐する。常に「RFC 9535適合」をライブラリが主張しているか確認する。

JSONPathでJSONを変更できますか、それとも読むだけですか?

RFC 9535はJSONPathを厳密にクエリ言語として定義する:ドキュメントから値を返し、変異しない。JSONを変更するには、JSON Patch(RFC 6902)を使う、これはJSON Pointerパスとadd/remove/replace/copy/move/test操作を使う。一部のライブラリは両方を組み合わせる(例えばJavaScriptのjsonpath-plusにはapply()変異拡張がある)が、それは標準JSONPathではない。

JSONPathはフィルタで正規表現をサポートしますか?

RFC 9535は2つのregex関数を追加した:match(node, regex)は文字列全体にマッチ、search(node, regex)は任意の部分文字列にマッチ。例:$.book[?(match(@.isbn, "^978-"))]。regexフレーバーはI-Regexp(RFC 9485、XMLスキーマregexのプロファイル)、PCREやJavaScript regexではない。古いライブラリはホスト言語のregexフレーバーを使用していたため、regexクエリは特に移植性がない。

このツールを使うときに自分のJSONはどこかに送信されますか?

いいえ。パス評価は完全にブラウザのJavaScriptエンジン内で実行されます。DevToolsでネットワークタブを開いてクエリを実行すると、評価中にアウトバウンドリクエストがゼロ表示されます。シークレット付きのAPI応答、PII付きのデータベースダンプ、または認証情報を含む設定ファイルに対して安全です。