1.1. 用語

この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、 「MAY」、および「OPTIONAL」は、 ここに示すようにすべて大文字で現れる場合に限り、 BCP 14 [RFC2119] [RFC8174] に記述されているように解釈されます。¶

この文書の文法規則は、[RFC5234] に 記述されているように ABNF として解釈されます。 この文書の ABNF 終端値は、その UTF-8 エンコーディングではなく Unicode スカラー値を定義します。 たとえば、Unicode PLACE OF INTEREST SIGN (U+2318) は ABNF では %x2318 と定義されます。¶

関数は、fname() のように、関数名の後に一対の 括弧を付けて参照されます。¶

[RFC8259] の用語は、以下で明確化される場合を除き適用されます。 「primitive」と「structured」という用語は、[RFC8259] のセクション 1と同様に、 値の種類を分類するために使用されます。JSON オブジェクトと配列は structured です。その他すべての値は primitive です。 「object」、「array」、「number」、および「string」の定義は 変更されません。 重要なこととして、とくに「object」と「array」は、 一般的なプログラミング文脈でそうであるような汎用的な意味を帯びません。¶

[RFC9485] の用語が適用されます。¶

この文書で使用される追加の用語を以下に定義します。¶

値:

[RFC8259] に従い、JSON の汎用データモデルに適合するデータ項目です。すなわち、 primitive データ（数値、テキスト文字列、および特別な 値 null、true、false）、または structured データ（JSON オブジェクトと配列）です。 [RFC8259] は JSON 値のテキスト表現に焦点を当てており、 ここで想定されている値の抽象化を完全には定義していません。¶

メンバー:

オブジェクト内の名前/値のペアです。（メンバー自体は 値ではありません。）¶

名前:

メンバーを構成する名前/値ペア内の名前（文字列）です。 これは [RFC8259] でも使用されていますが、 その仕様では 形式的には定義されていません。 完全性のためにここに含めています。¶

要素:

JSON 配列内の値です。¶

インデックス:

配列内の特定の要素を識別する整数です。¶

クエリ:

JSONPath 式の短い名称です。¶

クエリ引数:

JSONPath 式が適用される値の短い名称です。¶

位置:

クエリ引数内における値の位置です。これは、クエリ引数内の オブジェクトと配列を通ってその値まで移動する名前とインデックスの シーケンスと考えることができ、空のシーケンスは クエリ引数そのものを示します。 位置は正規化パス（以下で定義）として表現できます。¶

ノード:

値と、そのクエリ引数内での位置とのペアです。¶

ルートノード:

その値がクエリ引数全体である一意のノードです。¶

ルートノード識別子:

式 $ であり、クエリ引数のルートノードを参照します。¶

現在ノード識別子:

式 @ であり、フィルター式（後述）の評価の文脈における 現在ノードを参照します。¶

子（ノードの）:

ノードが配列である場合は、その要素のノードです。ノードがオブジェクトである場合は、そのメンバー値のノードです。 ノードが配列でもオブジェクトでもない場合、子はありません。¶

子孫（ノードの）:

そのノードの子、およびその子の子、というように 再帰的に含めたものです。より形式的には、ノード間の「子孫」関係は「子」関係の推移 閉包です。¶

深さ（値内の子孫ノードの）:

値内におけるそのノードの祖先の数です。値のルート ノードの深さは 0、 ルートノードの子の深さは 1、その子の深さは 2、というように続きます。¶

ノードリスト:

ノードのリストです。 ノードリストは JSON で、たとえば配列として表現できますが、この文書は 特定の表現を要求または想定しません。¶

パラメーター:

関数式内で関数引数 （実引数）を受け取ることができる（関数の）仮パラメーターです。¶

正規化パス:

値内のノードを識別する JSONPath 式の形式であり、 ちょうどそのノードを結果とするクエリを提供します。 クエリ引数内の各ノードは、ちょうど 1 つの正規化パスによって識別されます（そのノードに対して 正規化パスが「一意」であると言います）。また、特定のクエリ引数に対する 正規化パスであるためには、正規化パスは ちょうど 1 つのノードを識別する必要があります。これは JSON Pointer [RFC6901] に似ていますが、構文的には異なります。 注: この定義は セクション 2.7 の構文上の定義に基づいています。 値内のノードを識別するものの、その 構文に適合しない JSONPath 式は正規化パスではありません。¶

