🔎 JSONPath 테스터
JSON 데이터에 대해 JSONPath 쿼리($.store.book[*].author 등)를 실시간 평가. 필터, 재귀, 와일드카드 지원.
🔒 개인정보 보호
- ・모든 처리는 브라우저 내에서 완료됩니다
- ・입력 데이터는 서버로 전송되지 않습니다
📚 JSONPath 구문 도움말
$ — 루트 객체@ — 현재 노드 (필터 내).field / ['field'] — 자식 접근.. — 재귀 하강* — 와일드카드[index] — 배열 인덱스[start:end:step] — 배열 슬라이스[a,b,c] — 복수 인덱스/필드[?(@.price < 10)] — 필터 식[?(@.tags)] — 필드 존재📖 자주 걸리는 지점
JSON 에 대해 JSONPath 쿼리를 실시간으로 평가하고 매치된 값과 건수를 표시합니다. 재귀 하강 · 와일드카드 · 슬라이스 · 필터식에 대응하며 처리는 브라우저 안에서 끝납니다. JSONPath 는 2024 년에 RFC 9535 로 표준화될 때까지 정식 사양이 존재하지 않았습니다 — 그때까지의 17 년간 각 구현이 2007 년의 기사를 독자적으로 해석하고 있었으므로 같은 식이 구현에 따라 다른 결과를 반환합니다.
| 사례 | 무슨 일이 일어나는가 | 어떻게 하면 되는가 |
|---|---|---|
| 같은 식이 구현에 따라 다른 결과가 된다 | 모호함이 남아 있던 것은 주로 세 곳입니다 — 재귀 하강과 인덱스의 조합($..book[0] 이 각 배열의 첫 번째인지 전 book 을 모은 배열의 첫 번째인지), 결과가 항상 배열인지 단일한 값일 때는 값 자체를 반환하는지, 그리고 필터식에서 존재하지 않는 필드를 참조했을 때의 동작입니다. 구현을 갈아탄 순간에 결과가 바뀌므로 라이브러리를 갱신했더니 갑자기 동작하지 않게 되었다는 형태로 표면화합니다 — 식은 바꾸지 않았으므로 원인의 짐작이 가지 않습니다. |
RFC 9535 준거를 명시하고 있는 라이브러리를 고르세요 — 2024 년 이후의 것은 준거라고 쓰여 있습니다. 기존 코드에서는 쓰고 있는 라이브러리의 문서에서 실제 동작을 확인하는 수밖에 없습니다. 실무상의 조언으로는 모호함이 나오는 작성법을 피하는 것이 가장 확실합니다 — 재귀 하강 $.. 직후에 인덱스를 쓰지 않는다, 결과는 항상 배열로 받고 [0] 은 코드 쪽에서 취한다, 필터는 존재 확인과 조합한다(?(@.price && @.price < 10)). 이 세 가지를 지키면 구현의 차이에 거의 영향받지 않게 됩니다 — JSONPath 를 식 안에서 정교하게 할수록 이식성은 떨어집니다. |
| 필터식이 동작하지 않는다 | 숫자의 비교 ?(@.price < 10) 는 많은 구현에서 동작하지만 문자열의 비교에서 따옴표의 종류가 문제가 됩니다 — ?(@.category == 'fiction') 의 작은따옴표를 받지 않는 구현, 반대로 큰따옴표를 받지 않는 구현 양쪽이 존재합니다. RFC 9535 는 양쪽을 허용하지만 그 이전의 구현은 어느 한쪽만인 경우가 있습니다. 더 까다롭게도 비교 연산자의 앞뒤 공백의 유무로 실패하는 구현이나 == 가 아니라 = 를 요구하는 구현도 있습니다 — 그리고 에러 메시지는 나오지 않고 단순히 0 건이 돌아옵니다. |
쿼리를 한꺼번에 쓰지 말고 단계적으로 좁혀 가세요 — $ 로 전체를 보고 $.store, $.store.book, $.store.book[*], 마지막에 필터라는 순서로 확인하면 어느 단계에서 0 건이 되었는지를 알 수 있습니다. 이는 이런 종류의 쿼리 언어에서 가장 빠른 디버그 방법입니다 — 0 건이라는 결과만 봐서는 오타인지 데이터가 없는지 구문이 통하지 않은 것인지를 구별할 수 없기 때문입니다. 필터가 원인이라고 알게 되면 따옴표의 종류를 바꾸고 연산자 앞뒤의 공백을 지우고 == 와 = 를 시험한다는 순서로 짚어 보세요. 복잡한 필터가 필요한 단계가 되면 JSONPath 가 아니라 코드로 쓰는 편이 읽기 쉽고 테스트도 할 수 있습니다. |
| JSONPath 와 JMESPath 와 jq 를 혼동한다 | 이름도 겉모습도 비슷하지만 이 셋은 다른 언어이고 구문의 호환성은 거의 없습니다. AWS CLI 의 --query 는 JMESPath(Reservations[].Instances[].InstanceId 처럼 $ 를 쓰지 않습니다), kubectl -o jsonpath 은 Kubernetes 고유의 방언({} 로 감싸고 $ 를 생략할 수 있으며 range 라는 고유 구문이 있습니다), jq 는 완전히 독자적인 쿼리 언어(파이프, 변수, 함수 정의까지 있습니다)입니다. 인터넷에서 찾은 식을 그대로 붙여 넣어 동작하지 않는 원인의 상당수가 이것이며 JSONPath 의 기사라고 생각했던 것이 실은 JMESPath 였다는 일이 흔히 일어납니다. |
쓰기 전에 이것이 어느 언어인지를 확인하세요 — 구분법은 간단해서 $ 로 시작하면 JSONPath, $ 가 없고 [] 나 | 를 쓰면 JMESPath, .field 나 select() 나 파이프가 늘어서면 jq 입니다. 한 가지 더, JSONPath 는 읽기 전용입니다 — 값의 수정, 구조의 재구성, 집계는 할 수 없습니다. 꺼낸 뒤에 가공하고 싶다면 jq 를 쓰세요 — jq 는 변환 언어이므로 map · group_by · reduce 까지 갖춰져 있습니다. 용도의 기준으로는 설정 파일에서 값을 하나 꺼낸다면 JSONPath, 셸에서 JSON 을 가공한다면 jq, AWS 를 다룬다면 JMESPath 입니다 — 고를 수 있는 장면이라면 그 환경에서 이미 쓰이고 있는 것에 맞추는 것이 가장 마찰이 적습니다. |
JSONPath 를 쓰기 전에 애초에 필요한지를 생각하세요. 프로그램 안에서 JSON 을 다룬다면 파싱한 뒤 네이티브 구조로서 따라가는 편이 타입이 붙고 에러의 위치도 알 수 있고 테스트도 쓸 수 있습니다 — data.store.book.filter(b => b.price < 10) 쪽이 $.store.book[?(@.price<10)] 이라는 문자열에 심어진 식보다 확실히 읽기 쉽고 IDE 의 보완도 듣습니다. JSONPath 가 정말로 유효한 것은 쿼리를 실행 시에 정하고 싶을 때 — 설정 파일에서 추출 조건을 지정한다, 사용자가 매핑을 정의한다, 로그의 검색 조건을 저장한다 같은 쿼리가 데이터인 장면입니다. 그 경우에는 외부에서 받은 쿼리의 취급에 주의하세요 — JSONPath 자체는 코드 실행을 포함하지 않지만 재귀 하강 $.. 을 거대한 JSON 에 대해 실행당하면 CPU 와 메모리를 소비하게 됩니다. 입력 크기와 식의 복잡성 양쪽에 상한을 두세요.
📖 사용법
-
1
JSON 붙여넣기왼쪽에 JSON 데이터를 붙여넣으세요. 샘플 버튼으로 시도할 수 있습니다.
-
2
쿼리 입력$ 로 시작하는 JSONPath 식을 입력하면 실시간으로 결과가 업데이트됩니다.
-
3
결과 확인일치한 값의 배열이 오른쪽에 표시됩니다. 건수와 오류도 함께 표시됩니다.
❓ 자주 묻는 질문
JSONPath란?
필터 식은 어떻게 쓰나요?
재귀 하강은 언제 쓰나요?
🔗 관련 도구
🐛 이 도구에서 문제가 발생했나요?
무료 · 가입 불필요. 재현 절차만이라도 도움이 됩니다. 보고는 운영자에게 직접 전달되어 개선에 사용됩니다.
보고 감사합니다!
운영자에게 전달되었습니다. 개선에 사용됩니다.