Internet Engineering Task Force (IETF) S. Gössner, Ed.
Request for Comments: 9535 Fachhochschule Dortmund
Category: Standards Track G. Normington, Ed.
ISSN: 2070-1721
C. Bormann, Ed.
Universität Bremen TZI
February 2024
JSONPath defines a string syntax for selecting and extracting JSON (RFC 8259) values from within a given JSON value.
JSonPathは、特定のJSON値内からJSON（RFC 8259）値を選択および抽出するための文字列構文を定義します。
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9535.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9535で取得できます。
Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2024 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
1.1. Terminology
1.1.1. JSON Values as Trees of Nodes
1.2. History
1.3. JSON Values
1.4. Overview of JSONPath Expressions
1.4.1. Identifiers
1.4.2. Segments
1.4.3. Selectors
1.4.4. Summary
1.5. JSONPath Examples
2. JSONPath Syntax and Semantics
2.1. Overview
2.1.1. Syntax
2.1.2. Semantics
2.1.3. Example
2.2. Root Identifier
2.2.1. Syntax
2.2.2. Semantics
2.2.3. Examples
2.3. Selectors
2.3.1. Name Selector
2.3.1.1. Syntax
2.3.1.2. Semantics
2.3.1.3. Examples
2.3.2. Wildcard Selector
2.3.2.1. Syntax
2.3.2.2. Semantics
2.3.2.3. Examples
2.3.3. Index Selector
2.3.3.1. Syntax
2.3.3.2. Semantics
2.3.3.3. Examples
2.3.4. Array Slice Selector
2.3.4.1. Syntax
2.3.4.2. Semantics
2.3.4.3. Examples
2.3.5. Filter Selector
2.3.5.1. Syntax
2.3.5.2. Semantics
2.3.5.3. Examples
2.4. Function Extensions
2.4.1. Type System for Function Expressions
2.4.2. Type Conversion
2.4.3. Well-Typedness of Function Expressions
2.4.4. length() Function Extension
2.4.5. count() Function Extension
2.4.6. match() Function Extension
2.4.7. search() Function Extension
2.4.8. value() Function Extension
2.4.9. Examples
2.5. Segments
2.5.1. Child Segment
2.5.1.1. Syntax
2.5.1.2. Semantics
2.5.1.3. Examples
2.5.2. Descendant Segment
2.5.2.1. Syntax
2.5.2.2. Semantics
2.5.2.3. Examples
2.6. Semantics of null
2.6.1. Examples
2.7. Normalized Paths
2.7.1. Examples
3. IANA Considerations
3.1. Registration of Media Type application/jsonpath
3.2. Function Extensions Subregistry
4. Security Considerations
4.1. Attack Vectors on JSONPath Implementations
4.2. Attack Vectors on How JSONPath Queries Are Formed
4.3. Attacks on Security Mechanisms That Employ JSONPath
5. References
5.1. Normative References
5.2. Informative References
Appendix A. Collected ABNF Grammars
Appendix B. Inspired by XPath
B.1. JSONPath and XPath
Appendix C. JSON Pointer
Acknowledgements
Contributors
Authors' Addresses
JSON [RFC8259] is a popular representation format for structured data values. JSONPath defines a string syntax for selecting and extracting JSON values from within a given JSON value.
JSON [RFC8259]は、構造化されたデータ値に人気のある表現形式です。JSonPathは、特定のJSON値内からJSON値を選択および抽出するための文字列構文を定義します。
In relation to JSON Pointer [RFC6901], JSONPath is not intended as a replacement but as a more powerful companion. See Appendix C.
JSON Pointer [RFC6901]に関連して、JSonPathは代替品としてではなく、より強力な仲間として意図されています。付録Cを参照してください
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The grammatical rules in this document are to be interpreted as ABNF, as described in [RFC5234]. ABNF terminal values in this document define Unicode scalar values rather than their UTF-8 encoding. For example, the Unicode PLACE OF INTEREST SIGN (U+2318) would be defined in ABNF as %x2318.
[RFC5234]で説明されているように、このドキュメントの文法規則はABNFと解釈されます。このドキュメントのABNF端子値は、UTF-8エンコーディングではなく、Unicodeスカラー値を定義します。たとえば、Unicode Place of Renticing Sign（U 2318）は、ABNFで％x2318として定義されます。
Functions are referred to using the function name followed by a pair of parentheses, as in fname().
関数は、fname（）のように、関数名を使用した後に括弧のペアを使用することに言及されます。
The terminology of [RFC8259] applies except where clarified below. The terms "primitive" and "structured" are used to group different kinds of values as in Section 1 of [RFC8259]. JSON objects and arrays are structured; all other values are primitive. Definitions for "object", "array", "number", and "string" remain unchanged. Importantly, "object" and "array" in particular do not take on a generic meaning, such as they would in a general programming context.
[RFC8259]の用語は、以下を明確にした場合を除き、適用されます。[RFC8259]のセクション1のように、「原始」および「構造化」という用語は、さまざまな種類の値をグループ化するために使用されます。JSONオブジェクトと配列は構造化されています。他のすべての値は原始的です。「オブジェクト」、「配列」、「番号」、および「文字列」の定義は変更されません。重要なことに、「オブジェクト」と「配列」は、一般的なプログラミングのコンテキストでは、一般的な意味を引き受けません。
The terminology of [RFC9485] applies.
[RFC9485]の用語が適用されます。
Additional terms used in this document are defined below.
このドキュメントで使用される追加の用語は、以下に定義されています。
Value:
価値：
As per [RFC8259], a data item conforming to the generic data model of JSON, i.e., primitive data (numbers, text strings, and the special values null, true, and false), or structured data (JSON objects and arrays). [RFC8259] focuses on the textual representation of JSON values and does not fully define the value abstraction assumed here.
[RFC8259]によると、JSONの汎用データモデル、つまりプリミティブデータ（数字、テキスト文字列、特別な値null、true、and false）、または構造化データ（JSONオブジェクトと配列）に準拠するデータ項目。[RFC8259]は、JSON値のテキスト表現に焦点を当てており、ここで想定される値の抽象化を完全に定義していません。
Member:
メンバー：
A name/value pair in an object. (A member is not itself a value.)
オブジェクト内の名前/値ペア。（メンバー自体は価値ではありません。）
Name:
名前：
The name (a string) in a name/value pair constituting a member. This is also used in [RFC8259], but that specification does not formally define it. It is included here for completeness.
メンバーを構成する名前/値ペアの名前（文字列）。これは[RFC8259]でも使用されますが、その仕様では正式に定義されていません。完全性のためにここに含まれています。
Element:
要素：
A value in a JSON array.
JSONアレイの値。
Index:
索引：
An integer that identifies a specific element in an array.
配列内の特定の要素を識別する整数。
Query:
クエリ：
Short name for a JSONPath expression.
jsonpath式の短い名前。
Query Argument:
クエリ引数：
Short name for the value a JSONPath expression is applied to.
jsonpath式が適用される値の短い名前。
Location:
位置：
The position of a value within the query argument. This can be thought of as a sequence of names and indexes navigating to the value through the objects and arrays in the query argument, with the empty sequence indicating the query argument itself. A location can be represented as a Normalized Path (defined below).
クエリ引数内の値の位置。これは、クエリ引数のオブジェクトと配列を介して値にナビゲートする名前とインデックスのシーケンスと考えることができ、空のシーケンスはクエリ引数自体を示します。場所は、正規化されたパスとして表すことができます（以下に定義）。
Node:
ノード：
The pair of a value along with its location within the query argument.
値のペアとクエリ引数内の位置。
Root Node:
ルートノード：
The unique node whose value is the entire query argument.
値がクエリ引数全体である一意のノード。
Root Node Identifier:
ルートノード識別子：
The expression $, which refers to the root node of the query argument.
クエリ引数のルートノードを指します。
Current Node Identifier:
現在のノード識別子：
The expression @, which refers to the current node in the context of the evaluation of a filter expression (described later).
式 @は、フィルター式の評価のコンテキストでの現在のノードを指します（後述）。
Children (of a node):
子供（ノードの）：
If the node is an array, the nodes of its elements; if the node is an object, the nodes of its member values. If the node is neither an array nor an object, it has no children.
ノードが配列の場合、その要素のノード。ノードがオブジェクトの場合、メンバー値のノード。ノードが配列でもオブジェクトでもない場合、子供はいません。
Descendants (of a node):
（ノードの）子孫：
The children of the node, together with the children of its children, and so forth recursively. More formally, the "descendants" relation between nodes is the transitive closure of the "children" relation.
ノードの子供たちは、子供の子供たちと一緒に、そのようなことを再帰的に。より正式には、ノード間の「子孫」の関係は、「子供」関係の推移的な閉鎖です。
Depth (of a descendant node within a value):
深さ（値内の子孫ノードの）：
The number of ancestors of the node within the value. The root node of the value has depth zero, the children of the root node have depth one, their children have depth two, and so forth.
値内のノードの祖先の数。値のルートノードには深さゼロ、ルートノードの子供には深さ1、子供の深さ2などがあります。
Nodelist:
ノデリスト：
A list of nodes. While a nodelist can be represented in JSON, e.g., as an array, this document does not require or assume any particular representation.
ノードのリスト。ノデリストはJSONで、たとえば配列として表現できますが、このドキュメントでは特定の表現を必要としないか仮定しません。
Parameter:
パラメーター：
Formal parameter (of a function) that can take a function argument (an actual parameter) in a function expression.
関数式に関数引数（実際のパラメーター）を取ることができる正式なパラメーター（関数の）。
Normalized Path:
正規化されたパス：
A form of JSONPath expression that identifies a node in a value by providing a query that results in exactly that node. Each node in a query argument is identified by exactly one Normalized Path (we say that the Normalized Path is "unique" for that node), and to be a Normalized Path for a specific query argument, the Normalized Path needs to identify exactly one node. This is similar to, but syntactically different from, a JSON Pointer [RFC6901]. Note: This definition is based on the syntactical definition in Section 2.7; JSONPath expressions that identify a node in a value but do not conform to that syntax are not Normalized Paths.
正確にそのノードになるクエリを提供することにより、値のノードを識別するJSONPATH式の形式。クエリ引数内の各ノードは、正確に1つの正規化されたパスで識別されます（正規化されたパスはそのノードの「一意」であると言います）。。これは、JSONポインター[RFC6901]に似ていますが、構文的に異なります。注：この定義は、セクション2.7の構文定義に基づいています。値のノードを識別するが、その構文に準拠しないJSONPATH式は正規化されたパスではありません。
Unicode Scalar Value:
ユニコードスカラー値：
Any Unicode [UNICODE] code point except high-surrogate and low-surrogate code points (in other words, integers in the inclusive base 16 ranges, either 0 to D7FF or E000 to 10FFFF). JSONPath queries are sequences of Unicode scalar values.
任意のユニコード[Unicode]コードポイントは、高スロゲートおよび低スロゲートコードポイントを除きます（つまり、包括的ベース16範囲の整数、0〜D7FFまたはE000〜10FFFF）。JSonPathクエリは、Unicodeスカラー値のシーケンスです。
Segment:
セグメント：
One of the constructs that selects children ([<selectors>]) or descendants (..[<selectors>]) of an input value.
入力値の子供（[<electors>]）または子孫（.. [<electors>]）を選択する構造の1つ。
Selector:
セレクタ：
A single item within a segment that takes the input value and produces a nodelist consisting of child nodes of the input value.
入力値を取得し、入力値の子ノードで構成されるノデリストを生成するセグメント内の単一のアイテム。
Singular Query:
特異クエリ：
A JSONPath expression built from segments that have been syntactically restricted in a certain way (Section 2.3.5.1) so that, regardless of the input value, the expression produces a nodelist containing at most one node. Note: JSONPath expressions that always produce a singular nodelist but do not conform to the syntax in Section 2.3.5.1 are not singular queries.
特定の方法で構文的に制限されているセグメント（セクション2.3.5.1）から構築されたJSONPATH式は、入力値に関係なく、最大1つのノードを含むノデリストを生成します。注：常に特異なノデリストを生成しますが、セクション2.3.5.1の構文に適合しないJsonPath式は、特異なクエリではありません。
This document models the query argument as a tree of JSON values, each with its own node. A node is either the root node or one of its descendants.
このドキュメントは、クエリ引数をJSON値のツリーとしてモデル化し、それぞれに独自のノードを備えています。ノードは、ルートノードまたはその子孫のいずれかです。
This document models the result of applying a query to the query argument as a nodelist (a list of nodes).
このドキュメントは、クエリ引数にノデリスト（ノードのリスト）としてクエリ引数にクエリを適用した結果をモデル化します。
Nodes are the selectable parts of the query argument. The only parts of an object that can be selected by a query are the member values. Member names and members (name/value pairs) cannot be selected. Thus, member values have nodes, but members and member names do not. Similarly, member values are children of an object, but members and member names are not.
ノードは、クエリ引数の選択可能な部分です。クエリで選択できるオブジェクトの唯一の部分は、メンバー値です。メンバー名とメンバー（名前/値ペア）を選択できません。したがって、メンバー値にはノードがありますが、メンバーとメンバー名はありません。同様に、メンバー値はオブジェクトの子供ですが、メンバーとメンバー名はそうではありません。
This document is based on Stefan Gössner's popular JSONPath proposal (dated 2007-02-21) [JSONPath-orig], builds on the experience from the widespread deployment of its implementations, and provides a normative specification for it.
このドキュメントは、StefanGösnerの人気のJsonPath Proposal（2007-02-21）[JsonPath-Orig]に基づいており、その実装の広範な展開からの経験に基づいており、その規範的な仕様を提供します。
Appendix B describes how JSONPath was inspired by XML's XPath [XPath].
付録Bでは、XMLのXpath [XPath]にJsonPathがどのように触発されたかについて説明しています。
JSONPath was intended as a lightweight companion to JSON implementations in programming languages such as PHP and JavaScript, so instead of defining its own expression language, like XPath did, JSONPath delegated parts of a query to the underlying runtime, e.g., JavaScript's eval() function. As JSONPath was implemented in more environments, JSONPath expressions became decreasingly portable. For example, regular expression processing was often delegated to a convenient regular expression engine.
JSONPATHは、PHPやJavaScriptなどのプログラミング言語でのJSON実装の軽量コンパニオンとして意図されていたため、Xpathがそうであるように独自の表現言語を定義する代わりに、JSONPATHは基礎となるランタイムにクエリの一部を委任しました。。JSONPATHがより多くの環境で実装されたため、JSONPATHの表現は脱出するようになりました。たとえば、正規表現処理は、しばしば便利な正規表現エンジンに委任されました。
This document aims to remove such implementation-specific dependencies and serve as a common JSONPath specification that can be used across programming languages and environments. This means that backwards compatibility is not always achieved; a design principle of this document is to go with a "consensus" between implementations even if it is rough, as long as that does not jeopardize the objective of obtaining a usable, stable JSON query language.
このドキュメントは、このような実装固有の依存関係を削除し、プログラミング言語や環境で使用できる一般的なJSONPATH仕様として機能することを目的としています。これは、後方互換性が常に達成されるとは限らないことを意味します。このドキュメントの設計原則は、使用可能で安定したJSONクエリ言語を取得する目的を危険にさらす限り、ラフであっても、実装間で「コンセンサス」を使用することです。
The term _JSONPath_ was chosen because of the XPath inspiration and also because the outcome of a query consists of _paths_ identifying nodes in the JSON query argument.
_jsonpath_という用語は、Xpathのインスピレーションのために選択されました。また、クエリの結果は、JSONクエリ引数の_Paths_識別ノードで構成されているためです。
The JSON value a JSONPath query is applied to is, by definition, a valid JSON value. A JSON value is often constructed by parsing a JSON text.
JSON値は、定義上、有効なJSON値です。JSON値は、JSONテキストを解析することにより多くの場合構築されます。
The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this document. Sections 4 and 8 of [RFC8259] identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, as they may cause unpredictable behavior. This document does not attempt to define predictable behavior for JSONPath queries in these situations.
JSONテキストのJSON値への解析と、JSONテキストが有効なJSONを表していない場合は、このドキュメントで定義されていません。[RFC8259]のセクション4と8は、JSONテキストの文法に準拠する可能性のある特定の状況を特定しますが、予測不可能な動作を引き起こす可能性があるため、JSONの相互運用可能な使用ではありません。このドキュメントは、これらの状況でJSONPATHクエリの予測可能な動作を定義しようとはしません。
Specifically, the "Semantics" subsections of Sections 2.3.1, 2.3.2, 2.3.5, and 2.5.2 describe behavior that becomes unpredictable when the JSON value for one of the objects under consideration was constructed out of JSON text that exhibits multiple members for a single object that share the same member name ("duplicate names"; see Section 4 of [RFC8259]). Also, when selecting a child by name (Section 2.3.1) and comparing strings (Section 2.3.5.2.2), it is assumed these strings are sequences of Unicode scalar values; the behavior becomes unpredictable if they are not (Section 8.2 of [RFC8259]).
具体的には、セクション2.3.1、2.3.2、2.3.5、および2.5.2の「セマンティクス」サブセクションは、検討中のオブジェクトの1つのJSON値が複数を示すJSONテキストから構築されたときに予測不可能になる動作を説明します同じメンバー名を共有する単一のオブジェクトのメンバー（「Duplicate Name」; [RFC8259]のセクション4を参照）。また、名前で子供を選択し（セクション2.3.1）、文字列を比較する場合（セクション2.3.5.2.2）、これらの文字列はユニコードスカラー値のシーケンスであると想定されています。動作がそうでない場合、動作は予測不可能になります（[RFC8259]のセクション8.2）。
A JSONPath expression is applied to a JSON value, known as the query argument. The output is a nodelist.
JSONPATH式は、クエリ引数として知られるJSON値に適用されます。出力はノデリストです。
A JSONPath expression consists of an identifier followed by a series of zero or more segments, each of which contains one or more selectors.
JSONPATH式は、識別子で構成され、その後に一連のゼロ以上のセグメントがあり、それぞれに1つ以上のセレクターが含まれています。
The root node identifier $ refers to the root node of the query argument, i.e., to the argument as a whole.
ルートノード識別子$は、クエリ引数のルートノード、つまり引数全体を指します。
The current node identifier @ refers to the current node in the context of the evaluation of a filter expression (Section 2.3.5).
現在のノード識別子 @は、フィルター式の評価のコンテキストでの現在のノードを指します（セクション2.3.5）。
Segments select children ([<selectors>]) or descendants (..[<selectors>]) of an input value.
セグメントは、入力値の子供（[<electors>]）または子孫（.. [<selectors>]）を選択します。
Segments can use _bracket notation_, for example:
セグメントは_Bracket Notation_を使用できます。
$['store']['book'][0]['title']
or the more compact _dot notation_, for example:
または、よりコンパクトな_DOT NOTATION_など：
$.store.book[0].title
Bracket notation contains one or more (comma-separated) selectors of any kind. Selectors are detailed in the next section.
ブラケット表記には、あらゆる種類の1つまたは複数の（コンマ分離された）セレクターが含まれています。セレクターの詳細については、次のセクションで詳しく説明します。
A JSONPath expression may use a combination of bracket and dot notations.
JSONPATH式は、ブラケットとドット表記の組み合わせを使用する場合があります。
This document treats the bracket notations as canonical and defines the shorthand dot notation in terms of bracket notation. Examples and descriptions use shorthand where convenient.
このドキュメントは、ブラケット表記を正規として扱い、ブラケット表記の観点から略記のドット表記を定義します。例と説明は、便利な速記を使用します。
A name selector, e.g., 'name', selects a named child of an object.
名前セレクター、例えば「名前」は、オブジェクトの名前の子を選択します。
An index selector, e.g., 3, selects an indexed child of an array.
インデックスセレクター、例えば3は、配列のインデックス付き子を選択します。
In the expression [*], a wildcard * (Section 2.3.2) selects all children of a node, and in the expression ..[*], it selects all descendants of a node.
式[*]では、ワイルドカード*（セクション2.3.2）は、ノードのすべての子供を選択し、式.. [*]では、ノードのすべての子孫を選択します。
An array slice start:end:step (Section 2.3.4) selects a series of elements from an array, giving a start position, an end position, and an optional step value that moves the position from the start to the end.
アレイスライスの開始：終了：ステップ（セクション2.3.4）は、アレイから一連の要素を選択し、開始位置、エンド位置、および最初から最後まで位置を移動するオプションのステップ値を与えます。
A filter expression ?<logical-expr> selects certain children of an object or array, as in:
フィルター式？<Logical-Expr>は、次のようにオブジェクトまたは配列の特定の子供を選択します。
$.store.book[?@.price < 10].title
Table 1 provides a brief overview of JSONPath syntax.
表1に、JSonPath構文の簡単な概要を示します。
+==================+================================================+
| Syntax Element | Description |
+==================+================================================+
| $ | root node identifier (Section 2.2) |
+------------------+------------------------------------------------+
| @ | current node identifier (Section 2.3.5) |
| | (valid only within filter selectors) |
+------------------+------------------------------------------------+
| [<selectors>] | child segment (Section 2.5.1): selects |
| | zero or more children of a node |
+------------------+------------------------------------------------+
| .name | shorthand for ['name'] |
+------------------+------------------------------------------------+
| .* | shorthand for [*] |
+------------------+------------------------------------------------+
| ..[<selectors>] | descendant segment (Section 2.5.2): |
| | selects zero or more descendants of a node |
+------------------+------------------------------------------------+
| ..name | shorthand for ..['name'] |
+------------------+------------------------------------------------+
| ..* | shorthand for ..[*] |
+------------------+------------------------------------------------+
| 'name' | name selector (Section 2.3.1): selects a |
| | named child of an object |
+------------------+------------------------------------------------+
| * | wildcard selector (Section 2.3.2): selects |
| | all children of a node |
+------------------+------------------------------------------------+
| 3 | index selector (Section 2.3.3): selects an |
| | indexed child of an array (from 0) |
+------------------+------------------------------------------------+
| 0:100:5 | array slice selector (Section 2.3.4): |
| | start:end:step for arrays |
+------------------+------------------------------------------------+
| ?<logical-expr> | filter selector (Section 2.3.5): selects |
| | particular children using a logical |
| | expression |
+------------------+------------------------------------------------+
| length(@.foo) | function extension (Section 2.4): invokes |
| | a function in a filter expression |
+------------------+------------------------------------------------+
Table 1: Overview of JSONPath Syntax
表1：JSonPath構文の概要
This section is informative. It provides examples of JSONPath expressions.
このセクションは有益です。JSonPathの表現の例を提供します。
The examples are based on the simple JSON value shown in Figure 1, representing a bookstore (which also has a bicycle).
例は、図1に示す単純なJSON値に基づいており、書店（自転車もあります）を表しています。
{ "store": {
"book": [
{ "category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
},
{ "category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
},
{ "category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99
},
{ "category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
}
],
"bicycle": {
"color": "red",
"price": 399
}
}
}
Figure 1: Example JSON Value
図1：JSON値の例
Table 2 shows some JSONPath queries that might be applied to this example and their intended results.
表2は、この例に適用される可能性のあるJsonPathクエリと意図した結果を示しています。
+========================+=======================================+
| JSONPath | Intended Result |
+========================+=======================================+
| $.store.book[*].author | the authors of all books in the store |
+------------------------+---------------------------------------+
| $..author | all authors |
+------------------------+---------------------------------------+
| $.store.* | all things in the store, which are |
| | some books and a red bicycle |
+------------------------+---------------------------------------+
| $.store..price | the prices of everything in the store |
+------------------------+---------------------------------------+
| $..book[2] | the third book |
+------------------------+---------------------------------------+
| $..book[2].author | the third book's author |
+------------------------+---------------------------------------+
| $..book[2].publisher | empty result: the third book does not |
| | have a "publisher" member |
+------------------------+---------------------------------------+
| $..book[-1] | the last book in order |
+------------------------+---------------------------------------+
| $..book[0,1] | the first two books |
| $..book[:2] | |
+------------------------+---------------------------------------+
| $..book[?@.isbn] | all books with an ISBN number |
+------------------------+---------------------------------------+
| $..book[?@.price<10] | all books cheaper than 10 |
+------------------------+---------------------------------------+
| $..* | all member values and array elements |
| | contained in the input value |
+------------------------+---------------------------------------+
Table 2: Example JSONPath Expressions and Their Intended Results When Applied to the Example JSON Value
表2：例JSONPATH式とその意図した結果の例JSON値に適用した場合の結果
A JSONPath _expression_ is a string that, when applied to a JSON value (the _query argument_), selects zero or more nodes of the argument and outputs these nodes as a nodelist.
jsonpath _expression_は、json値（_ query argument_）に適用されると、引数のゼロ以上のノードを選択し、これらのノードをノデリストとして出力する文字列です。
A query MUST be encoded using UTF-8. The grammar for queries given in this document assumes that its UTF-8 form is first decoded into Unicode scalar values as described in [RFC3629]; implementation approaches that lead to an equivalent result are possible.
UTF-8を使用してクエリをエンコードする必要があります。このドキュメントに記載されているクエリの文法は、[RFC3629]で説明されているように、そのUTF-8フォームが最初にユニコードスカラー値にデコードされることを前提としています。同等の結果につながる実装アプローチが可能です。
A string to be used as a JSONPath query needs to be _well-formed_ and _valid_. A string is a well-formed JSONPath query if it conforms to the ABNF syntax in this document. A well-formed JSONPath query is valid if it also fulfills both semantic requirements posed by this document, which are as follows:
jsonpathクエリとして使用する文字列は、_well-formed_および_valid_である必要があります。文字列は、このドキュメントのABNF構文に準拠している場合、よく形成されたJSonPathクエリです。適切に形成されたJSONPATHクエリは、このドキュメントによって提起されたセマンティック要件の両方を満たしている場合に有効です。これは次のとおりです。
1. Integer numbers in the JSONPath query that are relevant to the JSONPath processing (e.g., index values and steps) MUST be within the range of exact integer values defined in Internet JSON (I-JSON) (see Section 2.2 of [RFC7493]), namely within the interval [-(2^53)+1, (2^53)-1].
1. JSONPATH処理に関連するJSONPATHクエリの整数数（インデックス値と手順など）は、インターネットJSON（I-JSON）で定義された正確な整数値の範囲内でなければなりません（[RFC7493]のセクション2.2を参照）、つまり間隔内[ - （2^53）1、（2^53）-1]。
2. Uses of function extensions MUST be _well-typed_, as described in Section 2.4.3.
2. セクション2.4.3で説明されているように、関数拡張機能の使用は_Well-Tyed_でなければなりません。
A JSONPath implementation MUST raise an error for any query that is not well-formed and valid. The well-formedness and the validity of JSONPath queries are independent of the JSON value the query is applied to. No further errors relating to the well-formedness and the validity of a JSONPath query can be raised during application of the query to a value. This clearly separates well-formedness/ validity errors in the query from mismatches that may actually stem from flaws in the data.
JSONPATHの実装は、十分に形成されておらず有効ではないクエリのエラーを提起する必要があります。JSONPATHクエリの整形式と有効性は、クエリが適用されるJSON値とは無関係です。クエリを値に適用する際に、JSONPATHクエリの識別性と妥当性に関するさらなるエラーは発生することはできません。これにより、クエリの整形式/妥当性エラーは、実際にデータの欠陥に起因する可能性のあるミスマッチから明確に分離されます。
Mismatches between the structure expected by a valid query and the structure found in the data can lead to empty query results, which may be unexpected and indicate bugs in either. JSONPath implementations might therefore want to provide diagnostics to the application developer that aid in finding the cause of empty results.
有効なクエリで予想される構造とデータにある構造の間の不一致は、空のクエリの結果につながる可能性があります。したがって、JSonPathの実装は、空の結果の原因を見つけるのに役立つアプリケーション開発者に診断を提供したいと思うかもしれません。
Obviously, an implementation can still fail when executing a JSONPath query, e.g., because of resource depletion, but this is not modeled in this document. However, the implementation MUST NOT silently malfunction. Specifically, if a valid JSONPath query is evaluated against a structured value whose size is too large to process the query correctly (for instance, requiring the processing of numbers that fall outside the range of exact values), the implementation MUST provide an indication of overflow.
明らかに、JSONPathクエリを実行すると実装が失敗する可能性があります。たとえば、リソースの枯渇のためですが、これはこのドキュメントではモデル化されていません。ただし、実装は静かに誤動作してはなりません。具体的には、クエリを正しく処理するにはサイズが大きすぎる構造的な値に対して有効なJSONPATHクエリが正しく処理できない構造化された値に対して評価される場合（たとえば、正確な値の範囲外にある数値の処理が必要です）、実装はオーバーフローの兆候を提供する必要があります。
(Readers familiar with the HTTP error model may be reminded of 400 type errors when pondering well-formedness and validity, and they may recognize resource depletion and related errors as comparable to 500 type errors.)
（HTTPエラーモデルに精通している読者は、整形式と有効性を熟考するときに400型のエラーを思い出させる可能性があり、リソースの枯渇と関連するエラーが500型エラーに匹敵するものとして認識される場合があります。）
Syntactically, a JSONPath query consists of a root identifier ($), which stands for a nodelist that contains the root node of the query argument, followed by a possibly empty sequence of _segments_.
構文的に、JSONPATHクエリは、クエリ引数のルートノードを含むノデリストを表すルート識別子（$）で構成され、その後に_segments_の空のシーケンスが続きます。
jsonpath-query = root-identifier segments
segments = *(S segment)
B = %x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ; Carriage return
S = *B ; optional blank space
The syntax and semantics of segments are defined in Section 2.5.
セグメントの構文とセマンティクスは、セクション2.5で定義されています。
In this document, the semantics of a JSONPath query define the required results and do not prescribe the internal workings of an implementation. This document may describe semantics in a procedural step-by-step fashion; however, such descriptions are normative only in the sense that any implementation MUST produce an identical result but not in the sense that implementers are required to use the same algorithms.
このドキュメントでは、JSONPATHクエリのセマンティクスが必要な結果を定義し、実装の内部作業を規定していません。このドキュメントは、セマンティクスを手続き的な段階的な方法で説明する場合があります。ただし、そのような説明は、実装が同じアルゴリズムを使用する必要があるという意味では、実装が同一の結果を生成しなければならないという意味でのみ規範的です。
The semantics are that a valid query is executed against a value (the _query argument_) and produces a nodelist (i.e., a list of zero or more nodes of the value).
セマンティクスは、有効なクエリが値（_ query argument_）に対して実行され、ノデリスト（つまり、値のゼロ以上のノードのリスト）を生成することです。
The query is a root identifier followed by a sequence of zero or more segments, each of which is applied to the result of the previous root identifier or segment and provides input to the next segment. These results and inputs take the form of nodelists.
クエリはルート識別子であり、その後にゼロ以上のセグメントのシーケンスが続き、それぞれが前のルート識別子またはセグメントの結果に適用され、次のセグメントへの入力を提供します。これらの結果と入力は、ノデリストの形を取ります。
The nodelist resulting from the root identifier contains a single node (the query argument). The nodelist resulting from the last segment is presented as the result of the query. Depending on the specific API, it might be presented as an array of the JSON values at the nodes, an array of Normalized Paths referencing the nodes, or both -- or some other representation as desired by the implementation. Note: An empty nodelist is a valid query result.
ルート識別子から生じるノデリストには、単一のノード（クエリ引数）が含まれています。最後のセグメントから生じるノデリストは、クエリの結果として提示されます。特定のAPIに応じて、ノードでのJSON値の配列、ノードを参照する正規化されたパスの配列、または実装が望むその他の表現として表示される場合があります。注：空のノデリストは有効なクエリ結果です。
A segment operates on each of the nodes in its input nodelist in turn, and the resultant nodelists are concatenated in the order of the input nodelist they were derived from to produce the result of the segment. A node may be selected more than once and appears that number of times in the nodelist. Duplicate nodes are not removed.
セグメントは、入力ノデリストの各ノードで動作し、結果のノデリストは、セグメントの結果を生成するために派生した入力ノデリストの順に連結されます。ノードは複数回選択でき、ノデリストにその数回表示されます。重複したノードは削除されません。
A syntactically valid segment MUST NOT produce errors when executing the query. This means that some operations that might be considered erroneous, such as using an index lying outside the range of an array, simply result in fewer nodes being selected. (Additional discussion of this property can be found in the introduction of Section 2.1.)
構文的に有効なセグメントは、クエリを実行するときにエラーを作成してはなりません。これは、アレイの範囲の外側にあるインデックスを使用するなど、誤っていると見なされる可能性のある操作が、選択されたノードが少なくなるなどの一部の操作を意味します。（このプロパティの追加の議論は、セクション2.1の導入にあります。）
As a consequence of this approach, if any of the segments produces an empty nodelist, then the whole query produces an empty nodelist.
このアプローチの結果として、セグメントのいずれかが空のノデリストを生成する場合、クエリ全体が空のノデリストを生成します。
If the semantics of a query give an implementation a choice of producing multiple possible orderings, a particular implementation may produce distinct orderings in successive runs of the query.
クエリのセマンティクスが実装に複数の可能な注文を生成する選択肢を提供する場合、特定の実装は、クエリの連続した実行で明確な注文を生成する場合があります。
Consider this example. With the query argument {"a":[{"b":0},{"b":1},{"c":2}]}, the query $.a[*].b selects the following list of nodes (denoted here by their values): 0, 1.
この例を考えてください。クエリ引数{"a"：[{"b"：0}、{"b"：1}、{"c"：2}]}、query $ .a [*]。ノードの（ここでは値で示されています）：0、1。
The query consists of $ followed by three segments: .a, [*], and .b.
クエリは、$の続いて、3つのセグメントの続きで構成されています：.a、[*]、および.b。
First, $ produces a nodelist consisting of just the query argument.
まず、$はクエリ引数のみで構成されるノデリストを生成します。
Next, .a selects from any object input node and selects the node of any member value of the input node corresponding to the member name "a". The result is again a list containing a single node: [{"b":0},{"b":1},{"c":2}].
次に、.aは任意のオブジェクト入力ノードから選択し、メンバー名「A」に対応する入力ノードのメンバー値のノードを選択します。結果は、単一のノードを含むリストになります：[{"b"：0}、{"b"：1}、{"c"：2}]。
Next, [*] selects all the elements from the input array node. The result is a list of three nodes: {"b":0}, {"b":1}, and {"c":2}.
次に、[*]入力配列ノードからすべての要素を選択します。結果は、3つのノードのリストです：{"b"：0}、{"b"：1}、および{"c"：2}。
Finally, .b selects from any object input node with a member name b and selects the node of the member value of the input node corresponding to that name. The result is a list containing 0, 1. This is the concatenation of three lists: two of length one containing 0, 1, respectively, and one of length zero.
最後に、.bは、メンバー名bを持つオブジェクト入力ノードから任意のオブジェクト入力ノードを選択し、その名前に対応する入力ノードのメンバー値のノードを選択します。結果は、0、1を含むリストです。これは、3つのリストの連結です。それぞれ0、1を含む長さの2つと、長さゼロの1つです。
Every JSONPath query (except those inside filter expressions; see Section 2.3.5) MUST begin with the root identifier $.
すべてのJSonPathクエリ（内部フィルター式を除く;セクション2.3.5を参照）は、ルート識別子$から開始する必要があります。
root-identifier = "$"
The root identifier $ represents the root node of the query argument and produces a nodelist consisting of that root node.
ルート識別子$は、クエリ引数のルートノードを表し、そのルートノードで構成されるノデリストを生成します。
Note: In this example and the following examples in Sections 2.2 and 2.3, except for Table 11, we will present a JSON text to show the JSON value used as the query argument to the queries in the examples and then a table with the following columns:
注：この例と次の例では、2.2および2.3の次の例を表11を除き、JSONテキストを提示して、例のクエリのクエリ引数として使用されているJSON値を表示し、次の列のあるテーブルを表示します。：
* Query: an example query to be applied to the query argument
* クエリ：クエリ引数に適用されるクエリの例
* Result: the query result as a list of JSON values that were located in the query argument
* 結果：クエリ引数にあるJSON値のリストとしてのクエリ結果
* Result Path: the query result as a list of (normalized) paths into the query argument, giving locations of the JSON values in the previous column
* 結果パス：クエリ引数への（正規化された）パスのリストとしてのクエリ結果。前の列のJSON値の位置を与えます
* Comment: descriptive information
* コメント：記述情報
JSON:
JSON：
{"k": "v"}
Queries:
クエリ：
+=======+============+=============+===========+
| Query | Result | Result Path | Comment |
+=======+============+=============+===========+
| $ | {"k": "v"} | $ | Root node |
+-------+------------+-------------+-----------+
Table 3: Root Identifier Example
表3：ルート識別子の例
Selectors appear only inside child segments (Section 2.5.1) and descendant segments (Section 2.5.2).
セレクターは、子セグメント（セクション2.5.1）および子孫セグメント（セクション2.5.2）内にのみ表示されます。
A selector produces a nodelist consisting of zero or more children of the input value.
セレクターは、入力値のゼロ以上の子供で構成されるノデリストを生成します。
There are various kinds of selectors that produce children of objects, children of arrays, or children of either objects or arrays.
オブジェクトの子供、アレイの子供、またはオブジェクトまたはアレイの子供を生産するさまざまな種類のセレクターがあります。
selector = name-selector /
wildcard-selector /
slice-selector /
index-selector /
filter-selector
The syntax and semantics of each kind of selector are defined below.
各種類のセレクターの構文とセマンティクスを以下に定義します。
A name selector '<name>' selects at most one object member value.
name selector '<name>'は、最大1つのオブジェクトメンバー値を選択します。
In contrast to JSON, the JSONPath syntax allows strings to be enclosed in _single_ or _double_ quotes.
JSONとは対照的に、JSONPATH構文では、文字列を_Single_または_Double_引用符で囲むことができます。
name-selector = string-literal
string-literal = %x22 *double-quoted %x22 / ; "string"
%x27 *single-quoted %x27 ; 'string'
double-quoted = unescaped /
%x27 / ; '
ESC %x22 / ; \"
ESC escapable
single-quoted = unescaped /
%x22 / ; "
ESC %x27 / ; \'
ESC escapable
ESC = %x5C ; \ backslash
unescaped = %x20-21 / ; see RFC 8259
; omit 0x22 "
%x23-26 /
; omit 0x27 '
%x28-5B /
; omit 0x5C \
%x5D-D7FF /
; skip surrogate code points
%xE000-10FFFF
escapable = %x62 / ; b BS backspace U+0008
%x66 / ; f FF form feed U+000C
%x6E / ; n LF line feed U+000A
%x72 / ; r CR carriage return U+000D
%x74 / ; t HT horizontal tab U+0009
"/" / ; / slash (solidus) U+002F
"\" / ; \ backslash (reverse solidus) U+005C
(%x75 hexchar) ; uXXXX U+XXXX
hexchar = non-surrogate /
(high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
Notes:
ノート：
* Double-quoted strings follow the JSON string syntax (Section 7 of [RFC8259]); single-quoted strings follow an analogous pattern. No attempt was made to improve on this syntax, so if it is desired to escape characters with scalar values above 0xFFFF, such as U+1F041 ("🁁", DOMINO TILE HORIZONTAL-02-02), they need to be represented by a pair of surrogate escapes ("\uD83C\uDC41" in this case).
* 二重引用文字列は、JSON文字列構文（[RFC8259]のセクション7）に従います。単一引用文字列は、類似のパターンに従います。この構文を改善する試みは行われなかったので、u 1f041（ "🁁"、domino tile horizontal-02-02）など、0xffffを超えるスカラー値を持つ文字を逃がすことが望ましい場合は、ペアで表現する必要があります。代理脱出（この場合は "\ ud83c \ udc41"）の脱出。
* Alphabetic characters in quoted strings are case-insensitive in ABNF, so each of the hexadecimal digits within \u escapes (as specified in rules referenced by hexchar) can be either lowercase or uppercase, while the u in \u needs to be lowercase (indicated as %x75).
* 引用された文字列のアルファベット文字はABNFではケース非感受性です。そのため、\ uの脱出内の各六量体数字は（六ヘクサーによって参照されるルールで指定されているように）小文字または大文字のいずれかであり、\ uは小文字を必要とする必要があります（示すものがあります。AS％x75）。
A name-selector string MUST be converted to a member name M by removing the surrounding quotes and replacing each escape sequence with its equivalent Unicode character, as shown in Table 4:
表4に示すように。
+=================+===================+=============================+
| Escape Sequence | Unicode Character | Description |
+=================+===================+=============================+
| \b | U+0008 | BS backspace |
+-----------------+-------------------+-----------------------------+
| \t | U+0009 | HT horizontal tab |
+-----------------+-------------------+-----------------------------+
| \n | U+000A | LF line feed |
+-----------------+-------------------+-----------------------------+
| \f | U+000C | FF form feed |
+-----------------+-------------------+-----------------------------+
| \r | U+000D | CR carriage return |
+-----------------+-------------------+-----------------------------+
| \" | U+0022 | quotation mark |
+-----------------+-------------------+-----------------------------+
| \' | U+0027 | apostrophe |
+-----------------+-------------------+-----------------------------+
| \/ | U+002F | slash (solidus) |
+-----------------+-------------------+-----------------------------+
| \\ | U+005C | backslash (reverse |
| | | solidus) |
+-----------------+-------------------+-----------------------------+
| \uXXXX | see | hexadecimal escape |
| | Section 2.3.1.1 | |
+-----------------+-------------------+-----------------------------+
Table 4: Escape Sequence Replacements
表4：エスケープシーケンスの交換
Applying the name-selector to an object node selects a member value whose name equals the member name M or selects nothing if there is no such member value. Nothing is selected from a value that is not an object.
名前セレクターをオブジェクトノードに適用すると、名前がメンバー名mに等しい、またはそのようなメンバー値がない場合は何も選択しないメンバー値を選択します。オブジェクトではない値から選択されるものはありません。
Note: Processing the name selector requires comparing the member name string M with member name strings in the JSON to which the selector is being applied. Two strings MUST be considered equal if and only if they are identical sequences of Unicode scalar values. In other words, normalization operations MUST NOT be applied to either the member name string M from the JSONPath or the member name strings in the JSON prior to comparison.
注：名前セレクターを処理するには、メンバー名文字列Mとセレクターが適用されているJSONのメンバー名文字列を比較する必要があります。2つの文字列は、ユニコードスカラー値の同一シーケンスである場合にのみ等しいと見なす必要があります。言い換えれば、比較前に、JSONPATHのメンバー名String MまたはJSONのメンバー名文字列に正規化操作を適用する必要はありません。
JSON:
JSON：
{
"o": {"j j": {"k.k": 3}},
"'": {"@": 2}
}
Queries:
クエリ：
The examples in Table 5 show the name selector in use by child segments.
表5の例は、子セグメントで使用されている名前セレクターを示しています。
+====================+=======+=======================+============+
| Query |Result | Result Paths | Comment |
+====================+=======+=======================+============+
| $.o['j j'] |{"k.k":| $['o']['j j'] | Named |
| |3} | | value in |
| | | | a nested |
| | | | object |
+--------------------+-------+-----------------------+------------+
| $.o['j j']['k.k'] |3 | $['o']['j j']['k.k'] | Nesting |
| | | | further |
| | | | down |
+--------------------+-------+-----------------------+------------+
| $.o["j j"]["k.k"] |3 | $['o']['j j']['k.k'] | Different |
| | | | delimiter |
| | | | in the |
| | | | query, |
| | | | unchanged |
| | | | Normalized |
| | | | Path |
+--------------------+-------+-----------------------+------------+
| $["'"]["@"] |2 | $['\'']['@'] | Unusual |
| | | | member |
| | | | names |
+--------------------+-------+-----------------------+------------+
Table 5: Name Selector Examples
表5：名前セレクターの例
The wildcard selector consists of an asterisk.
ワイルドカードセレクターはアスタリスクで構成されています。
wildcard-selector = "*"
A wildcard selector selects the nodes of all children of an object or array. The order in which the children of an object appear in the resultant nodelist is not stipulated, since JSON objects are unordered. Children of an array appear in array order in the resultant nodelist.
ワイルドカードセレクターは、オブジェクトまたは配列のすべての子供のノードを選択します。JSONオブジェクトは順序付けられていないため、結果のノデリストにオブジェクトの子供が表示される順序は規定されていません。アレイの子供は、結果のノデリストに配列の順序で表示されます。
Note that the children of an object are its member values, not its member names.
オブジェクトの子供は、メンバー名ではなく、メンバー値であることに注意してください。
The wildcard selector selects nothing from a primitive JSON value (that is, a number, a string, true, false, or null).
WildCardセレクターは、プリミティブJSON値（つまり、数字、文字列、真、false、またはnull）から何も選択しません。
JSON:
JSON：
{
"o": {"j": 1, "k": 2},
"a": [5, 3]
}
Queries:
クエリ：
The examples in Table 6 show the wildcard selector in use by a child segment.
表6の例は、子セグメントで使用されているワイルドカードセレクターを示しています。
+========+==========+=============+===================+
| Query | Result | Result | Comment |
| | | Paths | |
+========+==========+=============+===================+
| $[*] | {"j": 1, | $['o'] | Object values |
| | "k": 2} | $['a'] | |
| | [5, 3] | | |
+--------+----------+-------------+-------------------+
| $.o[*] | 1 | $['o']['j'] | Object values |
| | 2 | $['o']['k'] | |
+--------+----------+-------------+-------------------+
| $.o[*] | 2 | $['o']['k'] | Alternative |
| | 1 | $['o']['j'] | result |
+--------+----------+-------------+-------------------+
| $.o[*, | 1 | $['o']['j'] | Non-deterministic |
| *] | 2 | $['o']['k'] | ordering |
| | 2 | $['o']['k'] | |
| | 1 | $['o']['j'] | |
+--------+----------+-------------+-------------------+
| $.a[*] | 5 | $['a'][0] | Array members |
| | 3 | $['a'][1] | |
+--------+----------+-------------+-------------------+
Table 6: Wildcard Selector Examples
表6：ワイルドカードセレクターの例
The example above with the query $.o[*, *] shows that the wildcard selector may produce nodelists in distinct orders each time it appears in the child segment when it is applied to an object node with two or more members (but not when it is applied to object nodes with fewer than two members or to array nodes).
Query $ .o [ *、 *]の上記の例は、ワイルドカードセレクターが2人以上のメンバーを持つオブジェクトノードに適用されるときに、子セグメントに表示されるたびに明確な順序でノデリストを生成する可能性があることを示しています（ただし、2人未満のメンバーまたは配列ノードのオブジェクトノードに適用されます）。
An index selector <index> matches at most one array element value.
インデックスセレクター<index>は、最大1つの配列要素値で一致します。
index-selector = int ; decimal integer
int = "0" /
(["-"] DIGIT1 *DIGIT) ; - optional
DIGIT1 = %x31-39 ; 1-9 non-zero digit
Applying the numerical index-selector selects the corresponding element. JSONPath allows it to be negative (see Section 2.3.3.2).
数値インデックスセレクターを適用すると、対応する要素が選択されます。JSonPathを使用すると、それを負にすることができます（セクション2.3.3.2を参照）。
To be valid, the index selector value MUST be in the I-JSON range of exact values (see Section 2.1).
有効にするには、インデックスセレクターの値は、正確な値のI-JSON範囲にある必要があります（セクション2.1を参照）。
Notes:
ノート：
* An index-selector is an integer (in base 10, as in JSON numbers).
* インデックスセレクターは整数です（JSON番号のように、ベース10の）。
* As in JSON numbers, the syntax does not allow octal-like integers with leading zeros, such as 01 or -01.
* JSON数と同様に、構文では、01や-01などの主要なゼロを持つオクタル様整数が許可されていません。
A non-negative index-selector applied to an array selects an array element using a zero-based index. For example, the selector 0 selects the first, and the selector 4 selects the fifth element of a sufficiently long array. Nothing is selected, and it is not an error, if the index lies outside the range of the array. Nothing is selected from a value that is not an array.
配列に適用される非陰性インデックスセレクターは、ゼロベースのインデックスを使用して配列要素を選択します。たとえば、セレクター0は最初のものを選択し、セレクター4は十分に長い配列の5番目の要素を選択します。インデックスが配列の範囲外にある場合、それは何も選択されておらず、それはエラーではありません。配列ではない値から選択されるものはありません。
A negative index-selector counts from the array end backwards, obtaining an equivalent non-negative index-selector by adding the length of the array to the negative index. For example, the selector -1 selects the last, and the selector -2 selects the penultimate element of an array with at least two elements. As with non-negative indexes, it is not an error if such an element does not exist; this simply means that no element is selected.
アレイからの負のインデックスセレクターは逆方向にカウントされ、アレイの長さを負のインデックスに追加することにより、同等の非陰性インデックスセレクターを取得します。たとえば、セレクター-1は最後を選択し、セレクター-2は少なくとも2つの要素を持つ配列の最後から2番目の要素を選択します。非陰性インデックスと同様に、そのような要素が存在しない場合、それはエラーではありません。これは、単に要素が選択されていないことを意味します。
JSON:
JSON：
["a","b"]
Queries:
クエリ：
The examples in Table 7 show the index selector in use by a child segment.
表7の例は、子セグメントで使用されているインデックスセレクターを示しています。
+=======+========+==============+================================+
| Query | Result | Result Paths | Comment |
+=======+========+==============+================================+
| $[1] | "b" | $[1] | Element of array |
+-------+--------+--------------+--------------------------------+
| $[-2] | "a" | $[0] | Element of array, from the end |
+-------+--------+--------------+--------------------------------+
Table 7: Index Selector Examples
表7：インデックスセレクターの例
The array slice selector has the form <start>:<end>:<step>. It matches elements from arrays starting at index <start> and ending at (but not including) <end>, while incrementing by step with a default of 1.
配列スライスセレクターには、<Start>：<End>：<step>フォームがあります。インデックス<Start>から始まり、<End>で終了する（ただしない）アレイの要素と一致し、デフォルトの1でステップごとに増加します。
slice-selector = [start S] ":" S [end S] [":" [S step ]]
start = int ; included in selection
end = int ; not included in selection
step = int ; default: 1
The slice selector consists of three optional decimal integers separated by colons. The second colon can be omitted when the third integer is omitted.
スライスセレクターは、コロンで区切られた3つのオプションの小数整数で構成されています。3番目の整数が省略されている場合、2番目のコロンは省略できます。
To be valid, the integers provided MUST be in the I-JSON range of exact values (see Section 2.1).
有効にするには、提供される整数は正確な値のI-JSON範囲にある必要があります（セクション2.1を参照）。
The slice selector was inspired by the slice operator that was proposed for ECMAScript 4 (ES4), which was never released, and that of Python.
スライスセレクターは、ECMAScript 4（ES4）に提案されたスライス演算子に触発されました。
This section is informative.
このセクションは有益です。
Array slicing is inspired by the behavior of the Array.prototype.slice method of the JavaScript language, as defined by the ECMA-262 standard [ECMA-262], with the addition of the step parameter, which is inspired by the Python slice expression.
Arrayスライシングは、eCMA-262標準[ECMA-262]で定義されているArray.Prototype.Sliceメソッドの動作に触発されます。。
The array slice expression start:end:step selects elements at indices starting at start, incrementing by step, and ending with end (which is itself excluded). So, for example, the expression 1:3 (where step defaults to 1) selects elements with indices 1 and 2 (in that order), whereas 1:5:2 selects elements with indices 1 and 3.
アレイスライス式の開始：終了：ステップは、開始時に開始するインデックスで要素を選択し、ステップごとに増加し、終了（それ自体が除外されています）で終了します。したがって、たとえば、式1：3（ステップがデフォルトで1）は、インデックス1と2（その順序で）を持つ要素を選択しますが、1：5：2はインデックス1と3の要素を選択します。
When step is negative, elements are selected in reverse order. Thus, for example, 5:1:-2 selects elements with indices 5 and 3 (in that order), and ::-1 selects all the elements of an array in reverse order.
ステップが負の場合、要素は逆の順序で選択されます。したがって、たとえば、5：1：-2は、インデックス5および3（その順序で）を持つ要素を選択し、::-1は配列のすべての要素を逆の順序で選択します。
When step is 0, no elements are selected. (This is the one case that differs from the behavior of Python, which raises an error in this case.)
ステップが0の場合、要素は選択されていません。（これは、Pythonの動作とは異なる1つのケースであり、この場合にエラーが発生します。）
The following section specifies the behavior fully, without depending on JavaScript or Python behavior.
次のセクションでは、JavaScriptやPythonの動作に依存することなく、動作を完全に指定します。
A slice expression selects a subset of the elements of the input array in the same order as the array or the reverse order, depending on the sign of the step parameter. It selects no nodes from a node that is not an array.
スライス式は、ステップパラメーターの符号に応じて、入力配列の要素のサブセットを配列または逆の順序で選択します。アレイではないノードからノードを選択しません。
A slice is defined by the two slice parameters, start and end, and an iteration delta, step. Each of these parameters is optional. In the rest of this section, len denotes the length of the input array.
スライスは、2つのスライスパラメーター、開始と終了、および反復デルタ、ステップによって定義されます。これらの各パラメーターはオプションです。このセクションの残りの部分では、LENは入力配列の長さを示します。
The default value for step is 1. The default values for start and end depend on the sign of step, as shown in Table 8.
ステップのデフォルト値は1です。表8に示すように、開始と終了のデフォルト値はステップの符号に依存します。
+===========+=========+==========+
| Condition | start | end |
+===========+=========+==========+
| step >= 0 | 0 | len |
+-----------+---------+----------+
| step < 0 | len - 1 | -len - 1 |
+-----------+---------+----------+
Table 8: Default Array Slice start and end Values
表8：デフォルトの配列スライスの開始値と終了値
Slice expression parameters start and end are not directly usable as slice bounds and must first be normalized. Normalization for this purpose is defined as:
スライス式の式パラメーターの開始と端は、スライス境界として直接使用できず、最初に正規化する必要があります。この目的の正規化は、次のように定義されます。
FUNCTION Normalize(i, len):
IF i >= 0 THEN
RETURN i
ELSE
RETURN len + i
END IF
The result of the array index expression i applied to an array of length len is the result of the array slicing expression Normalize(i, len):Normalize(i, len)+1:1.
LENの配列に適用した配列インデックス式の結果は、アレイスライシング式式（i、len）：正規化（i、len）1：1の結果です。
Slice expression parameters start and end are used to derive slice bounds lower and upper. The direction of the iteration, defined by the sign of step, determines which of the parameters is the lower bound and which is the upper bound:
スライス式の式パラメータの開始と端は、スライス境界を下と上のスライス境界を導出するために使用されます。ステップの符号によって定義される反復の方向は、どのパラメーターが下限であり、どのパラメーターが上限であるかを決定します。
FUNCTION Bounds(start, end, step, len):
n_start = Normalize(start, len)
n_end = Normalize(end, len)
IF step >= 0 THEN
lower = MIN(MAX(n_start, 0), len)
upper = MIN(MAX(n_end, 0), len)
ELSE
upper = MIN(MAX(n_start, -1), len-1)
lower = MIN(MAX(n_end, -1), len-1)
END IF
RETURN (lower, upper)
The slice expression selects elements with indices between the lower and upper bounds. In the following pseudocode, a(i) is the i+1th element of the array a (i.e., a(0) is the first element, a(1) the second, and so forth).
スライス式は、下限と上限の間にインデックスを持つ要素を選択します。次の擬似コードでは、a（i）は配列a（すなわち、a（0）が最初の要素であり、a（1）2番目など）の第1要素です。
IF step > 0 THEN
i = lower
WHILE i < upper:
SELECT a(i)
i = i + step
END WHILE
ELSE if step < 0 THEN
i = upper
WHILE lower < i:
SELECT a(i)
i = i + step
END WHILE
END IF
When step = 0, no elements are selected, and the result array is empty.
step = 0の場合、要素は選択されておらず、結果配列は空です。
JSON:
JSON：
["a", "b", "c", "d", "e", "f", "g"]
Queries:
クエリ：
The examples in Table 9 show the array slice selector in use by a child segment.
表9の例は、子セグメントで使用されているアレイスライスセレクターを示しています。
+===========+========+========+==========+
| Query | Result | Result | Comment |
| | | Paths | |
+===========+========+========+==========+
| $[1:3] | "b" | $[1] | Slice |
| | "c" | $[2] | with |
| | | | default |
| | | | step |
+-----------+--------+--------+----------+
| $[5:] | "f" | $[5] | Slice |
| | "g" | $[6] | with no |
| | | | end |
| | | | index |
+-----------+--------+--------+----------+
| $[1:5:2] | "b" | $[1] | Slice |
| | "d" | $[3] | with |
| | | | step 2 |
+-----------+--------+--------+----------+
| $[5:1:-2] | "f" | $[5] | Slice |
| | "d" | $[3] | with |
| | | | negative |
| | | | step |
+-----------+--------+--------+----------+
| $[::-1] | "g" | $[6] | Slice in |
| | "f" | $[5] | reverse |
| | "e" | $[4] | order |
| | "d" | $[3] | |
| | "c" | $[2] | |
| | "b" | $[1] | |
| | "a" | $[0] | |
+-----------+--------+--------+----------+
Table 9: Array Slice Selector Examples
表9：配列スライスセレクターの例
Filter selectors are used to iterate over the elements or members of structured values, i.e., JSON arrays and objects. The structured values are identified in the nodelist offered by the child or descendant segment using the filter selector.
フィルターセレクターは、構造化された値の要素またはメンバー、つまりJSONアレイとオブジェクトを反復するために使用されます。構造化された値は、フィルターセレクターを使用して、子または子孫セグメントが提供するノデリストで識別されます。
For each iteration (element/member), a logical expression (the _filter expression_) is evaluated, which decides whether the node of the element/member is selected. (While a logical expression evaluates to what mathematically is a Boolean value, this specification uses the term _logical_ to maintain a distinction from the Boolean values that JSON can represent.)
各反復（要素/メンバー）について、論理式（_Filter Expression_）が評価され、要素/メンバーのノードが選択されているかどうかを決定します。（論理式は数学的にブール値であるものを評価しますが、この仕様は_logical_という用語を使用して、JSONが表すことができるブール値と区別を維持します。）
During the iteration process, the filter expression receives the node of each array element or object member value of the structured value being filtered; this element or member value is then known as the _current node_.
反復プロセス中、フィルター式は、フィルタリングされている構造値の各配列要素またはオブジェクトメンバー値のノードを受信します。この要素またはメンバー値は、_current node_として知られています。
The current node can be used as the start of one or more JSONPath queries in subexpressions of the filter expression, notated via the current-node-identifier @. Each JSONPath query can be used either for testing existence of a result of the query, for obtaining a specific JSON value resulting from that query that can then be used in a comparison, or as a _function argument_.
現在のノードは、現在のnode-identifier @を介して記載されているフィルター式のサブエクスペッションでの1つ以上のjsonpathクエリの開始として使用できます。各JSonPathクエリは、クエリの結果の存在をテストするために、そのクエリから生じる特定のJSON値を取得するために使用できます。そのクエリは、比較で使用できます。
Filter selectors may use function extensions, which are covered in Section 2.4. Within the logical expression for a filter selector, function expressions can be used to operate on nodelists and values. The set of available functions is extensible, with a number of functions predefined (see Section 2.4) and the ability to register further functions provided by the "Function Extensions" subregistry (Section 3.2). When a function is defined, it is given a unique name, and its return value and each of its parameters are given a _declared type_. The type system is limited in scope; its purpose is to express restrictions that, without functions, are implicit in the grammar of filter expressions. The type system also guides conversions (Section 2.4.2) that mimic the way different kinds of expressions are handled in the grammar when function expressions are not in use.
フィルターセレクターは、セクション2.4でカバーされている機能拡張機能を使用する場合があります。フィルターセレクターの論理式内では、関数式を使用してノデリストと値を動作させることができます。利用可能な関数のセットは拡張可能であり、多くの関数が事前に定義されており（セクション2.4を参照）、「関数拡張」サブレジストリ（セクション3.2）によって提供されるさらなる関数を登録する機能があります。関数が定義されると、一意の名前が与えられ、その返品値とそのパラメーターのそれぞれに_declared type_が与えられます。タイプシステムの範囲は制限されています。その目的は、機能がなければ、フィルター式の文法に暗黙的である制限を表現することです。また、タイプシステムは、関数式が使用されていない場合にさまざまな種類の式が文法で処理される方法を模倣する変換（セクション2.4.2）をガイドします。
The filter selector has the form ?<logical-expr>.
フィルターセレクターにはフォームがありますか？<Logical-Expr>。
filter-selector = "?" S logical-expr
As the filter expression is composed of constituents free of side effects, the order of evaluation does not need to be (and is not) defined. Similarly, for conjunction (&&) and disjunction (||) (defined later), both a short-circuiting and a fully evaluating implementation will lead to the same result; both implementation strategies are therefore valid.
フィルター式は副作用のない構成要素で構成されているため、評価の順序は定義される必要はありません（そしてそうではありません）。同様に、接続詞（&&）および分離（||）（後で定義）の場合、短絡と完全に評価する実装の両方が同じ結果につながります。したがって、両方の実装戦略が有効です。
The current node is accessible via the current node identifier @. This identifier addresses the current node of the filter-selector that is directly enclosing the identifier. Note: Within nested filter-selectors, there is no syntax to address the current node of any other than the directly enclosing filter-selector (i.e., of filter-selectors enclosing the filter-selector that is directly enclosing the identifier).
現在のノードは、現在のノード識別子 @からアクセスできます。この識別子は、識別子を直接囲んでいるフィルターセレクターの現在のノードに対応します。注：ネストされたフィルターセレクター内には、直接囲まれたフィルターセレクター以外の現在のノードに対処する構文はありません（つまり、識別子を直接囲むフィルターセレクターを囲むフィルターセレクター）。
Logical expressions offer the usual Boolean operators (|| for OR, && for AND, and ! for NOT). They have the normal semantics of Boolean algebra and obey its laws (for example, see [BOOLEAN-LAWS]). Parentheses MAY be used within logical-expr for grouping.
論理式は、通常のブールの演算子を提供します（|| for or、&& for、および！for not）。それらは、ブール代数の通常のセマンティクスを持ち、その法則に従います（たとえば、[boolean-laws]を参照）。括弧は、グループ化のために論理expr内で使用できます。
It is not required that logical-expr consist of a parenthesized expression (which was required in [JSONPath-orig]), although it can be, and the semantics are the same as without the parentheses.
論理-Exprは、括弧付きの式（[jsonpath-orig]では必要でした）で構成されていることは必須ではありませんが、セマンティクスは括弧なしと同じです。
logical-expr = logical-or-expr
logical-or-expr = logical-and-expr *(S "||" S logical-and-expr)
; disjunction
; binds less tightly than conjunction
logical-and-expr = basic-expr *(S "&&" S basic-expr)
; conjunction
; binds more tightly than disjunction
basic-expr = paren-expr /
comparison-expr /
test-expr
paren-expr = [logical-not-op S] "(" S logical-expr S ")"
; parenthesized expression
logical-not-op = "!" ; logical NOT operator
A test expression either tests the existence of a node designated by an embedded query (see Section 2.3.5.2.1) or tests the result of a function expression (see Section 2.4). In the latter case, if the function's declared result type is LogicalType (see Section 2.4.1), it tests whether the result is LogicalTrue; if the function's declared result type is NodesType, it tests whether the result is non-empty. If the function's declared result type is ValueType, its use in a test expression is not well-typed (see Section 2.4.3).
テスト式は、組み込みクエリ（セクション2.3.5.2.1を参照）で指定されたノードの存在をテストするか、関数式の結果をテストします（セクション2.4を参照）。後者の場合、関数の宣言された結果タイプが論理タイプである場合（セクション2.4.1を参照）、結果が論理的なものかどうかをテストします。関数の宣言された結果タイプがnodestypeである場合、結果が空でないかどうかをテストします。関数の宣言された結果タイプがValueTypeである場合、テスト式での使用は十分にタイプではありません（セクション2.4.3を参照）。
test-expr = [logical-not-op S]
(filter-query / ; existence/non-existence
function-expr) ; LogicalType or NodesType
filter-query = rel-query / jsonpath-query
rel-query = current-node-identifier segments
current-node-identifier = "@"
Comparison expressions are available for comparisons between primitive values (that is, numbers, strings, true, false, and null). These can be obtained via literal values; singular queries, each of which selects at most one node, the value of which is then used; or function expressions (see Section 2.4) of type ValueType.
比較式は、プリミティブ値（つまり、数字、文字列、真、偽、ヌル）の比較に使用できます。これらはリテラル値を介して取得できます。それぞれが最大1つのノードで選択され、その値が使用されます。または型ValueTypeの関数式（セクション2.4を参照）。
comparison-expr = comparable S comparison-op S comparable
literal = number / string-literal /
true / false / null
comparable = literal /
singular-query / ; singular query value
function-expr ; ValueType
comparison-op = "==" / "!=" /
"<=" / ">=" /
"<" / ">"
singular-query = rel-singular-query / abs-singular-query
rel-singular-query = current-node-identifier singular-query-segments
abs-singular-query = root-identifier singular-query-segments
singular-query-segments = *(S (name-segment / index-segment))
name-segment = ("[" name-selector "]") /
("." member-name-shorthand)
index-segment = "[" index-selector "]"
Literals can be notated in the way that is usual for JSON (with the extension that strings can use single-quote delimiters).
リテラルは、JSONの通常の方法で記述できます（文字列が単一引用符のデリミターを使用できる拡張機能）。
Note: Alphabetic characters in quoted strings are case-insensitive in ABNF, so within a floating point number, the ABNF expression "e" can be either the character 'e' or 'E'.
注：引用された文字列のアルファベット文字は、ABNFでケース非感受性であるため、浮動小数点数内では、ABNF式「E」は文字「E」または「E」のいずれかになります。
true, false, and null are lowercase only (case-sensitive).
true、false、およびnullは小文字のみです（ケースに敏感です）。
number = (int / "-0") [ frac ] [ exp ] ; decimal number
frac = "." 1*DIGIT ; decimal fraction
exp = "e" [ "-" / "+" ] 1*DIGIT ; decimal exponent
true = %x74.72.75.65 ; true
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
Table 10 lists filter expression operators in order of precedence from highest (binds most tightly) to lowest (binds least tightly).
表10に、優先順位の順にフィルター式演算子を最も高い（最もしっかりと結合する）順にリストします（最小のバインド）。
+============+======================+=============+
| Precedence | Operator type | Syntax |
+============+======================+=============+
| 5 | Grouping | (...) |
| | Function Expressions | _name_(...) |
+------------+----------------------+-------------+
| 4 | Logical NOT | ! |
+------------+----------------------+-------------+
| 3 | Relations | == != |
| | | < <= > >= |
+------------+----------------------+-------------+
| 2 | Logical AND | && |
+------------+----------------------+-------------+
| 1 | Logical OR | || |
+------------+----------------------+-------------+
Table 10: Filter Expression Operator Precedence
表10：フィルター式演算子の優先順位
The filter selector works with arrays and objects exclusively. Its result is a list of (_zero_, _one_, _multiple_, or _all_) their array elements or member values, respectively. Applied to a primitive value, it selects nothing (and therefore does not contribute to the result of the filter selector).
フィルターセレクターは、配列とオブジェクトのみで動作します。その結果、アレイ要素またはメンバー値のそれぞれ（_zero_、_one_、_multiple_、または_all_）のリストが表示されます。プリミティブ値に適用されると、何も選択しません（したがって、フィルターセレクターの結果には寄与しません）。
In the resultant nodelist, children of an array are ordered by their position in the array. The order in which the children of an object (as opposed to an array) appear in the resultant nodelist is not stipulated, since JSON objects are unordered.
結果のノデリストでは、配列の子供は配列内の位置によって順序付けられます。JSONオブジェクトは順序付けられていないため、結果のノデリストに（アレイとは対照的に）オブジェクトの子供が（配列とは対照的に）表示される順序は規定されていません。
A query by itself in a logical context is an existence test that yields true if the query selects at least one node and yields false if the query does not select any nodes.
論理コンテキストでのクエリ自体は、クエリが少なくとも1つのノードを選択し、クエリがノードを選択しない場合にfalseを生成する場合に真の存在テストです。
Existence tests differ from comparisons in that:
存在テストは、その比較とは異なります。
* They work with arbitrary relative or absolute queries (not just singular queries).
* それらは、任意の相対的または絶対的なクエリ（単数のクエリだけでなく）で動作します。
* They work with queries that select structured values.
* 構造化された値を選択するクエリで動作します。
To examine the value of a node selected by a query, an explicit comparison is necessary. For example, to test whether the node selected by the query @.foo has the value null, use @.foo == null (see Section 2.6) rather than the negated existence test !@.foo (which yields false if @.foo selects a node, regardless of the node's value). Similarly, @.foo == false yields true only if @.foo selects a node and the value of that node is false.
クエリで選択されたノードの値を調べるには、明示的な比較が必要です。たとえば、Query @.fooで選択されたノードに値nullがあるかどうかをテストするには、negated Indess test！ @.foo（ @.fooの場合にfalseを生成する場合、 @.foo == null（セクション2.6を参照）を使用します（セクション2.6を参照）ノードの値に関係なく、ノードを選択します）。同様に、 @.foo == falseは、 @.fooがノードを選択し、そのノードの値がfalseである場合にのみtrueを生成します。
The comparison operators == and < are defined first, and then these are used to define !=, <=, >, and >=.
比較演算子==および<は最初に定義され、次にこれらは！=、<=、>、および> =を定義するために使用されます。
When either side of a comparison results in an empty nodelist or the special result Nothing (see Section 2.4.1):
比較のどちらかの側面が空のノデリストまたは特別な結果が得られない場合（セクション2.4.1を参照）：
* A comparison using the operator == yields true if and only the other side also results in an empty nodelist or the special result Nothing.
* Operator ==を使用した比較は、反対側のみが空のノデリストまたは特別な結果をもたらす場合、真でありません。
* A comparison using the operator < yields false.
* オペレーターを使用した比較<falseを生成します。
When any query or function expression on either side of a comparison results in a nodelist consisting of a single node, that side is replaced by the value of its node and then:
比較の両側でのクエリまたは関数式が、単一のノードで構成されるノデリストが生じる場合、その側はそのノードの値に置き換えられ、次に次のように置き換えられます。
* A comparison using the operator == yields true if and only if the comparison is between:
* Operator ==を使用した比較は、比較が次の場合にのみTRUEを生成します。
- numbers expected to interoperate, as per Section 2.2 of I-JSON [RFC7493], that compare equal using normal mathematical equality,
- I-JSON [RFC7493]のセクション2.2に従って相互運用すると予想される数字は、通常の数学的平等を使用して等しいと比較します。
- numbers, at least one of which is not expected to interoperate as per I-JSON, where the numbers compare equal using an implementation-specific equality,
- 数字、少なくとも1つはI-JSONに従って相互運用するとは予想されていません。この場合、数値は実装固有の平等を使用して等しいと比較されます。
- equal primitive values that are not numbers,
- 数字ではない等しい原始値、
- equal arrays, that is, arrays of the same length where each element of the first array is equal to the corresponding element of the second array, or
- 等しい配列、つまり、最初のアレイの各要素が2番目の配列の対応する要素に等しいのと同じ長さの配列、または
- equal objects with no duplicate names, that is, where:
- 名前が複製されていない等しいオブジェクト、つまり、ここで：
o both objects have the same collection of names (with no duplicates) and
o どちらのオブジェクトにも同じ名前のコレクションがあります（重複はありません）と
o for each of those names, the values associated with the name by the objects are equal.
o これらの名前のそれぞれについて、オブジェクトによって名前に関連付けられた値は等しくなります。
* A comparison using the operator < yields true if and only if the comparison is between values that are both numbers or both strings and that satisfy the comparison:
* Operator <を使用した比較は、数字または両方の文字列であり、比較を満たす値の両方の値の間での場合にのみTRUEを生成します。
- numbers expected to interoperate, as per Section 2.2 of I-JSON [RFC7493], MUST compare using the normal mathematical ordering; numbers not expected to interoperate, as per I-JSON, MAY compare using an implementation-specific ordering,
- I-JSON [RFC7493]のセクション2.2に従って、相互運用すると予想される数値は、通常の数学的順序を使用して比較する必要があります。I-JSONによると、相互運用すると予想されていない数字は、実装固有の順序付けを使用して比較する場合があります。
- the empty string compares less than any non-empty string, and
- 空の文字列は、空でない文字列と比較し、
- a non-empty string compares less than another non-empty string if and only if the first string starts with a lower Unicode scalar value than the second string or if both strings start with the same Unicode scalar value and the remainder of the first string compares less than the remainder of the second string.
- 最初の文字列が2番目の文字列よりも低いUnicodeスカラー値で始まる場合、または両方の文字列が同じUnicodeスカラー値で開始され、最初の文字列の残りが比較される場合にのみ、空でない文字列が別の非空白の文字列よりも少ない場合にのみ比較されます2番目の文字列の残りよりも少ない。
!=, <=, >, and >= are defined in terms of the other comparison operators. For any a and b:
！=、<=、>、および> =は、他の比較演算子に関して定義されます。AおよびBの場合：
* The comparison a != b yields true if and only if a == b yields false.
* 比較a！= bは、a == bがfalseを生成する場合にのみ真であります。
* The comparison a <= b yields true if and only if a < b yields true or a == b yields true.
* A <= bがtrueまたはa == bが真である場合にのみ、比較a <= bはtrueを生成します。
* The comparison a > b yields true if and only if b < a yields true.
* 比較a> bは、b <aが真である場合にのみ真であります。
* The comparison a >= b yields true if and only if b < a yields true or a == b yields true.
* 比較a> = bは、b <aが真であるか、a == bが真である場合にのみ真である。
The first set of examples shows some comparison expressions and their result with a given JSON value as input.
最初の一連の例は、いくつかの比較式とその結果を入力として与えられたJSON値を示しています。
JSON:
JSON：
{
"obj": {"x": "y"},
"arr": [2, 3]
}
Comparisons:
比較：
+========================+========+========================+
| Comparison | Result | Comment |
+========================+========+========================+
| $.absent1 == $.absent2 | true | Empty nodelists |
+------------------------+--------+------------------------+
| $.absent1 <= $.absent2 | true | == implies <= |
+------------------------+--------+------------------------+
| $.absent == 'g' | false | Empty nodelist |
+------------------------+--------+------------------------+
| $.absent1 != $.absent2 | false | Empty nodelists |
+------------------------+--------+------------------------+
| $.absent != 'g' | true | Empty nodelist |
+------------------------+--------+------------------------+
| 1 <= 2 | true | Numeric comparison |
+------------------------+--------+------------------------+
| 1 > 2 | false | Numeric comparison |
+------------------------+--------+------------------------+
| 13 == '13' | false | Type mismatch |
+------------------------+--------+------------------------+
| 'a' <= 'b' | true | String comparison |
+------------------------+--------+------------------------+
| 'a' > 'b' | false | String comparison |
+------------------------+--------+------------------------+
| $.obj == $.arr | false | Type mismatch |
+------------------------+--------+------------------------+
| $.obj != $.arr | true | Type mismatch |
+------------------------+--------+------------------------+
| $.obj == $.obj | true | Object comparison |
+------------------------+--------+------------------------+
| $.obj != $.obj | false | Object comparison |
+------------------------+--------+------------------------+
| $.arr == $.arr | true | Array comparison |
+------------------------+--------+------------------------+
| $.arr != $.arr | false | Array comparison |
+------------------------+--------+------------------------+
| $.obj == 17 | false | Type mismatch |
+------------------------+--------+------------------------+
| $.obj != 17 | true | Type mismatch |
+------------------------+--------+------------------------+
| $.obj <= $.arr | false | Objects and arrays do |
| | | not offer < comparison |
+------------------------+--------+------------------------+
| $.obj < $.arr | false | Objects and arrays do |
| | | not offer < comparison |
+------------------------+--------+------------------------+
| $.obj <= $.obj | true | == implies <= |
+------------------------+--------+------------------------+
| $.arr <= $.arr | true | == implies <= |
+------------------------+--------+------------------------+
| 1 <= $.arr | false | Arrays do not offer < |
| | | comparison |
+------------------------+--------+------------------------+
| 1 >= $.arr | false | Arrays do not offer < |
| | | comparison |
+------------------------+--------+------------------------+
| 1 > $.arr | false | Arrays do not offer < |
| | | comparison |
+------------------------+--------+------------------------+
| 1 < $.arr | false | Arrays do not offer < |
| | | comparison |
+------------------------+--------+------------------------+
| true <= true | true | == implies <= |
+------------------------+--------+------------------------+
| true > true | false | Booleans do not offer |
| | | < comparison |
+------------------------+--------+------------------------+
Table 11: Comparison Examples
表11：比較例
The second set of examples shows some complete JSONPath queries that make use of filter selectors and the results of evaluating these queries on a given JSON value as input. (Note: Two of the queries employ function extensions; please see Sections 2.4.6 and 2.4.7 for details about these.)
2番目の例のセットは、フィルターセレクターを使用するいくつかの完全なJSONPATHクエリと、特定のJSON値でこれらのクエリを入力として評価した結果を示しています。（注：2つのクエリは機能拡張機能を採用しています。これらの詳細については、セクション2.4.6および2.4.7を参照してください。）
JSON:
JSON：
{
"a": [3, 5, 1, 2, 4, 6,
{"b": "j"},
{"b": "k"},
{"b": {}},
{"b": "kilo"}
],
"o": {"p": 1, "q": 2, "r": 3, "s": 5, "t": {"u": 6}},
"e": "f"
}
Queries:
クエリ：
The examples in Table 12 show the filter selector in use by a child segment.
表12の例は、子セグメントで使用されているフィルターセレクターを示しています。
+==================+==============+=============+===================+
| Query | Result | Result | Comment |
| | | Paths | |
+==================+==============+=============+===================+
| $.a[?@.b == | {"b": | $['a'][9] | Member value |
| 'kilo'] | "kilo"} | | comparison |
+------------------+--------------+-------------+-------------------+
| $.a[?(@.b == | {"b": | $['a'][9] | Equivalent query |
| 'kilo')] | "kilo"} | | with enclosing |
| | | | parentheses |
+------------------+--------------+-------------+-------------------+
| $.a[?@>3.5] | 5 | $['a'][1] | Array value |
| | 4 | $['a'][4] | comparison |
| | 6 | $['a'][5] | |
+------------------+--------------+-------------+-------------------+
| $.a[?@.b] | {"b": "j"} | $['a'][6] | Array value |
| | {"b": "k"} | $['a'][7] | existence |
| | {"b": {}} | $['a'][8] | |
| | {"b": | $['a'][9] | |
| | "kilo"} | | |
+------------------+--------------+-------------+-------------------+
| $[?@.*] | [3, 5, 1, | $['a'] | Existence of non- |
| | 2, 4, 6, | $['o'] | singular queries |
| | {"b": "j"}, | | |
| | {"b": "k"}, | | |
| | {"b": {}}, | | |
| | {"b": | | |
| | "kilo"}] | | |
| | {"p": 1, | | |
| | "q": 2, | | |
| | "r": 3, | | |
| | "s": 5, | | |
| | "t": {"u": | | |
| | 6}} | | |
+------------------+--------------+-------------+-------------------+
| $[?@[?@.b]] | [3, 5, 1, | $['a'] | Nested filters |
| | 2, 4, 6, | | |
| | {"b": "j"}, | | |
| | {"b": "k"}, | | |
| | {"b": {}}, | | |
| | {"b": | | |
| | "kilo"}] | | |
+------------------+--------------+-------------+-------------------+
| $.o[?@<3, ?@<3] | 1 | $['o']['p'] | Non-deterministic |
| | 2 | $['o']['q'] | ordering |
| | 2 | $['o']['q'] | |
| | 1 | $['o']['p'] | |
+------------------+--------------+-------------+-------------------+
| $.a[?@<2 || @.b | 1 | $['a'][2] | Array value |
| == "k"] | {"b": "k"} | $['a'][7] | logical OR |
+------------------+--------------+-------------+-------------------+
| $.a[?match(@.b, | {"b": "j"} | $['a'][6] | Array value |
| "[jk]")] | {"b": "k"} | $['a'][7] | regular |
| | | | expression match |
+------------------+--------------+-------------+-------------------+
| $.a[?search(@.b, | {"b": "j"} | $['a'][6] | Array value |
| "[jk]")] | {"b": "k"} | $['a'][7] | regular |
| | {"b": | $['a'][9] | expression search |
| | "kilo"} | | |
+------------------+--------------+-------------+-------------------+
| $.o[?@>1 && @<4] | 2 | $['o']['q'] | Object value |
| | 3 | $['o']['r'] | logical AND |
+------------------+--------------+-------------+-------------------+
| $.o[?@>1 && @<4] | 3 | $['o']['r'] | Alternative |
| | 2 | $['o']['q'] | result |
+------------------+--------------+-------------+-------------------+
| $.o[?@.u || @.x] | {"u": 6} | $['o']['t'] | Object value |
| | | | logical OR |
+------------------+--------------+-------------+-------------------+
| $.a[?@.b == $.x] | 3 | $['a'][0] | Comparison of |
| | 5 | $['a'][1] | queries with no |
| | 1 | $['a'][2] | values |
| | 2 | $['a'][3] | |
| | 4 | $['a'][4] | |
| | 6 | $['a'][5] | |
+------------------+--------------+-------------+-------------------+
| $.a[?@ == @] | 3 | $['a'][0] | Comparisons of |
| | 5 | $['a'][1] | primitive and of |
| | 1 | $['a'][2] | structured values |
| | 2 | $['a'][3] | |
| | 4 | $['a'][4] | |
| | 6 | $['a'][5] | |
| | {"b": "j"} | $['a'][6] | |
| | {"b": "k"} | $['a'][7] | |
| | {"b": {}} | $['a'][8] | |
| | {"b": | $['a'][9] | |
| | "kilo"} | | |
+------------------+--------------+-------------+-------------------+
Table 12: Filter Selector Examples
表12：フィルターセレクターの例
The example above with the query $.o[?@<3, ?@<3] shows that a filter selector may produce nodelists in distinct orders each time it appears in the child segment.
Query $ .o [？@<3、？@<3]の上記の例は、フィルターセレクターが子セグメントに表示されるたびに別個の順序でノデリストを生成する可能性があることを示しています。
Beyond the filter expression functionality defined in the preceding subsections, JSONPath defines an extension point that can be used to add filter expression functionality: "Function Extensions".
前述のサブセクションで定義されているフィルター式の機能性を超えて、JSonPathは、フィルター式の機能性「関数拡張」を追加するために使用できる拡張ポイントを定義します。
This section defines the extension point and some function extensions that use this extension point. While these mechanisms are designed to use the extension point, they are an integral part of the JSONPath specification and are expected to be implemented like any other integral part of this specification.
このセクションでは、この拡張ポイントを使用する拡張ポイントといくつかの関数拡張機能を定義します。これらのメカニズムは拡張ポイントを使用するように設計されていますが、JSONPATH仕様の不可欠な部分であり、この仕様の他の不可欠な部分と同様に実装されると予想されます。
A function extension defines a registered name (see Section 3.2) that can be applied to a sequence of zero or more arguments, producing a result. Each registered function name is unique.
関数拡張は、ゼロ以上の引数のシーケンスに適用できる登録名（セクション3.2を参照）を定義し、結果を生成します。各登録機能名は一意です。
A function extension MUST be defined such that its evaluation is free of side effects, i.e., all possible orders of evaluation and choices of short-circuiting or full evaluation of an expression containing it MUST lead to the same result. (Note: Memoization or logging are not side effects in this sense as they are visible at the implementation level only -- they do not influence the result of the evaluation.)
機能拡張は、その評価に副作用がないように定義する必要があります。つまり、すべての可能な評価の順序と短絡またはそれを含む式の完全な評価の選択は、同じ結果につながる必要があります。（注：メモ化またはロギングは、実装レベルのみで表示されるため、この意味では副作用ではありません。評価の結果には影響しません。）
function-name = function-name-first *function-name-char
function-name-first = LCALPHA
function-name-char = function-name-first / "_" / DIGIT
LCALPHA = %x61-7A ; "a".."z"
function-expr = function-name "(" S [function-argument
*(S "," S function-argument)] S ")"
function-argument = literal /
filter-query / ; (includes singular-query)
logical-expr /
function-expr
Any function expressions in a query must be well-formed (by conforming to the above ABNF) and well-typed; otherwise, the JSONPath implementation MUST raise an error (see Section 2.1). To define which function expressions are well-typed, a type system is first introduced.
クエリ内の関数式は、（上記のABNFに準拠することにより）よく形成され、よくタイプ化する必要があります。それ以外の場合、JSONPATHの実装ではエラーが発生する必要があります（セクション2.1を参照）。どの関数式がよくタイプであるかを定義するために、タイプシステムが最初に導入されます。
Each parameter and the result of a function extension must have a declared type.
各パラメーターと関数拡張の結果には、宣言されたタイプが必要です。
Declared types enable checking a JSONPath query for well-typedness independent of any query argument the JSONPath query is applied to.
宣言されたタイプを有効にして、jsonpathクエリが適用されるクエリ引数とは無関係に、jsonpathクエリをチェックします。
Table 13 defines the available types in terms of the instances they contain.
表13は、入手可能なタイプを含むインスタンスの観点から定義しています。
+=============+=============================+
| Type | Instances |
+=============+=============================+
| ValueType | JSON values or Nothing |
+-------------+-----------------------------+
| LogicalType | LogicalTrue or LogicalFalse |
+-------------+-----------------------------+
| NodesType | Nodelists |
+-------------+-----------------------------+
Table 13: Function Extension Type System
表13：関数拡張タイプシステム
Notes:
ノート：
* The only instances that can be directly represented in JSONPath syntax are certain JSON values in ValueType expressed as literals (which, in JSONPath, are limited to primitive values).
* JSONPATH構文で直接表現できる唯一のインスタンスは、リテラルとして表されるValuETypeの特定のJSON値です（JSONPATHでは、プリミティブ値に限定されています）。
* The special result Nothing represents the absence of a JSON value and is distinct from any JSON value, including null.
* 特別な結果は、JSON値がないことを表し、NULLを含むJSON値とは異なります。
* LogicalTrue and LogicalFalse are unrelated to the JSON values expressed by the literals true and false.
* LogicalTrueと論理ファルスは、リテラルによって表されるJSON値とは無関係です。
Just as queries can be used in logical expressions by testing for the existence of at least one node (Section 2.3.5.2.1), a function expression of declared type NodesType can be used as a function argument for a parameter of declared type LogicalType, with the equivalent conversion rule:
少なくとも1つのノードの存在（セクション2.3.5.2.1）の存在をテストすることにより、論理式でクエリを使用できるように、宣言されたタイプNodestypeの関数式は、宣言された型論理タイプのパラメーターの関数引数として使用できます。同等の変換ルールで：
* If the nodelist contains one or more nodes, the conversion result is LogicalTrue.
* ノデリストに1つ以上のノードが含まれている場合、変換結果は論理的なものです。
* If the nodelist is empty, the conversion result is LogicalFalse.
* ノデリストが空の場合、変換結果は論理ファルスです。
Notes:
ノート：
* Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from NodesType to ValueType may be surprising and has therefore not been defined.
* ノデリストからの値の抽出はいくつかの方法で実行できます。したがって、NodestypeからValueTypeへの暗黙的な変換は驚くべきものである可能性があるため、定義されていません。
* A function expression with a declared type of NodesType can indirectly be used as an argument for a parameter of declared type ValueType by wrapping the expression in a call to a function extension, such as value() (see Section 2.4.8), that takes a parameter of type NodesType and returns a result of type ValueType.
* 宣言されたタイプのnodestypeを使用した関数式は、value（）などの関数拡張機能に式を包むことにより、宣言されたタイプValueTypeのパラメーターの引数として間接的に使用できます（セクション2.4.8を参照）。型nodestypeのパラメーターであり、型ValueTypeの結果を返します。
The well-typedness of function expressions can now be defined in terms of this type system.
関数式のよくタイプ性は、このタイプシステムの観点から定義できるようになりました。
For a function expression to be well-typed:
関数式が十分にタイプであるために：
1. Its declared type must be well-typed in the context in which it occurs.
1. その宣言されたタイプは、それが発生するコンテキストではよくタイプでなければなりません。
1. As per the grammar, a function expression can occur in three different immediate contexts, which lead to the following conditions for well-typedness:
1. 文法によると、関数式は3つの異なる直接的なコンテキストで発生する可能性があります。
As a test-expr in a logical expression:
論理式のテストexprとして：
The function's declared result type is LogicalType or (giving rise to conversion as per Section 2.4.2) NodesType.
関数の宣言された結果タイプは、論理タイプまたは（セクション2.4.2に従って変換の発生を与えます）nodestypeです。
As a comparable in a comparison:
比較で同等のものとして：
The function's declared result type is ValueType.
関数の宣言された結果タイプはValueTypeです。
As a function-argument in another function expression:
別の関数式の関数のアリグメントとして：
The function's declared result type fulfills the following rules for the corresponding parameter of the enclosing function.
関数の宣言された結果タイプは、囲まれた関数の対応するパラメーターの次のルールを満たします。
2. Its arguments must be well-typed for the declared type of the corresponding parameters.
2. その議論は、対応するパラメーターの宣言されたタイプに対して十分にタイプでなければなりません。
2. The arguments of the function expression are well-typed when each argument of the function can be used for the declared type of the corresponding parameter, according to one of the following conditions:
2. 関数式の引数は、次の条件のいずれかに従って、関数の各引数を対応するパラメーターの宣言されたタイプに使用できる場合、よくタイプされています。
* When the argument is a function expression with the same declared result type as the declared type of the parameter.
* 引数がパラメーターの宣言されたタイプと同じ宣言された結果タイプを持つ関数式である場合。
* When the declared type of the parameter is LogicalType and the argument is one of the following:
* 宣言されたタイプのパラメーターが論理タイプであり、引数が次のいずれかである場合：
- A function expression with declared result type NodesType. In this case, the argument is converted to LogicalType as per Section 2.4.2.
- 宣言された結果型nodestypeを使用した関数式。この場合、引数はセクション2.4.2に従って論理タイプに変換されます。
- A logical-expr that is not a function expression.
- 関数式ではない論理expr。
* When the declared type of the parameter is NodesType and the argument is a query (which includes singular query).
* 宣言されたパラメーターのタイプがnodestypeであり、引数はクエリ（特異クエリを含む）である場合。
* When the declared type of the parameter is ValueType and the argument is one of the following:
* 宣言されたタイプのパラメーターがValuETypeであり、引数が次のいずれかである場合：
- A value expressed as a literal.
- 文字通りとして表される値。
- A singular query. In this case:
- 特異なクエリ。この場合：
o If the query results in a nodelist consisting of a single node, the argument is the value of the node.
o クエリが単一のノードで構成されるノデリストになった場合、引数はノードの値です。
o If the query results in an empty nodelist, the argument is the special result Nothing.
o クエリが空のノデリストになった場合、引数は特別な結果ではありません。
Parameters:
パラメーター：
1. ValueType
1. ValueType
Result:
結果：
ValueType (unsigned integer or Nothing)
ValueType（符号なし整数または何もない）
The length() function extension provides a way to compute the length of a value and make that available for further processing in the filter expression:
長さ（）関数拡張は、値の長さを計算し、フィルター式でさらに処理できるようにする方法を提供します。
$[?length(@.authors) >= 5]
Its only argument is an instance of ValueType (possibly taken from a singular query, as in the example above). The result is also an instance of ValueType: an unsigned integer or the special result Nothing.
その唯一の引数は、ValueTypeのインスタンスです（上記の例のように、おそらく特異なクエリから取られた可能性があります）。結果は、ValueTypeのインスタンスでもあります。署名されていない整数または特別な結果は何もありません。
* If the argument value is a string, the result is the number of Unicode scalar values in the string.
* 引数値が文字列の場合、結果は文字列内のUnicodeスカラー値の数になります。
* If the argument value is an array, the result is the number of elements in the array.
* 引数値が配列の場合、結果は配列内の要素の数になります。
* If the argument value is an object, the result is the number of members in the object.
* 引数値がオブジェクトである場合、結果はオブジェクト内のメンバーの数になります。
* For any other argument value, the result is the special result Nothing.
* 他の引数値については、結果は特別な結果ではありません。
Parameters:
パラメーター：
1. NodesType
1. nodestype
Result:
結果：
ValueType (unsigned integer)
ValueType（符号なし整数）
The count() function extension provides a way to obtain the number of nodes in a nodelist and make that available for further processing in the filter expression:
count（）関数拡張は、ノデリストのノードの数を取得し、それをフィルター式でさらに処理できるようにする方法を提供します。
$[?count(@.*.author) >= 5]
Its only argument is a nodelist. The result is a value (an unsigned integer) that gives the number of nodes in the nodelist.
その唯一の議論はノデリストです。結果は、ノデリストにノードの数を与える値（署名されていない整数）です。
Notes:
ノート：
* There is no deduplication of the nodelist.
* ノデリストの重複はありません。
* The number of nodes in the nodelist is counted independent of their values or any children they may have, e.g., the count of a non-empty singular nodelist such as count(@) is always 1.
* ノデリストのノードの数は、その価値や、たとえば、count（@）などの非空白の特異なノデリストのカウントとは無関係にカウントされます。
Parameters:
パラメーター：
1. ValueType (string)
1. ValueType（文字列）
2. ValueType (string conforming to [RFC9485])
2. ValueType（[RFC9485]に準拠する文字列）
Result:
結果：
LogicalType
LogicalType
The match() function extension provides a way to check whether (the entirety of; see Section 2.4.7) a given string matches a given regular expression, which is in the form described in [RFC9485].
一致（）関数拡張は、[RFC9485]で説明されている形式である特定の正規表現と一致するかどうか（セクション2.4.7を参照）かどうかを確認する方法を提供します。
$[?match(@.date, "1974-05-..")]
Its arguments are instances of ValueType (possibly taken from a singular query, as for the first argument in the example above). If the first argument is not a string or the second argument is not a string conforming to [RFC9485], the result is LogicalFalse. Otherwise, the string that is the first argument is matched against the I-Regexp contained in the string that is the second argument; the result is LogicalTrue if the string matches the I-Regexp and is LogicalFalse otherwise.
その引数は、ValueTypeのインスタンスです（上記の例の最初の引数のように、おそらく特異なクエリから取られた）。最初の引数が文字列ではない場合、または2番目の引数が[rfc9485]に準拠する文字列ではない場合、結果は論理falseです。それ以外の場合、最初の引数である文字列は、2番目の引数である文字列に含まれるi-regexpと一致します。結果は、文字列がi-regexpと一致し、それ以外の場合は論理falseである場合に論理的なものになります。
Parameters:
パラメーター：
1. ValueType (string)
1. ValueType（文字列）
2. ValueType (string conforming to [RFC9485])
2. ValueType（[RFC9485]に準拠する文字列）
Result:
結果：
LogicalType
LogicalType
The search() function extension provides a way to check whether a given string contains a substring that matches a given regular expression, which is in the form described in [RFC9485].
検索（）関数拡張は、特定の文字列に、[RFC9485]で説明されている形式である特定の正規表現と一致するサブストリングが含まれているかどうかを確認する方法を提供します。
$[?search(@.author, "[BR]ob")]
Its arguments are instances of ValueType (possibly taken from a singular query, as for the first argument in the example above). If the first argument is not a string or the second argument is not a string conforming to [RFC9485], the result is LogicalFalse. Otherwise, the string that is the first argument is searched for a substring that matches the I-Regexp contained in the string that is the second argument; the result is LogicalTrue if at least one such substring exists and is LogicalFalse otherwise.
その引数は、ValueTypeのインスタンスです（上記の例の最初の引数のように、おそらく特異なクエリから取られた）。最初の引数が文字列ではない場合、または2番目の引数が[rfc9485]に準拠する文字列ではない場合、結果は論理falseです。それ以外の場合、最初の引数である文字列は、2番目の引数である文字列に含まれるi-regexpに一致するサブストリングを検索します。そのようなサブストリングが少なくとも1つ存在し、それ以外の場合は論理ファルスである場合、結果は論理的なものになります。
Parameters:
パラメーター：
1. NodesType
1. nodestype
Result:
結果：
ValueType
ValueType
The value() function extension provides a way to convert an instance of NodesType to a value and make that available for further processing in the filter expression:
値（）関数拡張は、nodestypeのインスタンスを値に変換し、フィルター式でさらに処理できるようにする方法を提供します。
$[?value(@..color) == "red"]
Its only argument is an instance of NodesType (possibly taken from a filter-query, as in the example above). The result is an instance of ValueType.
その唯一の引数は、nodestypeのインスタンスです（上記の例のように、フィルタークエリから採取される可能性があります）。結果は、ValuETypeのインスタンスです。
* If the argument contains a single node, the result is the value of the node.
* 引数に単一のノードが含まれている場合、結果はノードの値です。
* If the argument is the empty nodelist or contains multiple nodes, the result is Nothing.
* 引数が空のノデリストであるか、複数のノードが含まれている場合、結果は何もありません。
Note: A singular query may be used anywhere where a ValueType is expected, so there is no need to use the value() function extension with a singular query.
注：valueTypeが予想される場所では、特異なクエリをどこでも使用できるため、singularクエリでvalue（）関数拡張を使用する必要はありません。
+======================+==========================================+
| Query | Comment |
+======================+==========================================+
| $[?length(@) < 3] | well-typed |
+----------------------+------------------------------------------+
| $[?length(@.*) < 3] | not well-typed since @.* is a non- |
| | singular query |
+----------------------+------------------------------------------+
| $[?count(@.*) == 1] | well-typed |
+----------------------+------------------------------------------+
| $[?count(1) == 1] | not well-typed since 1 is not a query or |
| | function expression |
+----------------------+------------------------------------------+
| $[?count(foo(@.*)) | well-typed, where foo() is a function |
| == 1] | extension with a parameter of type |
| | NodesType and result type NodesType |
+----------------------+------------------------------------------+
| $[?match(@.timezone, | well-typed |
| 'Europe/.*')] | |
+----------------------+------------------------------------------+
| $[?match(@.timezone, | not well-typed as LogicalType may not be |
| 'Europe/.*') == | used in comparisons |
| true] | |
+----------------------+------------------------------------------+
| $[?value(@..color) | well-typed |
| == "red"] | |
+----------------------+------------------------------------------+
| $[?value(@..color)] | not well-typed as ValueType may not be |
| | used in a test expression |
+----------------------+------------------------------------------+
| $[?bar(@.a)] | well-typed for any function bar() with a |
| | parameter of any declared type and |
| | result type LogicalType |
+----------------------+------------------------------------------+
| $[?bnl(@.*)] | well-typed for any function bnl() with a |
| | parameter of declared type NodesType or |
| | LogicalType and result type LogicalType |
+----------------------+------------------------------------------+
| $[?blt(1==1)] | well-typed, where blt() is a function |
| | with a parameter of declared type |
| | LogicalType and result type LogicalType |
+----------------------+------------------------------------------+
| $[?blt(1)] | not well-typed for the same function |
| | blt(), as 1 is not a query, logical- |
| | expr, or function expression |
+----------------------+------------------------------------------+
| $[?bal(1)] | well-typed, where bal() is a function |
| | with a parameter of declared type |
| | ValueType and result type LogicalType |
+----------------------+------------------------------------------+
Table 14: Function Expression Examples
表14：関数式の例
For each node in an input nodelist, segments apply one or more selectors to the node and concatenate the results of each selector into per-input-node nodelists, which are then concatenated in the order of the input nodelist to form a single segment result nodelist.
入力ノデリストの各ノードについて、セグメントは1つ以上のセレクターをノードに適用し、各セレクターの結果を入力ノードごとのノデリストに連結し、入力ノデリストの順に連結して単一のセグメント結果ノデリストを形成します。
It turns out that the more segments there are in a query, the greater the depth in the input value of the nodes of the resultant nodelist:
クエリにセグメントが多いほど、結果のノデリストのノードの入力値の深さが大きくなることがわかります。
* A query with N segments, where N >= 0, produces a nodelist consisting of nodes at depth in the input value of N or greater.
* n> = 0では、n> = 0のnセグメントを使用したクエリは、n以上の入力値の深さのノードで構成されるノデリストを生成します。
* A query with N segments, where N >= 0, all of which are child segments (Section 2.5.1), produces a nodelist consisting of nodes precisely at depth N in the input value.
* n> = 0のnセグメントを使用したクエリは、すべての子セグメント（セクション2.5.1）であり、入力値の深さnでのノードからなるノードから構成されるノデリストを生成します。
There are two kinds of segments: child segments and descendant segments.
セグメントには2種類のセグメントがあります。子セグメントと子孫セグメントです。
segment = child-segment / descendant-segment
The syntax and semantics of each kind of segment are defined below.
各種類のセグメントの構文とセマンティクスを以下に定義します。
The child segment consists of a non-empty, comma-separated sequence of selectors enclosed in square brackets.
子セグメントは、四角い括弧に囲まれたセレクターの空白されていないコンマ区切りのシーケンスで構成されています。
Shorthand notations are also provided for when there is a single wildcard or name selector.
Shorthand表記は、単一のワイルドカードまたは名前セレクターがある場合にも提供されます。
child-segment = bracketed-selection /
("."
(wildcard-selector /
member-name-shorthand))
bracketed-selection = "[" S selector *(S "," S selector) S "]"
member-name-shorthand = name-first *name-char
name-first = ALPHA /
"_" /
%x80-D7FF /
; skip surrogate code points
%xE000-10FFFF
name-char = name-first / DIGIT
DIGIT = %x30-39 ; 0-9
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
.*, a child-segment directly built from a wildcard-selector, is shorthand for [*].
。*、ワイルドカードセレクターから直接作られた子セグメントは、[*]の略記です。
.<member-name>, a child-segment built from a member-name-shorthand, is shorthand for ['<member-name>']. Note: This can only be used with member names that are composed of certain characters, as specified in the ABNF rule member-name-shorthand. Thus, for example, $.foo.bar is shorthand for $['foo']['bar'] (but not for $['foo.bar']).
。<member-name>は、メンバー名のショートンで構築された子セグメントであり、['<member-name>']の速記です。注：これは、ABNF Rule Member-Name-Shorthandで指定されているように、特定の文字で構成されるメンバー名でのみ使用できます。したがって、たとえば、$ .foo.barは$ ['foo'] ['bar']の速記です（ただし、$ ['foo.bar']ではありません）。
A child segment contains a sequence of selectors, each of which selects zero or more children of the input value.
子セグメントには、各セレクターのシーケンスが含まれており、それぞれが入力値のゼロ以上の子供を選択します。
Selectors of different kinds may be combined within a single child segment.
異なる種類のセレクターは、単一の子セグメント内で組み合わせることができます。
For each node in the input nodelist, the resulting nodelist of a child segment is the concatenation of the nodelists from each of its selectors in the order that the selectors appear in the list. Note: Any node matched by more than one selector is kept as many times in the nodelist.
入力ノデリストの各ノードについて、結果の子セグメントの結果として得られるノデリストは、セレクターがリストに表示される順に、各セレクターからのノデリストの連結です。注：複数のセレクターによって一致するノードは、ノデリストに何度も保持されます。
Where a selector can produce a nodelist in more than one possible order, each occurrence of the selector in the child segment may produce a nodelist in a distinct order.
セレクターが複数の可能な順序でノデリストを生成できる場合、子セグメント内のセレクターの各発生は、明確な順序でノデリストを生成する場合があります。
In summary, a child segment drills down one more level into the structure of the input value.
要約すると、子セグメントが入力値の構造にもう1つのレベルを掘り下げます。
JSON:
JSON：
["a", "b", "c", "d", "e", "f", "g"]
Queries:
クエリ：
+========+========+========+============+
| Query | Result | Result | Comment |
| | | Paths | |
+========+========+========+============+
| $[0, | "a" | $[0] | Indices |
| 3] | "d" | $[3] | |
+--------+--------+--------+------------+
| $[0:2, | "a" | $[0] | Slice and |
| 5] | "b" | $[1] | index |
| | "f" | $[5] | |
+--------+--------+--------+------------+
| $[0, | "a" | $[0] | Duplicated |
| 0] | "a" | $[0] | entries |
+--------+--------+--------+------------+
Table 15: Child Segment Examples
表15：子セグメントの例
The descendant segment consists of a double dot .. followed by a child segment (using bracket notation).
子孫セグメントは、2倍のドットで構成されています。その後、子セグメントが続きます（ブラケット表記を使用）。
Shorthand notations are also provided that correspond to the shorthand forms of the child segment.
また、子供セグメントの速記形式に対応する速記表記も提供されます。
descendant-segment = ".." (bracketed-selection /
wildcard-selector /
member-name-shorthand)
..*, the descendant-segment directly built from a wildcard-selector, is shorthand for ..[*].
..*、ワイルドカードセレクターから直接構築された子孫セグメントは、[*]の速記です。
..<member-name>, a descendant-segment built from a member-name-shorthand, is shorthand for ..['<member-name>']. Note: As with the similar shorthand of a child-segment, this can only be used with member names that are composed of certain characters, as specified in the ABNF rule member-name-shorthand.
.. <member-name>、メンバー名のショーサンドから構築された子孫セグメントは、.. ['<member-name>']の速記です。注：子セグメントの同様の速記と同様に、これは、ABNFルールメンバーノームショーサンドで指定されているように、特定の文字で構成されるメンバー名でのみ使用できます。
Note: On its own, .. is not a valid segment.
注：それ自体では、..は有効なセグメントではありません。
A descendant segment produces zero or more descendants of an input value.
子孫セグメントは、入力値のゼロ以上の子孫を生成します。
For each node in the input nodelist, a descendant selector visits the input node and each of its descendants such that:
入力ノデリストの各ノードについて、子孫セレクターが入力ノードとその子孫のそれぞれにアクセスして、次のようにアクセスします。
* nodes of any array are visited in array order, and
* 任意の配列のノードは、配列の順序で訪問され、
* nodes are visited before their descendants.
* ノードは子孫の前に訪問されます。
The order in which the children of an object are visited is not stipulated, since JSON objects are unordered.
JSONオブジェクトは順序付けられていないため、オブジェクトの子供が訪問する順序は規定されていません。
Suppose the descendant segment is of the form ..[<selectors>] (after converting any shorthand form to bracket notation), and the nodes, in the order visited, are D1, ..., Dn (where n >= 1). Note: D1 is the input value.
子孫セグメントがフォームであるとします。。注：D1は入力値です。
For each i such that 1 <= i <= n, the nodelist Ri is defined to be a result of applying the child segment [<selectors>] to the node Di.
1 <= i <= nのようなiの場合、ノデリストRIは、子セグメント[<electors>]をノードdiに適用した結果であると定義されます。
For each node in the input nodelist, the result of the descendant segment is the concatenation of R1, ..., Rn (in that order). These results are then concatenated in input nodelist order to form the result of the segment.
入力ノデリストの各ノードについて、子孫セグメントの結果はR1、...、RN（その順序で）の連結です。これらの結果は、入力ノデリスト順序で連結され、セグメントの結果を形成します。
In summary, a descendant segment drills down one or more levels into the structure of each input value.
要約すると、子孫セグメントは、各入力値の構造に1つ以上のレベルを掘削します。
JSON:
JSON：
{
"o": {"j": 1, "k": 2},
"a": [5, 3, [{"j": 4}, {"k": 6}]]
}
Queries:
クエリ：
(Note that the fourth example can be expressed in two equivalent queries, shown in Table 16 in one table row instead of two almost-identical rows.)
（4番目の例は、2つのほぼ同一の行ではなく、1つのテーブル行に表16に示す2つの同等のクエリで表現できることに注意してください。）
+==========+================+===================+===================+
| Query | Result | Result Paths | Comment |
+==========+================+===================+===================+
| $..j | 1 | $['o']['j'] | Object values |
| | 4 | $['a'][2][0]['j'] | |
+----------+----------------+-------------------+-------------------+
| $..j | 4 | $['a'][2][0]['j'] | Alternative |
| | 1 | $['o']['j'] | result |
+----------+----------------+-------------------+-------------------+
| $..[0] | 5 | $['a'][0] | Array values |
| | {"j": 4} | $['a'][2][0] | |
+----------+----------------+-------------------+-------------------+
| $..[*] | {"j": 1, | $['o'] | All values |
| or | "k": 2} | $['a'] | |
| $..* | [5, 3, | $['o']['j'] | |
| | [{"j": 4}, | $['o']['k'] | |
| | {"k": 6}]] | $['a'][0] | |
| | 1 | $['a'][1] | |
| | 2 | $['a'][2] | |
| | 5 | $['a'][2][0] | |
| | 3 | $['a'][2][1] | |
| | [{"j": 4}, | $['a'][2][0]['j'] | |
| | {"k": 6}] | $['a'][2][1]['k'] | |
| | {"j": 4} | | |
| | {"k": 6} | | |
| | 4 | | |
| | 6 | | |
+----------+----------------+-------------------+-------------------+
| $..o | {"j": 1, | $['o'] | Input value is |
| | "k": 2} | | visited |
+----------+----------------+-------------------+-------------------+
| $.o..[*, | 1 | $['o']['j'] | Non-deterministic |
| *] | 2 | $['o']['k'] | ordering |
| | 2 | $['o']['k'] | |
| | 1 | $['o']['j'] | |
+----------+----------------+-------------------+-------------------+
| $.a..[0, | 5 | $['a'][0] | Multiple segments |
| 1] | 3 | $['a'][1] | |
| | {"j": 4} | $['a'][2][0] | |
| | {"k": 6} | $['a'][2][1] | |
+----------+----------------+-------------------+-------------------+
Table 16: Descendant Segment Examples
表16：子孫セグメントの例
Note: The ordering of the results for the $..[*] and $..* examples above is not guaranteed, except that:
注：$ .. [*]および$ ..*の結果の順序付けは、次のことを除いて保証されていません。
* {"j": 1, "k": 2} must appear before 1 and 2,
* {"j"：1、 "k"：2}は、1と2の前に表示されなければなりません、
* [5, 3, [{"j": 4}, {"k": 6}]] must appear before 5, 3, and [{"j": 4}, {"k": 6}],
* [5、3、[{"j"：4}、{"k"：6}]]が5、3、および[{"j"：4}、{"k"：6}]、[{"j"：4}、
* 5 must appear before 3, which must appear before [{"j": 4}, {"k": 6}],
* 5は3より前に表示されなければなりません。
* 5 and 3 must appear before {"j": 4}, 4, {"k": 6}, and 6,
* 5と3は{"j"：4}、4、{"k"：6}、および6の前に表示されなければなりません。
* [{"j": 4}, {"k": 6}] must appear before {"j": 4} and {"k": 6},
* [{"j"：4}、{"k"：6}]は、{"j"：4}および{"k"：6}の前に表示されなければなりません。
* {"j": 4} must appear before {"k": 6},
* {"j"：4}は{"k"：6}の前に表示されなければなりません。
* {"k": 6} must appear before 4, and
* {"k"：6}は4前に表示され、
* 4 must appear before 6.
* 4は6より前に表示する必要があります。
The example above with the query $.o..[*, *] shows that a selector may produce nodelists in distinct orders each time it appears in the descendant segment.
Query $ .o .. [ *、 *]の上記の例は、セレクターが子孫セグメントに表示されるたびに別個の順序でノデリストを生成できることを示しています。
The example above with the query $.a..[0, 1] shows that the child segment [0, 1] is applied to each node in turn (rather than the nodes being visited once per selector, which is the case for some JSONPath implementations that do not conform to this specification).
クエリ$ .A .. [0、1]の上記の例は、子セグメント[0、1]が各ノードに適用されることを示しています（セレクターごとに一度訪問されるノードではなく、一部の場合は一部の場合です。この仕様に準拠していないJSONPATHの実装）。
Note: JSON null is treated the same as any other JSON value, i.e., it is not taken to mean "undefined" or "missing".
注：JSON Nullは、他のJSON値と同じように扱われます。つまり、「未定義」または「欠落」を意味するとは見なされません。
JSON:
JSON：
{"a": null, "b": [null], "c": [{}], "null": 1}
Queries:
クエリ：
+=================+========+===========+===========================+
| Query | Result | Result | Comment |
| | | Paths | |
+=================+========+===========+===========================+
| $.a | null | $['a'] | Object value |
+-----------------+--------+-----------+---------------------------+
| $.a[0] | | | null used as array |
+-----------------+--------+-----------+---------------------------+
| $.a.d | | | null used as object |
+-----------------+--------+-----------+---------------------------+
| $.b[0] | null | $['b'][0] | Array value |
+-----------------+--------+-----------+---------------------------+
| $.b[*] | null | $['b'][0] | Array value |
+-----------------+--------+-----------+---------------------------+
| $.b[?@] | null | $['b'][0] | Existence |
+-----------------+--------+-----------+---------------------------+
| $.b[?@==null] | null | $['b'][0] | Comparison |
+-----------------+--------+-----------+---------------------------+
| $.c[?@.d==null] | | | Comparison with "missing" |
| | | | value |
+-----------------+--------+-----------+---------------------------+
| $.null | 1 | $['null'] | Not JSON null at all, |
| | | | just a member name string |
+-----------------+--------+-----------+---------------------------+
Table 17: Examples Involving (or Not Involving) null
表17：nullを含む（または関与しない）例
A Normalized Path is a unique representation of the location of a node in a value that uniquely identifies the node in the value. Specifically, a Normalized Path is a JSONPath query with restricted syntax (defined below), e.g., $['book'][3], which when applied to the value, results in a nodelist consisting of just the node identified by the Normalized Path. Note: A Normalized Path represents the identity of a node _in a specific value_. There is precisely one Normalized Path identifying any particular node in a value.
正規化されたパスとは、値のノードを一意に識別する値のノードの位置のユニークな表現です。具体的には、正規化されたパスは、制限付き構文（以下に定義）を備えたJSonPathクエリです。。注：正規化されたパスは、Node _in and and value _のIDを表します。値内の特定のノードを識別する正規化されたパスが正確に1つあります。
A nodelist may be represented compactly in JSON as an array of strings, where the strings are Normalized Paths.
ノデリストは、文字列が正規化されたパスである文字列の配列としてJSONでコンパクトに表現される場合があります。
Normalized Paths provide a predictable format that simplifies testing and post-processing of nodelists, e.g., to remove duplicate nodes. Normalized Paths are used in this document as result paths in examples.
正規化されたパスは、ノデリストのテストと後処理を簡素化する予測可能な形式を提供します。たとえば、複製ノードを削除します。このドキュメントでは、例の結果パスとして正規化されたパスが使用されています。
Normalized Paths use the canonical bracket notation, rather than dot notation.
正規化されたパスは、ドット表記ではなく、標準的なブラケット表記を使用します。
Single quotes are used in Normalized Paths to delimit string member names. This reduces the number of characters that need escaping when Normalized Paths appear in strings delimited by double quotes, e.g., in JSON texts.
単一の引用符は、文字列メンバー名を区切るために正規化されたパスで使用されます。これにより、正規化されたパスが二重引用符（たとえばJSONテキスト）で区切られた文字列に表示されるときに逃げる必要がある文字の数が減ります。
Certain characters are escaped in Normalized Paths in one and only one way; all other characters are unescaped.
特定の文字は、1つの方法で正規化されたパスで逃げられます。他のすべてのキャラクターは無効です。
Note: Normalized Paths are singular queries, but not all singular queries are Normalized Paths. For example, $[-3] is a singular query but is not a Normalized Path. The Normalized Path equivalent to $[-3] would have an index equal to the array length minus 3. (The array length must be at least 3 if $[-3] is to identify a node.)
注：正規化されたパスは特異なクエリですが、すべての特異なクエリが正規化されたパスではありません。たとえば、$ [3]は特異なクエリですが、正規化されたパスではありません。$ [-3]に相当する正規化されたパスは、アレイの長さをマイナス3に等しいインデックスを持ちます（$ [-3]がノードを識別する場合、アレイの長さは少なくとも3でなければなりません。）
normalized-path = root-identifier *(normal-index-segment)
normal-index-segment = "[" normal-selector "]"
normal-selector = normal-name-selector / normal-index-selector
normal-name-selector = %x27 *normal-single-quoted %x27 ; 'string'
normal-single-quoted = normal-unescaped /
ESC normal-escapable
normal-unescaped = ; omit %x0-1F control codes
%x20-26 /
; omit 0x27 '
%x28-5B /
; omit 0x5C \
%x5D-D7FF /
; skip surrogate code points
%xE000-10FFFF
normal-escapable = %x62 / ; b BS backspace U+0008
%x66 / ; f FF form feed U+000C
%x6E / ; n LF line feed U+000A
%x72 / ; r CR carriage return U+000D
%x74 / ; t HT horizontal tab U+0009
"'" / ; ' apostrophe U+0027
"\" / ; \ backslash (reverse solidus) U+005C
(%x75 normal-hexchar)
; certain values u00xx U+00XX
normal-hexchar = "0" "0"
(
("0" %x30-37) / ; "00"-"07"
; omit U+0008-U+000A BS HT LF
("0" %x62) / ; "0b"
; omit U+000C-U+000D FF CR
("0" %x65-66) / ; "0e"-"0f"
("1" normal-HEXDIG)
)
normal-HEXDIG = DIGIT / %x61-66 ; "0"-"9", "a"-"f"
normal-index-selector = "0" / (DIGIT1 *DIGIT)
; non-negative decimal integer
Since there can only be one Normalized Path identifying a given node, the syntax stipulates which characters are escaped and which are not. So the definition of normal-hexchar is designed for hex escaping of characters that are not straightforwardly printable, for example, U+000B LINE TABULATION, but for which no standard JSON escape, such as \n, is available.
特定のノードを識別する正規化されたパスは1つだけであるため、構文はどの文字が逃げられ、そうでないかを規定しています。したがって、通常のヘクサチャーの定義は、たとえばu 000bラインの集計など、簡単に印刷できない文字を逃れるために設計されていますが、\ nなどの標準のJSONエスケープは利用できません。
+=============+=================+==========================+
| Path | Normalized Path | Comment |
+=============+=================+==========================+
| $.a | $['a'] | Object value |
+-------------+-----------------+--------------------------+
| $[1] | $[1] | Array index |
+-------------+-----------------+--------------------------+
| $[-3] | $[2] | Negative array index for |
| | | an array of length 5 |
+-------------+-----------------+--------------------------+
| $.a.b[1:2] | $['a']['b'][1] | Nested structure |
+-------------+-----------------+--------------------------+
| $["\u000B"] | $['\u000b'] | Unicode escape |
+-------------+-----------------+--------------------------+
| $["\u0061"] | $['a'] | Unicode character |
+-------------+-----------------+--------------------------+
Table 18: Normalized Path Examples
表18：正規化されたパスの例
IANA has registered the following media type [RFC6838]:
IANAは、次のメディアタイプ[RFC6838]を登録しました。
Type name:
タイプ名：
application
応用アプリケーション出願塗布申請アプリ使用利用申込申し込み応募運用願い願い出要請控訴勉励丹念請求応用力適用業務
Subtype name:
サブタイプ名：
jsonpath
jsonpath
Required parameters:
必要なパラメーター：
N/A
n/a
Optional parameters:
オプションのパラメーター：
N/A
n/a
Encoding considerations:
考慮事項のエンコード：
binary (UTF-8)
バイナリ（UTF-8）
Security considerations:
セキュリティ上の考慮事項：
See the Security Considerations section of RFC 9535.
RFC 9535のセキュリティに関する考慮事項セクションを参照してください。
Interoperability considerations:
相互運用性の考慮事項：
N/A
n/a
Published specification:
公開された仕様：
RFC 9535
RFC 9535
Applications that use this media type:
このメディアタイプを使用するアプリケーション：
Applications that need to convey queries in JSON data
JSONデータにクエリを伝える必要があるアプリケーション
Fragment identifier considerations:
フラグメント識別子の考慮事項：
N/A
n/a
Additional information:
追加情報：
Deprecated alias names for this type:
このタイプの非推奨エイリアス名：
N/A
n/a
Magic number(s):
マジックナンバー：
N/A
n/a
File extension(s):
ファイル拡張子：
N/A
n/a
Macintosh file type code(s):
Macintoshファイルタイプコード：
N/A
n/a
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
iesg@ietf.org
iesg@ietf.org
Intended usage:
意図された使用法：
COMMON
一般
Restrictions on usage:
使用に関する制限：
N/A
n/a
Author:
著者：
JSONPath WG
JSonPath WG
Change controller:
Change Controller：
IETF
IETF
Per this specification, IANA has created a new "Function Extensions" subregistry in a new "JSONPath" registry. The "Function Extensions" subregistry has the policy "Expert Review" (Section 4.5 of [RFC8126]).
この仕様に従って、IANAは新しい「JSONPATH」レジストリに新しい「関数拡張」サブレジストリを作成しました。「関数拡張」サブレジストリには、「[RFC8126]のセクション4.5）があります。
The experts are instructed to be frugal in the allocation of function extension names that are suggestive of generally applicable semantics, keeping them in reserve for functions that are likely to enjoy wide use and can make good use of their conciseness. The expert is also instructed to direct the registrant to provide a specification (Section 4.6 of [RFC8126]) but can make exceptions, for instance, when a specification is not available at the time of registration but is likely forthcoming. If the expert becomes aware of function extensions that are deployed and in use, they may also initiate a registration on their own if they deem such a registration can avert potential future collisions.
専門家は、一般的に適用可能なセマンティクスを示唆する関数拡張名の割り当てに満足のいくものであるように指示され、幅広い使用を楽しむ可能性が高く、その簡潔さをうまく利用できる機能のためにそれらを保存し続けます。また、専門家は、登録者に仕様（[RFC8126]のセクション4.6）を提供するよう指示するように指示されますが、たとえば登録時に仕様が利用できないが、今後の仕様が利用可能である場合、例外を作成できます。専門家が展開され、使用中の関数拡張を認識した場合、そのような登録が潜在的な将来の衝突を回避できると判断した場合、独自に登録を開始することもあります。
Each entry in the subregistry must include the following:
サブレジストリの各エントリには、次のものを含める必要があります。
Function Name:
関数名：
A lowercase ASCII [RFC0020] string that starts with a letter and can contain letters, digits, and underscore characters afterwards ([a-z][_a-z0-9]*). No other entry in the subregistry can have the same function name.
手紙で始まり、その後文字、数字、およびアンダースコア文字を含めることができる小文字ASCII [RFC0020]文字列（[a-z] [_ a-z0-9]*）。サブレジストリの他のエントリは同じ関数名を持つことはできません。
Brief description:
簡単な説明：
A brief description
簡単な説明
Parameters:
パラメーター：
A comma-separated list of zero or more declared types, one for each of the arguments expected for this function extension
ゼロ以上の宣言されたタイプのコンマ分離されたリスト、この関数拡張に期待される各引数に1つ
Result:
結果：
The declared type of the result for this function extension
この関数拡張の結果の宣言されたタイプ
Change Controller:
Change Controller：
See Section 2.3 of [RFC8126].
[RFC8126]のセクション2.3を参照してください。
Reference:
参照：
A reference document that provides a description of the function extension
関数拡張の説明を提供する参照ドキュメント
The initial entries in this subregistry are listed in Table 19; the entries in the "Change Controller" column all have the value "IETF", and the entries in the "Reference" column all have the value "Section 2.4 of RFC 9535":
このサブレジストリの最初のエントリを表19に示します。「Change Controller」列のエントリにはすべて値「IETF」があり、「リファレンス」列のエントリにはすべてRFC 9535」のセクション2.4があります。
+===============+=====================+============+=============+
| Function Name | Brief Description | Parameters | Result |
+===============+=====================+============+=============+
| length | length of string, | ValueType | ValueType |
| | array, or object | | |
+---------------+---------------------+------------+-------------+
| count | size of nodelist | NodesType | ValueType |
+---------------+---------------------+------------+-------------+
| match | regular expression | ValueType, | LogicalType |
| | full match | ValueType | |
+---------------+---------------------+------------+-------------+
| search | regular expression | ValueType, | LogicalType |
| | substring match | ValueType | |
+---------------+---------------------+------------+-------------+
| value | value of the single | NodesType | ValueType |
| | node in nodelist | | |
+---------------+---------------------+------------+-------------+
Table 19: Initial Entries in the Function Extensions Subregistry
表19：関数エクステンションサブレジストリの初期エントリ
Security considerations for JSONPath can stem from:
JSonPathのセキュリティ上の考慮事項は次のとおりです。
* attack vectors on JSONPath implementations,
* jsonpathの実装でベクトルを攻撃し、
* attack vectors on how JSONPath queries are formed, and
* JsonPathのクエリがどのように形成されるかについてベクターを攻撃し、
* the way JSONPath is used in security-relevant mechanisms.
* JSONPATHがセキュリティ関連のメカニズムで使用される方法。
Historically, JSONPath has often been implemented by feeding parts of the query to an underlying programming language engine, e.g., JavaScript's eval() function. This approach is well known to lead to injection attacks and would require perfect input validation to prevent these attacks (see Section 12 of [RFC8259] for similar considerations for JSON itself). Instead, JSONPath implementations need to implement the entire syntax of the query without relying on the parsers of programming language engines.
歴史的に、JsonPathは、クエリの一部を基礎となるプログラミング言語エンジン、たとえばJavaScriptのEval（）関数にフィードすることにより、しばしば実装されてきました。このアプローチは、注射攻撃につながることがよく知られており、これらの攻撃を防ぐために完全な入力検証が必要になります（JSON自体についても同様の考慮事項については、[RFC8259]のセクション12を参照）。代わりに、JSONPATHの実装は、プログラミング言語エンジンのパーサーに依存せずに、クエリの構文全体を実装する必要があります。
Attacks on availability may attempt to trigger unusually expensive runtime performance exhibited by certain implementations in certain cases. (See Section 10 of [RFC8949] for issues in hash-table implementations and Section 8 of [RFC9485] for performance issues in regular expression implementations.) Implementers need to be aware that good average performance is not sufficient as long as an attacker can choose to submit specially crafted JSONPath queries or query arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example, via a naive recursive implementation of the descendant segment, stack overflow. Implementations need to have appropriate resource management to mitigate these attacks.
可用性に対する攻撃は、特定のケースで特定の実装によって示される異常に高価なランタイムパフォーマンスをトリガーしようとする場合があります。（ハッシュテーブル実装の問題については、[RFC8949]のセクション10および正規表現実装のパフォーマンスの問題については[RFC9485]については、[RFC8949]のセクション10を参照してください。）攻撃者が選択できる限り、良い平均パフォーマンスが十分ではないことに注意する必要があります。特別に作成されたJSonPathクエリまたはクエリの引数を提出するには、驚くほど高く、おそらく指数関数的なCPU使用量を引き起こし、たとえば、子孫セグメントの素朴な再帰実装であるスタックオーバーフローを介して提出します。実装は、これらの攻撃を軽減するために適切なリソース管理を持つ必要があります。
JSONPath queries are often not static but formed from variables that provide index values, member names, or values to compare with in a filter expression. These variables need to be validated (e.g., only allowing specific constructs such as .name to be formed when the given values allow that) and translated (e.g., by escaping string delimiters). Not performing these validations and translations correctly can lead to unexpected failures, which can lead to availability, confidentiality, and integrity breaches, in particular, if an adversary has control over the values (e.g., by entering them into a web form). The resulting class of attacks, _injections_ (e.g., SQL injections), is consistently found among the top causes of application security vulnerabilities and requires particular attention.
JSONPATHクエリは多くの場合、静的ではありませんが、フィルター式で比較するためにインデックス値、メンバー名、または値を提供する変数から形成されます。これらの変数を検証する必要があります（たとえば、指定された値が許可されたときに.NAMEなどの特定のコンストラクトを形成することを許可します）、および翻訳（例：文字列デリミターを脱出することによって）。これらの検証と翻訳を正しく実行しないと、予期しない障害につながる可能性があります。これは、特に敵が値を制御する場合（たとえば、Webフォームに入力することで）、可用性、機密性、および整合性侵害につながる可能性があります。結果のクラスの攻撃クラス_Injections_（例：SQLインジェクション）は、アプリケーションセキュリティの脆弱性の最大の原因の中に一貫して見られ、特に注意が必要です。
Where JSONPath is used as a part of a security mechanism, attackers can attempt to provoke unexpected or unpredictable behavior or take advantage of differences in behavior between JSONPath implementations.
JSONPATHがセキュリティメカニズムの一部として使用されている場合、攻撃者は予期しないまたは予測不可能な動作を引き起こすか、JSONPATH実装間の行動の違いを利用しようとします。
Unexpected or unpredictable behavior can arise from a query argument with certain constructs described as unpredictable by [RFC8259]. Predictable behavior can be expected, except in relation to the ordering of objects, for any query argument conforming with [RFC7493].
予期しないまたは予測不可能な動作は、[RFC8259]によって予測不可能であると説明される特定のコンストラクトを含むクエリ引数から生じる可能性があります。[RFC7493]に準拠しているクエリ引数について、オブジェクトの順序に関連して、予測可能な動作が予想されます。
Other attacks can target the behavior of underlying technologies, such as UTF-8 (see Section 10 of [RFC3629]) and the Unicode character set.
他の攻撃は、UTF-8（[RFC3629]のセクション10を参照）やユニコード文字セットなど、基礎となる技術の動作を標的にすることができます。
[RFC0020] Cerf, V., "ASCII format for network interchange", STD 80,
RFC 20, DOI 10.17487/RFC0020, October 1969,
<https://www.rfc-editor.org/info/rfc20>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<https://www.rfc-editor.org/info/rfc7493>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.
[RFC9485] Bormann, C. and T. Bray, "I-Regexp: An Interoperable
Regular Expression Format", RFC 9485,
DOI 10.17487/RFC9485, October 2023,
<https://www.rfc-editor.org/info/rfc9485>.
[UNICODE] The Unicode Consortium, "The Unicode® Standard",
<https://www.unicode.org/versions/latest/>. At the time
of writing,
<https://www.unicode.org/versions/Unicode15.0.0/
UnicodeStandard-15.0.pdf>.
[BOOLEAN-LAWS]
"Boolean algebra: Laws", December 2023,
<https://en.wikipedia.org/w/
index.php?title=Boolean_algebra&oldid=1191386550#Laws>.
[COMPARISON]
Burgmer, C., "JSONPath Comparison",
<https://cburgmer.github.io/json-path-comparison/>.
[E4X] ISO, "Information technology - ECMAScript for XML (E4X)
specification", Withdrawn, ISO/IEC 22537:2006, February
2006, <https://www.iso.org/standard/41002.html>. An
equivalent specification, also withdrawn, is available
from <https://ecma-international.org/publications-and-
standards/standards/ ecma-357>.
[ECMA-262] ECMA International, "ECMAScript Language Specification",
Standard ECMA-262, Third Edition, December 1999,
<https://www.ecma-international.org/wp-content/uploads/
ECMA-262_3rd_edition_december_1999.pdf>.
[JSONPath-orig]
Gössner, S., "JSONPath - XPath for JSON", February 2007,
<https://goessner.net/articles/JsonPath/>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[SLICE] "Slice notation", commit 82f95b4, July 2022,
<https://github.com/tc39/proposal-slice-notation>.
[XPath] Berglund, A., Ed., Chamberlin, D., Ed., Simeon, J., Ed.,
Robie, J., Ed., Fernandez, M., Ed., Kay, M., Ed., and S.
Boag, Ed., "XML Path Language (XPath) 2.0 (Second
Edition)", W3C REC-xpath20-20101214, 14 December 2010,
<https://www.w3.org/TR/2010/REC-xpath20-20101214/>.
This appendix collects the ABNF grammar from the ABNF passages used throughout the document.
この付録は、ドキュメント全体で使用されるABNFパッセージからABNF文法を収集します。
Figure 2 contains the collected ABNF grammar that defines the syntax of a JSONPath query.
図2には、JSonPathクエリの構文を定義する収集されたABNF文法が含まれています。
jsonpath-query = root-identifier segments
segments = *(S segment)
B = %x20 / ; Space
%x09 / ; Horizontal tab
%x0A / ; Line feed or New line
%x0D ; Carriage return
S = *B ; optional blank space
root-identifier = "$"
selector = name-selector /
wildcard-selector /
slice-selector /
index-selector /
filter-selector
name-selector = string-literal
string-literal = %x22 *double-quoted %x22 / ; "string"
%x27 *single-quoted %x27 ; 'string'
double-quoted = unescaped /
%x27 / ; '
ESC %x22 / ; \"
ESC escapable
single-quoted = unescaped /
%x22 / ; "
ESC %x27 / ; \'
ESC escapable
ESC = %x5C ; \ backslash
unescaped = %x20-21 / ; see RFC 8259
; omit 0x22 "
%x23-26 /
; omit 0x27 '
%x28-5B /
; omit 0x5C \
%x5D-D7FF /
; skip surrogate code points
%xE000-10FFFF
escapable = %x62 / ; b BS backspace U+0008
%x66 / ; f FF form feed U+000C
%x6E / ; n LF line feed U+000A
%x72 / ; r CR carriage return U+000D
%x74 / ; t HT horizontal tab U+0009
"/" / ; / slash (solidus) U+002F
"\" / ; \ backslash (reverse solidus) U+005C
(%x75 hexchar) ; uXXXX U+XXXX
hexchar = non-surrogate /
(high-surrogate "\" %x75 low-surrogate)
non-surrogate = ((DIGIT / "A"/"B"/"C" / "E"/"F") 3HEXDIG) /
("D" %x30-37 2HEXDIG )
high-surrogate = "D" ("8"/"9"/"A"/"B") 2HEXDIG
low-surrogate = "D" ("C"/"D"/"E"/"F") 2HEXDIG
HEXDIG = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
wildcard-selector = "*"
index-selector = int ; decimal integer
int = "0" /
(["-"] DIGIT1 *DIGIT) ; - optional
DIGIT1 = %x31-39 ; 1-9 non-zero digit
slice-selector = [start S] ":" S [end S] [":" [S step ]]
start = int ; included in selection
end = int ; not included in selection
step = int ; default: 1
filter-selector = "?" S logical-expr
logical-expr = logical-or-expr
logical-or-expr = logical-and-expr *(S "||" S logical-and-expr)
; disjunction
; binds less tightly than conjunction
logical-and-expr = basic-expr *(S "&&" S basic-expr)
; conjunction
; binds more tightly than disjunction
basic-expr = paren-expr /
comparison-expr /
test-expr
paren-expr = [logical-not-op S] "(" S logical-expr S ")"
; parenthesized expression
logical-not-op = "!" ; logical NOT operator
test-expr = [logical-not-op S]
(filter-query / ; existence/non-existence
function-expr) ; LogicalType or NodesType
filter-query = rel-query / jsonpath-query
rel-query = current-node-identifier segments
current-node-identifier = "@"
comparison-expr = comparable S comparison-op S comparable
literal = number / string-literal /
true / false / null
comparable = literal /
singular-query / ; singular query value
function-expr ; ValueType
comparison-op = "==" / "!=" /
"<=" / ">=" /
"<" / ">"
singular-query = rel-singular-query / abs-singular-query
rel-singular-query = current-node-identifier singular-query-segments
abs-singular-query = root-identifier singular-query-segments
singular-query-segments = *(S (name-segment / index-segment))
name-segment = ("[" name-selector "]") /
("." member-name-shorthand)
index-segment = "[" index-selector "]"
number = (int / "-0") [ frac ] [ exp ] ; decimal number
frac = "." 1*DIGIT ; decimal fraction
exp = "e" [ "-" / "+" ] 1*DIGIT ; decimal exponent
true = %x74.72.75.65 ; true
false = %x66.61.6c.73.65 ; false
null = %x6e.75.6c.6c ; null
function-name = function-name-first *function-name-char
function-name-first = LCALPHA
function-name-char = function-name-first / "_" / DIGIT
LCALPHA = %x61-7A ; "a".."z"
function-expr = function-name "(" S [function-argument
*(S "," S function-argument)] S ")"
function-argument = literal /
filter-query / ; (includes singular-query)
logical-expr /
function-expr
segment = child-segment / descendant-segment
child-segment = bracketed-selection /
("."
(wildcard-selector /
member-name-shorthand))
bracketed-selection = "[" S selector *(S "," S selector) S "]"
member-name-shorthand = name-first *name-char
name-first = ALPHA /
"_" /
%x80-D7FF /
; skip surrogate code points
%xE000-10FFFF
name-char = name-first / DIGIT
DIGIT = %x30-39 ; 0-9
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
descendant-segment = ".." (bracketed-selection /
wildcard-selector /
member-name-shorthand)
Figure 2: Collected ABNF of JSONPath Queries
図2：JsonPathクエリの収集されたABNF
Figure 3 contains the collected ABNF grammar that defines the syntax of a JSONPath Normalized Path while also using the rules root-identifier, ESC, DIGIT, and DIGIT1 from Figure 2.
図3には、図2からルールルート識別子、ESC、桁、およびdigit1を使用しながら、JSONPATH正規化されたパスの構文を定義する収集されたABNF文法が含まれています。
normalized-path = root-identifier *(normal-index-segment)
normal-index-segment = "[" normal-selector "]"
normal-selector = normal-name-selector / normal-index-selector
normal-name-selector = %x27 *normal-single-quoted %x27 ; 'string'
normal-single-quoted = normal-unescaped /
ESC normal-escapable
normal-unescaped = ; omit %x0-1F control codes
%x20-26 /
; omit 0x27 '
%x28-5B /
; omit 0x5C \
%x5D-D7FF /
; skip surrogate code points
%xE000-10FFFF
normal-escapable = %x62 / ; b BS backspace U+0008
%x66 / ; f FF form feed U+000C
%x6E / ; n LF line feed U+000A
%x72 / ; r CR carriage return U+000D
%x74 / ; t HT horizontal tab U+0009
"'" / ; ' apostrophe U+0027
"\" / ; \ backslash (reverse solidus) U+005C
(%x75 normal-hexchar)
; certain values u00xx U+00XX
normal-hexchar = "0" "0"
(
("0" %x30-37) / ; "00"-"07"
; omit U+0008-U+000A BS HT LF
("0" %x62) / ; "0b"
; omit U+000C-U+000D FF CR
("0" %x65-66) / ; "0e"-"0f"
("1" normal-HEXDIG)
)
normal-HEXDIG = DIGIT / %x61-66 ; "0"-"9", "a"-"f"
normal-index-selector = "0" / (DIGIT1 *DIGIT)
; non-negative decimal integer
Figure 3: Collected ABNF of JSONPath Normalized Paths
図3：JsonPath正規化されたパスのABNFを収集しました
This appendix is informative.
この付録は有益です。
At the time JSONPath was invented, XML was noted for the availability of powerful tools to analyze, transform, and selectively extract data from XML documents. [XPath] is one of these tools.
JSONPATHが発明された時点で、XMLはXMLドキュメントからデータを分析、変換、選択的に抽出する強力なツールの可用性について注目されました。[Xpath]はこれらのツールの1つです。
In 2007, the need for something solving the same class of problems for the emerging JSON community became apparent, specifically for:
2007年には、新興のJSONコミュニティの同じクラスの問題を解決する必要性が明らかになりました。
* finding data interactively and extracting them out of JSON values [RFC8259] without special scripting and
* 特別なスクリプトなしでJSON値[RFC8259]からインタラクティブにデータを見つけ、それらを抽出します[RFC8259]
* specifying the relevant parts of the JSON data in a request by a client, so the server can reduce the amount of data in its response, minimizing bandwidth usage.
* クライアントによる要求でJSONデータの関連部分を指定すると、サーバーが応答のデータ量を減らして帯域幅の使用を最小限に抑えることができます。
(Note: XPath has evolved since 2007, and recent versions even nominally support operating inside JSON values. This appendix only discusses the more widely used version of XPath that was available in 2007.)
（注：Xpathは2007年以来進化しており、最近のバージョンはJSON値内での動作を名目上サポートしています。この付録では、2007年に利用可能なXPathのより広く使用されているバージョンについてのみ説明しています。）
JSONPath picks up the overall feeling of XPath but maps the concepts to syntax (and partially semantics) that would be familiar to someone using JSON in a dynamic language.
JsonPathはXpathの全体的な感覚を取り上げますが、概念を構文（および部分的にセマンティクス）にマッピングします。これは、動的言語でJSONを使用している人に馴染みがあります。
For example, in popular dynamic programming languages such as JavaScript, Python, and PHP, the semantics of the XPath expression:
たとえば、JavaScript、Python、PHPなどの一般的な動的プログラミング言語では、XPath式のセマンティクス：
/store/book[1]/title
can be realized in the expression:
表現で実現できます。
x.store.book[0].title
or in bracket notation:
またはブラケット表記で：
x['store']['book'][0]['title']
with the variable x holding the query argument.
変数Xがクエリ引数を保持しています。
The JSONPath language was designed to:
jsonpath言語は次のように設計されています。
* be naturally based on those language characteristics,
* これらの言語特性に自然に基づいて、
* cover only the most essential parts of XPath 1.0,
* Xpath1.0の最も重要な部分のみをカバーします。
* be lightweight in code size and memory consumption, and
* コードサイズとメモリ消費量の軽量であり、
* be runtime efficient.
* ランタイム効率を上げてください。
JSONPath expressions apply to JSON values in the same way as XPath expressions are used in combination with an XML document. JSONPath uses $ to refer to the root node of the query argument, similar to XPath's / at the front.
JSONPATH式は、XPATH式がXMLドキュメントと組み合わせて使用されるのと同じ方法でJSON値に適用されます。JSonPathは$を使用して、Xpath / at the Frontと同様に、クエリ引数のルートノードを参照します。
JSONPath expressions move further down the hierarchy using _dot notation_ ($.store.book[0].title) or the _bracket notation_ ($['store']['book'][0]['title']); both replace XPath's / within query expressions, where _dot notation_ serves as a lightweight but limited syntax while _bracket notation_ is a heavyweight but more general syntax.
jsonpath式は、_dot notation_（$ .store.book [0] .title）または_bracket notation_（$ ['store'] ['book'] [0] ['tittle']）を使用して階層をさらに下に移動します。どちらもXpath /内部のクエリ式を置き換えます。_DOT NOTATION_は軽量であるが限られた構文として機能し、_Bracket Notation_はヘビー級であるがより一般的な構文です。
Both JSONPath and XPath use * for a wildcard. JSONPath's descendant segment notation, starting with .., borrowed from [E4X], is similar to XPath's //. The array slicing construct [start:end:step] is unique to JSONPath, inspired by [SLICE] from ECMASCRIPT 4.
JsonPathとXpathの両方がワイルドカードに使用されます *。Jsonpathの子孫セグメント表記は、[e4x]から借りたものから、xpathの//に似ています。Arrayスライシングコンストラクト[start：end：step]は、ecmascript 4の[スライス]に触発されたjsonpathに固有のものです。
Filter expressions are supported via the syntax ?<logical-expr> as in:
フィルター式は、次のように構文を介してサポートされますか？<Logical-Expr>
$.store.book[?@.price < 10].title
Table 20 extends Table 1 by providing a comparison with similar XPath concepts.
表20は、同様のXPathの概念との比較を提供することにより、表1を拡張します。
+==========+==================+===================================+
| XPath | JSONPath | Description |
+==========+==================+===================================+
| / | $ | the root XML element |
+----------+------------------+-----------------------------------+
| . | @ | the current XML element |
+----------+------------------+-----------------------------------+
| / | . or [] | child operator |
+----------+------------------+-----------------------------------+
| .. | n/a | parent operator |
+----------+------------------+-----------------------------------+
| // | ..name, | descendants (JSONPath borrows |
| | ..[index], ..*, | this syntax from E4X) |
| | or ..[*] | |
+----------+------------------+-----------------------------------+
| * | * | wildcard: All XML elements |
| | | regardless of their names |
+----------+------------------+-----------------------------------+
| @ | n/a | attribute access: JSON values do |
| | | not have attributes |
+----------+------------------+-----------------------------------+
| [] | [] | subscript operator used to |
| | | iterate over XML element |
| | | collections and for predicates |
+----------+------------------+-----------------------------------+
| | | [,] | Union operator (results in a |
| | | combination of node sets); called |
| | | list operator in JSONPath, allows |
| | | combining member names, array |
| | | indices, and slices |
+----------+------------------+-----------------------------------+
| n/a | [start:end:step] | array slice operator borrowed |
| | | from ES4 |
+----------+------------------+-----------------------------------+
| [] | ? | applies a filter (script) |
| | | expression |
+----------+------------------+-----------------------------------+
| seamless | n/a | expression engine |
+----------+------------------+-----------------------------------+
| () | n/a | grouping |
+----------+------------------+-----------------------------------+
Table 20: XPath Syntax Compared to JSONPath
表20：jsonpathと比較したxpath構文
For further illustration, Table 21 shows some XPath expressions and their JSONPath equivalents.
さらに説明するために、表21にいくつかのXPath式とそのJSONPATH相当が示されています。
+=======================+========================+==================+
| XPath | JSONPath | Result |
+=======================+========================+==================+
| /store/book/author | $.store.book[*].author | the authors |
| | | of all books |
| | | in the store |
+-----------------------+------------------------+------------------+
| //author | $..author | all authors |
+-----------------------+------------------------+------------------+
| /store/* | $.store.* | all things in |
| | | store, which |
| | | are some |
| | | books and a |
| | | red bicycle |
+-----------------------+------------------------+------------------+
| /store//price | $.store..price | the prices of |
| | | everything in |
| | | the store |
+-----------------------+------------------------+------------------+
| //book[3] | $..book[2] | the third |
| | | book |
+-----------------------+------------------------+------------------+
| //book[last()] | $..book[-1] | the last book |
| | | in order |
+-----------------------+------------------------+------------------+
| //book[position()<3] | $..book[0,1] | the first two |
| | $..book[:2] | books |
+-----------------------+------------------------+------------------+
| //book[isbn] | $..book[?@.isbn] | filter all |
| | | books with an |
| | | ISBN number |
+-----------------------+------------------------+------------------+
| //book[price<10] | $..book[?@.price<10] | filter all |
| | | books cheaper |
| | | than 10 |
+-----------------------+------------------------+------------------+
| //* | $..* | all elements |
| | | in an XML |
| | | document; all |
| | | member values |
| | | and array |
| | | elements |
| | | contained in |
| | | input value |
+-----------------------+------------------------+------------------+
Table 21: Example XPath Expressions and Their JSONPath Equivalents
表21：例Xpath式とそのJSONPATH相当
XPath has a lot more functionality (location paths in unabbreviated syntax, operators, and functions) than listed in this comparison. Moreover, there are significant differences in how the subscript operator works in XPath and JSONPath:
XPathには、この比較にリストされているよりも、より多くの機能（吸収されない構文、演算子、および関数の位置パス）があります。さらに、XPathとJSONPATHで添え字オペレーターがどのように機能するかには大きな違いがあります。
* Square brackets in XPath expressions always operate on the _node set_ resulting from the previous path fragment. Indices always start at 1.
* Xpath式の正方形の括弧は、前のパスフラグメントから生じる_node set_で常に動作します。インデックスは常に1から始まります。
* With JSONPath, square brackets operate on each of the nodes in the _nodelist_ resulting from the previous query segment. Array indices always start at 0.
* JSONPATHを使用すると、前のクエリセグメントから生じる_nodelist_の各ノードで四角いブラケットが動作します。配列インデックスは常に0から始まります。
This appendix is informative.
この付録は有益です。
In relation to JSON Pointer [RFC6901], JSONPath is not intended as a replacement but as a more powerful companion. The purposes of the two standards are different.
JSON Pointer [RFC6901]に関連して、JSonPathは代替品としてではなく、より強力な仲間として意図されています。2つの基準の目的は異なります。
JSON Pointer is for identifying a single value within a JSON value whose structure is known.
JSON Pointerは、構造が既知のJSON値内で単一の値を識別するためのものです。
JSONPath can identify a single value within a JSON value, for example, by using a Normalized Path. But JSONPath is also a query syntax that can be used to search for and extract multiple values from JSON values whose structure is known only in a general way.
JSonPathは、たとえば正規化されたパスを使用して、JSON値内の単一の値を識別できます。しかし、JSonPathは、構造が一般的な方法でのみ知られているJSON値から複数の値を検索および抽出するために使用できるクエリ構文でもあります。
A Normalized JSONPath can be converted into a JSON Pointer by converting the syntax, without knowledge of any JSON value. The inverse is not generally true, i.e., a numeric reference token (path component) in a JSON Pointer may identify a member value of an object or an element of an array. For conversion to a JSONPath query, knowledge of the structure of the JSON value is needed to distinguish these cases.
正規化されたJSONPATHは、JSON値の知識なしに、構文を変換することにより、JSONポインターに変換できます。逆は一般に真実ではありません。つまり、JSONポインターの数値参照トークン（パスコンポーネント）は、オブジェクトのメンバー値または配列の要素を識別する場合があります。JSONPATHクエリへの変換には、これらのケースを区別するためにJSON値の構造に関する知識が必要です。
This document is based on Stefan Gössner's original online article defining JSONPath [JSONPath-orig].
このドキュメントは、JsonPath [JSonPath-Orig]を定義するStefanGösnerのオリジナルオンライン記事に基づいています。
The books example was taken from course material that Bielefeld University, Germany used in 2002.
本の例は、ドイツのビーレフェルド大学が2002年に使用したコース資料から撮影されました。
This work is indebted to Christoph Burgmer for the superb JSONPath comparison project [COMPARISON] that details the behavior of over forty JSONPath implementations applied to numerous queries.
この作業は、多数のクエリに適用される40以上のJSONPATH実装の動作を詳述するSuperB JSonPath比較プロジェクト[比較]について、Christoph Burgmerに感謝しています。
Marko Mikulicic
InfluxData, Inc.
Pisa
Italy
Email: mmikulicic@gmail.com
Edward Surov
TheSoul Publishing Ltd.
Limassol
Cyprus
Email: esurov.tsp@gmail.com
Greg Dennis
Auckland
New Zealand
Email: gregsdennis@yahoo.com
URI: https://github.com/gregsdennis
Stefan Gössner (editor)
Fachhochschule Dortmund
Sonnenstraße 96
D-44139 Dortmund
Germany
Email: stefan.goessner@fh-dortmund.de
Glyn Normington (editor)
Winchester
United Kingdom
Email: glyn.normington@gmail.com
Carsten Bormann (editor)
Universität Bremen TZI
Postfach 330440
D-28359 Bremen
Germany
Phone: +49-421-218-63921
Email: cabo@tzi.org