Unicode スカラー値:

上位サロゲートおよび 下位サロゲートのコードポイントを除く、任意の Unicode [UNICODE] コードポイントです（言い換えると、16 進の包括範囲で 0 から D7FF、または E000 から 10FFFF の整数です）。JSONPath クエリは Unicode スカラー値のシーケンスです。¶

セグメント:

入力値の子 ([<selectors>]) または子孫 (..⁠[<selectors>]) を選択する構成要素の 1 つです。¶

セレクター:

セグメント内の単一項目であり、入力値を受け取って 入力値の子ノードからなるノードリストを生成します。¶

単一クエリ:

特定の方法で構文上制限された セグメントから構成される JSONPath 式であり（セクション 2.3.5.1）、入力 値にかかわらず、その式が最大 1 つのノードを含むノードリストを生成するものです。 注: 常に単一ノードリストを生成するが、セクション 2.3.5.1 の構文に 適合しない JSONPath 式は単一クエリではありません。¶

1.2. 沿革

この文書は、Stefan Gössner による 広く知られた JSONPath 提案（2007-02-21 付け）[JSONPath-orig] に基づき、その実装の広範な 展開から得られた経験を踏まえ、それに対する規範的な仕様を提供します。¶

付録 B は、 JSONPath が XML の XPath [XPath] からどのように着想を得たかを説明します。¶

JSONPath は、PHP や JavaScript などのプログラミング言語における JSON 実装の軽量な補完手段として意図されていました。 そのため、XPath が行ったように独自の式言語を定義する代わりに、 JSONPath はクエリの一部を基盤となる 実行時、たとえば JavaScript の eval() 関数に委譲しました。 より多くの環境で JSONPath が実装されるにつれ、JSONPath 式の移植性は低下していきました。 たとえば、正規表現処理はしばしば 便利な正規表現エンジンに委譲されました。¶

この文書は、そのような実装固有の依存関係を取り除き、 プログラミング言語や環境をまたいで使用できる共通の JSONPath 仕様として機能することを目的としています。 これは、後方互換性が 常に達成されるわけではないことを意味します。この文書の設計原則は、 使いやすく安定した JSON クエリ言語を得るという目的を損なわない限り、 たとえ粗いものであっても実装間の「合意」に従うことです。¶

JSONPath という用語は、XPath からの着想に加え、 クエリの結果が JSON クエリ引数内のノードを識別する パスで構成されることから選ばれました。¶

1.3. JSON 値

JSONPath クエリが適用される JSON 値は、定義上、 有効な JSON 値です。JSON 値は、多くの場合 JSON テキストを解析することで構築されます。¶

JSON テキストを JSON 値へ解析すること、および JSON テキストが有効な JSON を表さない場合に何が起こるかは、この文書では定義しません。 [RFC8259] のセクション 4 および 8 は、JSON テキストの文法に適合し得るものの、 相互運用可能な JSON の使用ではない特定の状況を 識別しています。これらは予測不能な動作を引き起こす可能性があります。 この文書は、そのような状況における JSONPath クエリの 予測可能な動作を定義しようとはしません。¶

具体的には、セクション 2.3.1、2.3.2、 2.3.5、および 2.5.2 の「意味論」サブセクションでは、 検討対象のオブジェクトのいずれかに対する JSON 値が、 単一オブジェクトに対して同じメンバー名を共有する 複数のメンバーを示す JSON テキスト （「重複名」、[RFC8259] のセクション 4を参照） から構築された場合に、予測不能になる動作を説明しています。 また、名前によって子を選択する場合（セクション 2.3.1）および文字列を比較する場合 （セクション 2.3.5.2.2）、 これらの文字列は Unicode スカラー値のシーケンスであると想定されます。そうでない場合、その動作は予測不能になります （[RFC8259] のセクション 8.2）。¶

1.4. JSONPath 式の 概要

JSONPath 式は、クエリ引数として知られる JSON 値に適用されます。 出力はノードリストです。¶

JSONPath 式は、識別子の後に 0 個以上のセグメントが続くもので構成され、各セグメントには 1 つ以上のセレクターが含まれます。¶

