본문으로 건너뛰기

JSONPath 테스터

JSONPath Tester

JSONPath 식을 문서에 실행하고 입력하는 동안 일치하는 노드를 강조해 보여 줍니다.

JSONPath 질의를 문서에 실행해서 선택된 모든 노드를 각자의 경로와 함께 보여 줍니다. 그 앞의 이십 년 동안 나온 서로 안 맞는 구현들이 아니라 2024년 표준인 RFC 9535를 구현했습니다. 질의에 필터가 들어가는 순간부터 그 차이가 드러납니다.

🔒 브라우저 안에서만 처리jsonjsonpathquerytest

질의

루트에서: 아래 어디에서든 멤버 “book”; 그다음 필터를 통과하는 자식들; 그다음 멤버 “title”.

문서

일치 결과

입력하는 대로 여기에 결과가 나옵니다.

2024년 표준인 RFC 9535를 따릅니다. 그 이전 이십 년 동안의 서로 안 맞는 구현들이 아닙니다. 실제로 걸리는 차이는 이렇습니다. 결과는 노드 목록이라 중복을 지우지 않고, ..는 자식보다 자기 노드를 먼저 방문하며, 없는 멤버는 다른 없는 멤버와만 같고, 여러 노드에 일치할 수 있는 질의와 비교하면 짐작하는 대신 문법 오류를 냅니다. match()와 search() 안의 패턴은 브라우저의 정규식 엔진으로 넘어갑니다. RFC가 정한 I-Regexp 방언보다 더 많은 것을 받아들입니다.

사용 방법

  1. 문서를 붙여넣습니다

    JSON으로 파싱되는 것이면 됩니다. 질의는 워커에서 돌기 때문에 문서가 커도 입력하는 동안 페이지가 멈추지 않습니다.

  2. 질의를 쓰거나 예시에서 시작합니다

    입력 상자 아래 버튼들이 자주 쓰는 형태를 담고 있습니다. 와일드카드, 하위 탐색, 슬라이스, 필터, 정규식, 함수입니다. 그 위에는 지금 쓴 질의가 무슨 뜻인지 풀어 쓴 설명이 나옵니다.

  3. 경로와 함께 결과를 봅니다

    결과마다 그것에 이르는 정규화된 경로가 붙어서, 기대한 자리에서 나온 것인지 확인할 수 있습니다. 아래 줄에는 이 질의가 단일 질의인지 — 많아야 노드 하나를 고르는지 — 나옵니다. JSON 포인터가 그런 것입니다.

자주 묻는 질문

다른 도구에서는 되는 질의가 여기서는 안 됩니다.

RFC 9535과의 차이일 가능성이 큽니다. 표준은 옛 구현들이 허용하던 것들을 없앴습니다. `()` 안의 스크립트 식, 괄호를 쓰던 옛 필터 문법 `$..[?(@.x)]`, 그리고 여러 노드에 일치할 수 있는 질의와의 비교입니다. 마지막 것은 이제 짐작하는 대신 문법 오류가 납니다.

같은 값이 왜 두 번 나오나요?

결과가 집합이 아니라 노드 목록이기 때문입니다. `$..price`가 서로 다른 두 경로로 같은 노드에 닿으면 두 번 나옵니다. 의도된 동작입니다. 중복을 지우면 각 결과가 어디서 왔는지가 사라집니다.

`match()`의 정규식은 표준인가요?

정확히는 아닙니다. RFC는 I-Regexp라는 작은 방언을 정하는데, 여기서는 패턴을 브라우저의 엔진으로 넘깁니다. 브라우저 쪽이 더 많은 것을 받아들입니다. 여기서 되는 패턴이 엄격한 구현에서는 거절될 수 있습니다. 운영에 넣기 전에 알아 둘 만합니다.

문서를 수정할 수도 있나요?

아니요. JSONPath는 고르기만 하고 쓰지 않습니다. 수정하려면, 여기 나오는 경로가 RFC 6901 포인터이므로 JSON Patch에 그대로 넣을 수 있습니다. 이 사이트의 JSON 비교 도구가 그 패치를 만들어 줍니다.

이 도구로 이어지는 것

다음 단계

이 도구의 결과를 그대로 받을 수 있는 도구들입니다.