$['store']['book'][0]['title']

$.store.book[0].title

$.store.book[?@.price < 10].title

1.5. JSONPath の例

このセクションは参考情報です。JSONPath 式の例を提供します。¶

これらの例は、図 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
    }
  }
}

表 2 は、 この例に適用できるいくつかの JSONPath クエリと、それらの意図される結果を示します。¶

2.1. 概要

JSONPath 式は、JSON 値 （クエリ引数）に適用されたときに、その引数の 0 個以上のノードを選択し、 これらのノードをノードリストとして出力する文字列です。¶

クエリは UTF-8 を用いて符号化されなければなりません（MUST）。 この文書で与えられるクエリの文法は、その UTF-8 形式がまず [RFC3629] に記述されるように Unicode スカラー値へ復号されることを前提としています。同等の 結果をもたらす実装方法も可能です。¶

JSONPath クエリとして使用される文字列は、整形式かつ 妥当である必要があります。 文字列は、この文書の ABNF 構文に適合する場合、整形式の JSONPath クエリです。 整形式の JSONPath クエリは、この文書が課す両方の意味論的 要件も満たす場合に妥当です。その要件は次のとおりです。¶

1. JSONPath 処理に関係する JSONPath クエリ内の整数 （たとえばインデックス値やステップ）は、Internet JSON (I-JSON) で定義される 正確な整数値の範囲内でなければなりません（MUST）（セクション 2.2 of [RFC7493] を参照）。すなわち、 区間 [-(2⁵³)+1, (2⁵³)-1] の範囲内です。¶
2. 関数拡張の使用は、セクション 2.4.3 に記述されるように、 型整合していなければなりません（MUST）。¶

JSONPath 実装は、整形式かつ妥当でない任意のクエリに対して エラーを発生させなければなりません（MUST）。 JSONPath クエリの整形式性および妥当性は、 そのクエリが適用される JSON 値とは独立しています。 JSONPath クエリの整形式性および妥当性に関するさらなるエラーは、 値へクエリを適用している間に発生し得ません。 これにより、クエリ内の整形式性/妥当性エラーと、 実際にはデータの欠陥に由来し得る不一致とが明確に分離されます。¶

妥当なクエリが期待する構造と、 データ内で見つかった構造との不一致は、空のクエリ結果につながることがあり、 これは予期しないものであり、いずれかにバグがあることを示す可能性があります。 そのため JSONPath 実装は、空の 結果の原因を見つける助けとなる診断情報を、 アプリケーション開発者に提供したい場合があります。¶

明らかに、実装は JSONPath クエリの実行時に、たとえばリソース枯渇によって失敗することがあり得ますが、 この文書ではこれはモデル化されません。しかし、実装は 無言で誤動作してはなりません（MUST NOT）。 具体的には、妥当な JSONPath クエリが、 クエリを正しく処理するには大きすぎる構造化値に対して評価される場合 （たとえば、正確な値の範囲外にある数値の処理を必要とする場合）、 実装はオーバーフローの表示を提供しなければなりません（MUST）。¶

（HTTP エラーモデルに詳しい読者は、整形式性および妥当性について考えるときに 400 系のエラーを思い起こすかもしれません。また、 リソース枯渇および関連するエラーを 500 系のエラーに相当するものとして 認識するかもしれません。）¶

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

2.2. ルート識別子

root-identifier     = "$"

{"k": "v"}

2.3. セレクター

セレクターは、子セグメント（セクション 2.5.1）および 子孫セグメント（セクション 2.5.2）の内部にのみ現れます。¶

セレクターは、入力値の 0 個以上の子からなるノードリストを生成します。¶

オブジェクトの子、配列の子、 またはオブジェクトか配列のどちらかの子を生成する、さまざまな種類のセレクターがあります。¶

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"

{
  "o": {"j j": {"k.k": 3}},
  "'": {"@": 2}
}

wildcard-selector   = "*"

{
  "o": {"j": 1, "k": 2},
  "a": [5, 3]
}

index-selector      = int                        ; decimal integer

int                 = "0" /
                      (["-"] DIGIT1 *DIGIT)      ; - optional
DIGIT1              = %x31-39                    ; 1-9 non-zero digit

["a","b"]

slice-selector      = [start S] ":" S [end S] [":" [S step ]]

start               = int       ; included in selection
end                 = int       ; not included in selection
step                = int       ; default: 1

FUNCTION Normalize(i, len):
  IF i >= 0 THEN
    RETURN i
  ELSE
    RETURN len + i
  END IF

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)

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

["a", "b", "c", "d", "e", "f", "g"]

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

{
  "obj": {"x": "y"},
  "arr": [2, 3]
}

{
  "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"
}

2.4. 関数拡張

前のサブセクションで定義されたフィルター式の機能を超えて、 JSONPath はフィルター式の機能を追加するために使用できる拡張点、 「関数拡張」を定義します。¶

このセクションでは、この拡張点と、この拡張点を使用するいくつかの 関数拡張を定義します。 これらの仕組みは拡張点を使用するように設計されていますが、 JSONPath 仕様の不可欠な一部であり、この仕様の他の不可欠な部分と同様に 実装されることが期待されます。¶

関数拡張は、登録名（セクション 3.2 を参照）を定義します。 これは 0 個以上の引数のシーケンスに適用でき、 結果を生成します。登録された各関数名は一意です。¶

関数拡張は、その評価に副作用がないように定義されなければなりません（MUST）。 すなわち、それを含む式に対して可能なすべての評価順序と、 短絡評価または完全評価の選択が、同じ結果に至らなければなりません（MUST）。 （注: メモ化またはロギングは、この意味での副作用ではありません。 それらは実装レベルでのみ可視であり、評価結果に影響しないためです。）¶

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

クエリ内の任意の関数式は、 （上記の ABNF に適合することで）整形式であり、 かつ型整合していなければなりません。 そうでない場合、JSONPath 実装はエラーを発生させなければなりません（MUST） （セクション 2.1 を参照）。 どの関数式が型整合しているかを定義するために、 まず型システムを導入します。¶

$[?length(@.authors) >= 5]

$[?count(@.*.author) >= 5]

$[?match(@.date, "1974-05-..")]

$[?search(@.author, "[BR]ob")]

$[?value(@..color) == "red"]

2.5. セグメント

入力ノードリスト内の各ノードについて、 セグメントは 1 つ以上のセレクターをそのノードに適用し、 各セレクターの結果を入力ノードごとのノードリストへ連結します。 それらはさらに入力ノードリストの順序で連結され、 単一のセグメント結果ノードリストを形成します。¶

クエリ内のセグメントが多いほど、結果ノードリストのノードは、 入力値内でより深い位置にあることになります。¶

• N 個のセグメントを持つクエリ（N >= 0）は、 入力値内で深さ N 以上にあるノードからなるノードリストを生成します。¶
• N 個のセグメントを持つクエリ（N >= 0）で、 それらすべてが子セグメント（セクション 2.5.1）である場合、 入力値内で正確に深さ N にあるノードからなるノードリストを生成します。¶

セグメントには、子セグメントと子孫セグメントの 2 種類があります。¶

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

["a", "b", "c", "d", "e", "f", "g"]

descendant-segment  = ".." (bracketed-selection /
                            wildcard-selector /
                            member-name-shorthand)

{
  "o": {"j": 1, "k": 2},
  "a": [5, 3, [{"j": 4}, {"k": 6}]]
}

2.6. null の意味論

注: JSON の null は、他の任意の JSON 値と同じように扱われます。 すなわち、「undefined」または「missing」を意味するものとは見なされません。¶

{"a": null, "b": [null], "c": [{}], "null": 1}

2.7. 正規化パス

正規化パスは、値内のノードの位置を一意に表す表現であり、 その値内のノードを一意に識別します。 具体的には、正規化パスは制限された構文（以下で定義）を持つ JSONPath クエリであり、 たとえば $['book'][3] のようなものです。これを値に適用すると、 正規化パスによって識別されるノードだけからなるノードリストが結果となります。 注: 正規化パスは、特定の値内におけるノードの同一性を表します。 値内の任意の特定のノードを識別する正規化パスは、ちょうど 1 つだけ存在します。¶

ノードリストは、文字列の配列として JSON でコンパクトに表現できます。 ここで各文字列は正規化パスです。¶

正規化パスは、ノードリストのテストおよび後処理 （たとえば重複ノードの削除）を簡単にする予測可能な形式を提供します。 正規化パスは、この文書の例では結果パスとして使用されます。¶

正規化パスは、ドット記法ではなく、正準的なブラケット記法を使用します。¶

正規化パスでは、文字列のメンバー名を区切るために単一引用符が使用されます。 これにより、正規化パスが二重引用符で区切られた文字列 （たとえば JSON テキスト）内に現れるときに、エスケープが必要な文字数が減ります。¶

正規化パスでは、特定の文字はただ 1 つの方法でのみエスケープされます。 その他すべての文字はエスケープされません。¶

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

与えられたノードを識別する正規化パスは 1 つしか存在できないため、 構文はどの文字をエスケープし、どの文字をエスケープしないかを規定します。 そのため、normal-hexchar の定義は、 直接印字可能ではない文字、たとえば U+000B LINE TABULATION のように、 \n などの標準 JSON エスケープが利用できない文字を 16 進エスケープするために設計されています。¶

3.1. メディア型 application/jsonpath の登録

IANA は次のメディア型 [RFC6838] を登録しました。¶

型名:

application¶

サブタイプ名:

jsonpath¶

必須パラメーター:

N/A¶

任意パラメーター:

N/A¶

符号化に関する考慮事項:

binary (UTF-8)¶

セキュリティに関する考慮事項:

RFC 9535 の「セキュリティに関する考慮事項」セクションを参照してください。¶

相互運用性に関する考慮事項:

N/A¶

公開仕様:

RFC 9535¶

このメディア型を使用するアプリケーション:

JSON データ内でクエリを伝達する必要があるアプリケーション¶

フラグメント識別子に関する考慮事項:

N/A¶

追加情報:

この型の非推奨エイリアス名:

N/A¶

マジックナンバー:

N/A¶

ファイル拡張子:

N/A¶

Macintosh ファイル型コード:

N/A¶

詳細情報の問い合わせ先となる人物およびメールアドレス:

iesg@ietf.org¶

意図される用途:

COMMON¶

使用上の制限:

N/A¶

著者:

JSONPath WG¶

変更管理者:

IETF¶

3.2. 関数拡張 サブレジストリ

この仕様に従い、IANA は新しい「JSONPath」レジストリ内に 新しい「Function Extensions」サブレジストリを作成しました。 「Function Extensions」サブレジストリのポリシーは「Expert Review」 （[RFC8126] のセクション 4.5 ）です。¶

サブレジストリ内の各エントリーは、次を含まなければなりません。¶

関数名:

文字で始まり、その後に文字、数字、およびアンダースコア文字を含むことができる 小文字 ASCII [RFC0020] 文字列 （[a-z][_a-z0-9]*）。サブレジストリ内の他のエントリーは、 同じ関数名を持つことはできません。¶

簡潔な説明:

簡潔な説明¶

パラメーター:

この関数拡張で期待される各引数について 1 つずつ、 0 個以上の宣言型をカンマ区切りで並べたリスト¶

結果:

この関数拡張の結果の宣言型¶

変更管理者:

[RFC8126] のセクション 2.3を参照してください。¶

参照:

関数拡張の説明を提供する参照文書¶

このサブレジストリの初期エントリーは 表 19 に列挙されています。 「Change Controller」列のエントリーはすべて値「IETF」を持ち、 「Reference」列のエントリーはすべて値「RFC 9535 のセクション 2.4」を持ちます。¶

4.1. JSONPath 実装に対する 攻撃ベクトル

歴史的に、JSONPath はしばしば、クエリの一部を 基盤となるプログラミング言語エンジン、たとえば JavaScript の eval() 関数に渡すことで実装されてきました。 このアプローチはインジェクション攻撃につながることがよく知られており、 これらの攻撃を防ぐには完全な入力検証が必要になります （JSON 自体に関する同様の考慮事項については [RFC8259] のセクション 12を参照）。 その代わりに、JSONPath 実装は、プログラミング言語エンジンのパーサーに頼らず、 クエリの構文全体を実装する必要があります。¶

可用性に対する攻撃では、特定の実装が特定の場合に示す、 異常に高コストな実行時性能を引き起こそうとする可能性があります。 （ハッシュテーブル実装における問題については [RFC8949] のセクション 10を、 正規表現実装における性能問題については [RFC9485] のセクション 8を参照。） 実装者は、攻撃者が特別に細工した JSONPath クエリまたはクエリ引数を送信して、 驚くほど高い、場合によっては指数関数的な CPU 使用量や、たとえば子孫セグメントの ナイーブな再帰実装を通じたスタックオーバーフローを引き起こせる限り、 良好な平均性能だけでは不十分であることを認識する必要があります。 実装は、これらの攻撃を軽減するための適切なリソース管理を備える必要があります。¶

4.2. JSONPath クエリの形成方法に対する 攻撃ベクトル

JSONPath クエリは静的でないことが多く、 インデックス値、メンバー名、またはフィルター式で比較する値を提供する変数から形成されます。 これらの変数は検証される必要があり （たとえば、与えられた値が許す場合に限り .name のような特定の構成を形成できるようにする）、 かつ変換される必要があります（たとえば、文字列区切り文字をエスケープする）。 これらの検証および変換を正しく行わないと、予期しない失敗につながる可能性があり、 とりわけ攻撃者が値を制御している場合（たとえば Web フォームに入力することによって）、 可用性、機密性、および完全性の侵害につながり得ます。 結果として生じる攻撃の種類であるインジェクション（たとえば SQL インジェクション）は、 アプリケーションセキュリティ脆弱性の主要原因の上位に一貫して見られ、 特別な注意を必要とします。¶

4.3. JSONPath を用いるセキュリティ 仕組みに対する攻撃

JSONPath がセキュリティ仕組みの一部として使用される場合、 攻撃者は予期しない、または予測不能な挙動を引き起こそうとしたり、 JSONPath 実装間の挙動の違いを利用しようとしたりできます。¶

予期しない、または予測不能な挙動は、 [RFC8259] によって予測不能と記述される特定の構成を持つ クエリ引数から生じる可能性があります。 [RFC7493] に適合する任意のクエリ引数については、 オブジェクトの順序付けに関する場合を除き、予測可能な挙動を期待できます。¶

その他の攻撃は、UTF-8（[RFC3629] のセクション 10を参照）や Unicode 文字集合など、基盤技術の挙動を標的にする可能性があります。¶

B.1. JSONPath と XPath

JSONPath 式は、XPath 式が XML 文書と組み合わせて使用されるのと同じように、 JSON 値に適用されます。 JSONPath は、XPath の先頭の / と同様に、 クエリ引数のルートノードを参照するために $ を使用します。¶

JSONPath 式は、ドット記法 （$.store.book[0].title） またはブラケット記法 （$['store']['book'][0]['title']）を使用して階層をさらに下へ移動します。 どちらもクエリ式内の XPath の / を置き換えるものであり、 ドット記法は軽量ですが制限のある構文として機能し、 ブラケット記法は重量級ですが、より一般的な構文です。¶

JSONPath と XPath はどちらも、ワイルドカードに * を使用します。 JSONPath の子孫セグメント記法は .. で始まり、 [E4X] から借用したもので、 XPath の // に似ています。 配列スライス構文 [start:end:step] は JSONPath 独自のものであり、 ECMASCRIPT 4 の [SLICE] に着想を得ています。¶

フィルター式は、次のように ?<logical-expr> という構文でサポートされます。¶

$.store.book[?@.price < 10].title

表 20 は、 類似する XPath の概念との比較を提供することで、 表 1 を拡張します。¶

さらに説明するため、表 21 は、いくつかの XPath 式と それらに対応する JSONPath 式を示します。¶

XPath には、この比較に列挙されているものよりもはるかに多くの機能 （省略しない構文によるロケーションパス、演算子、および関数）があります。 さらに、XPath と JSONPath では添字演算子の動作に 重要な違いがあります。¶

• XPath 式の角括弧は、常に直前のパス断片から結果として得られる ノード集合に対して作用します。インデックスは常に 1 から始まります。¶
• JSONPath では、角括弧は直前のクエリセグメントから結果として得られる ノードリスト内の各ノードに対して作用します。 配列インデックスは常に 0 から始まります。¶