Trình Trích Xuất JSON Path

Cách thức hoạt động

1. Dán JSON của bạn: nhập một đối tượng hoặc một mảng JSON vào trường nhập.
2. Nhập một biểu thức JSONPath: gõ một đường dẫn như $.store.book[*].author hoặc $.users[?(@.age > 18)] để chọn các dữ liệu mong muốn.
3. Hình dung các kết quả được trích xuất: các giá trị tương ứng xuất hiện ngay lập tức trong bảng đầu ra. Sao chép kết quả hoặc xuất nó.

Tại sao sử dụng bộ trích xuất JSONPath?

Khi bạn làm việc với các phản hồi API phức tạp hoặc JSON được lồng sâu, trích xuất các giá trị cụ thể bằng tay là chậm và dễ mắc lỗi. JSONPath là ngôn ngữ truy vấn cho JSON, tương tự như XPath cho XML. Nó cho phép nhắm chính xác các dữ liệu bạn cần với một biểu thức đường dẫn ngắn gọn, cho dù đó là một giá trị được lồng duy nhất, tất cả các phần tử của một mảng hay các bản ghi đã lọc tương ứng với một điều kiện. Công cụ này làm cho khám phá JSONPath trở nên tương tác mà không cần viết mã.

Tính năng

• Hỗ trợ đầy đủ JSONPath: ký hiệu dấu chấm, ký hiệu trong ngoặc, ký tự đại diện (*), descent đệ quy (..), các bộ lọc (?()) và các slice mảng.
• Đánh giá trực tiếp: các kết quả cập nhật khi bạn gõ biểu thức JSONPath của bạn.
• Đầu ra được định dạng: các giá trị được trích xuất được hiển thị dưới dạng JSON được định dạng đẹp.
• Nhiều kết quả khớp: trả về tất cả các nút khớp của tài liệu JSON.
• Báo cáo các lỗi: các thông báo rõ ràng khi biểu thức đường dẫn không hợp lệ hoặc không tạo ra kết quả khớp nào.

Câu hỏi thường gặp

JSONPath là gì?

JSONPath là một ngôn ngữ truy vấn cho các tài liệu JSON, tương tự với XPath cho XML. Một đường dẫn như $.users[*].name chọn trường name của mỗi đối tượng trong mảng users. Nó được sử dụng rộng rãi cho kiểm tra API, biến đổi dữ liệu và xử lý JSON.

Cách lọc các phần tử của một mảng theo một điều kiện?

Sử dụng một biểu thức bộ lọc: $.items[?(@.price < 50)] trả về tất cả các phần tử có giá dưới 50. Ký hiệu @ chỉ phần tử đang được đánh giá.

Nó có hỗ trợ tìm kiếm đệ quy không?

Có. Toán tử .. thực hiện tìm kiếm đệ quy ở tất cả các cấp. Ví dụ, $..name tìm tất cả các khóa name ở bất kỳ đâu trong cấu trúc JSON, bất kể độ sâu lồng nhau.

Từ một bài blog đến RFC 9535: con đường 17 năm để có một tiêu chuẩn JSONPath

Stefan Gössner đã đề xuất JSONPath trong một bài blog duy nhất vào tháng 2 năm 2007, điều chỉnh ý tưởng XPath cho JSON. Ông đã xuất bản một triển khai JavaScript tham chiếu, phác thảo cú pháp (gốc $, các toán tử con dấu chấm và dấu ngoặc, .. cho việc xuống đệ quy, * cho ký tự đại diện, [bắt_đầu:kết_thúc:bước] cho cắt mảng, [?(...)] cho biểu thức lọc) và hệ sinh thái rộng lớn hơn đã theo. Các triển khai sinh sôi nảy nở: jsonpath cho JavaScript, JsonPath cho Java, jq (Stephen Dolan, 2012) gần với JSONPath nhưng là cái của riêng nó, jsonpath-ng cho Python, JMESPath (AWS, 2014) như một đối thủ nghiêm ngặt hơn. Vấn đề: mọi triển khai đều trôi dạt. Cú pháp bộ lọc, ngữ nghĩa đệ quy, khớp regex, định danh gốc, tất cả đều khác nhau một cách tinh tế giữa các thư viện. Một nghiên cứu so sánh năm 2023 của Carsten Bormann et al. đã kiểm tra 41 triển khai JSONPath riêng biệt với cùng một đầu vào và nhận được 41 bộ kết quả khác nhau cho cùng một biểu thức. Nhóm Công tác JSONPath của IETF đã tập hợp vào năm 2020 để khắc phục điều này. RFC 9535 «JSONPath: Query Expressions for JSON» được xuất bản vào tháng 2 năm 2024, trở thành tiêu chuẩn chính thức đầu tiên cho JSONPath, 17 năm sau bài đăng gốc của Gössner. RFC 9535 mã hóa cú pháp, định nghĩa một định dạng đầu ra chuẩn hóa, yêu cầu chuẩn hóa Unicode cho các so sánh chuỗi, và thêm một bộ kiểm tra tuân thủ.

Bảng tóm tắt cú pháp JSONPath

Bảy toán tử bao gồm hầu hết các truy vấn thế giới thực:

• $ gốc. Mỗi đường dẫn bắt đầu ở đây. $ một mình trả về toàn bộ tài liệu.
• .tên con theo tên. $.store.book chọn trường book bên trong store. Tên có khoảng trắng hoặc ký tự đặc biệt cần ký pháp dấu ngoặc: $['book title'].
• [0] chỉ số mảng. $.book[0] phần tử đầu tiên. $.book[-1] phần tử cuối cùng (bổ sung RFC 9535).
• [bắt_đầu:kết_thúc:bước] cắt mảng. Kiểu Python: $.book[1:3] phần tử 1 và 2, $.book[::2] mỗi phần tử khác. bước có thể âm để đảo ngược.
• * ký tự đại diện. $.book[*].title tiêu đề của mỗi cuốn sách. Cũng hoạt động như ký tự đại diện thuộc tính: $.store.* tất cả các con trực tiếp của store.
• .. xuống đệ quy. $..title tìm mọi trường title ở bất kỳ độ sâu nào. Mạnh mẽ nhưng chậm trên các tài liệu lớn.
• [?(...)] biểu thức lọc. $.book[?(@.price < 10)] tất cả sách có giá dưới 10. @ có nghĩa là «phần tử hiện tại». RFC 9535 đặt tên cái này là ? và chuẩn hóa các toán tử so sánh == != < <= > >= cộng boolean && ||. Chế độ nhanh của viewer này không đánh giá các biểu thức lọc, sử dụng một thư viện như jsonpath-plus nếu bạn cần chúng.

Nơi bạn thực sự với tay đến JSONPath

• Lọc đầu ra kubectl. kubectl get pods -o jsonpath='{.items[*].metadata.name}' được vận chuyển trong Kubernetes và là một người dùng JSONPath sử dụng hàng ngày. Hương vị Kubernetes bỏ $ ở đầu và có một vài đặc điểm đáng chú ý nếu bạn sống trong hệ sinh thái đó.
• Kiểm tra API với Postman hoặc Insomnia. Các khẳng định kiểm tra như pm.expect(jsonData.items[0].status).to.eql('active') thường được biểu diễn dưới dạng JSONPath dưới mui xe.
• Bảng điều khiển Grafana / khả năng quan sát. Các bảng nguồn dữ liệu JSON truy vấn các số liệu sử dụng JSONPath; các bộ thu OpenTelemetry sử dụng cú pháp giống JSONPath để trích xuất các thuộc tính span.
• Trích xuất CLI nhanh. Kết hợp công cụ này với curl | jq để khám phá API trực tiếp: tạo nguyên mẫu đường dẫn trong viewer, sau đó dịch sang cú pháp jq cho các tập lệnh shell. (jq sử dụng ký pháp dấu chấm nhưng không hoàn toàn là JSONPath.)
• ETL và kỹ thuật dữ liệu. Các ánh xạ Airflow XCom, các tệp seed dbt, và trích xuất cột JSON SQL tất cả đều sử dụng các biểu thức giống JSONPath để vươn tới các payload lồng nhau.
• Kiểm tra token. Đi sâu vào một JWT đã giải mã: $.payload.iss cho nhà phát hành, $..roles[*] cho mỗi vai trò được cấp ở bất kỳ đâu trong cây yêu sách.
• Thiết kế trình xử lý webhook. Trước khi viết mã trình xử lý, dán một payload webhook thực và tạo nguyên mẫu các đường dẫn rút ra các trường mà hệ thống của bạn quan tâm. Tiết kiệm một chuyến đi vòng với dịch vụ thượng nguồn.

Những lỗi cắn

• Sự trôi dạt triển khai. Một đường dẫn hoạt động trong một thư viện có thể tạo ra kết quả khác hoặc không có kết quả trong một thư viện khác. Trước RFC 9535 không có gì được chuẩn hóa. Bây giờ hãy tìm «tuân thủ RFC 9535» trong tài liệu thư viện của bạn (bộ kiểm tra IETF được công bố cùng với RFC).
• Trích dẫn bộ lọc. $.book[?(@.title=="Foo")] yêu cầu trích dẫn kép bên trong bộ lọc trong RFC 9535; nhiều thư viện cũ hơn cũng chấp nhận trích dẫn đơn 'Foo'. Trộn lẫn chúng là một nguyên nhân phổ biến của «lỗi cú pháp» trong sản xuất.
• Xuống đệ quy là tham lam. $..* trả về mỗi giá trị trong tài liệu, bao gồm các đối tượng và mảng lồng nhau, không chỉ lá. Trên các tài liệu lớn việc này có thể mất vài giây. Thu hẹp đường dẫn trước, sau đó hạ xuống.
• Khóa số nguyên vs chuỗi. JSON chỉ có khóa chuỗi, ngay cả khi chúng trông số. $.users.123 và $.users[123] có nghĩa khác nhau trong một số thư viện: cái đầu tiên tìm kiếm một thuộc tính có tên là "123" theo nghĩa đen, cái thứ hai có thể được hiểu là chỉ số mảng 123.
• Slice âm. $.book[-1:] có nghĩa là «phần tử cuối cùng» trong RFC 9535 và hầu hết các triển khai, nhưng trước năm 2024 một số thư viện coi các chỉ số âm là lỗi. Nếu bạn nhắm mục tiêu các parser cũ hơn, hãy sử dụng các chỉ số tuyệt đối.
• Quên $. Một đường dẫn không có $ ở đầu không hợp lệ trong RFC 9535. Một số triển khai chấp nhận .store.book như là viết tắt, những triển khai khác từ chối nó. Luôn thêm tiền tố $.
• Hiệu suất. Xuống đệ quy .. trên một tài liệu 10 MB có thể là O(n) cho mỗi khớp. Đối với các cột kho dữ liệu hoặc vòng lặp nóng, hãy trích xuất trước một lần với $.., lưu vào bộ đệm kết quả, sau đó đi qua mảng đã lưu vào bộ đệm. Không bao giờ chạy một JSONPath phức tạp trên mỗi yêu cầu.

JSONPath vs jq vs JMESPath vs JSON Pointer

• JSONPath (RFC 9535). Tốt nhất cho các truy vấn đặc biệt và các tệp cấu hình. Cú pháp quen thuộc từ XPath, tiêu chuẩn mới, nhiều thư viện ngôn ngữ hỗ trợ nó.
• jq. Một ngôn ngữ chuyển đổi dữ liệu đầy đủ, không chỉ là một truy vấn đường dẫn. Thêm map/filter/reduce, các hàm chuỗi, toán học, định dạng. Tốt hơn khi bạn cần định hình lại dữ liệu, không chỉ trích xuất nó. Có cú pháp riêng với ký pháp dấu chấm nhưng tách biệt với JSONPath ở cấp độ bộ lọc.
• JMESPath. Một giải pháp thay thế năm 2014 được sử dụng bởi AWS CLI (aws ec2 describe-instances --query "..."). Nghiêm ngặt và chức năng hơn JSONPath, có một ngữ pháp thực sự từ ngày đầu, hỗ trợ các phép chiếu và toán tử ống. Ít phổ biến hơn bên ngoài hệ sinh thái Amazon.
• JSON Pointer (RFC 6901). Một tiêu chuẩn năm 2013 để định địa chỉ một giá trị duy nhất: /store/book/0/title. Không thể làm ký tự đại diện, bộ lọc, hoặc đệ quy. Được sử dụng bởi JSON Patch (RFC 6902), JSON Schema $ref, và API patch Kubernetes. Chọn cái này khi bạn cần định địa chỉ chính xác, không phải truy vấn.

Các câu hỏi thường gặp khác

JSONPath có giống XPath không?

Được truyền cảm hứng bởi nó, không giống. XPath đã được W3C hoàn thiện năm 1999 cho XML, JSONPath đã được Gössner phác thảo năm 2007 để mang ý tưởng tương tự đến JSON. Sự khác biệt lớn nhất: JSONPath sử dụng . và [] thay vì /, JSONPath không có khái niệm về không gian tên hoặc thuộc tính XML, JSONPath được chuẩn hóa sau nhiều năm (2024 vs 1999), nên trong nhiều năm nó là một cú pháp thực tế với nhiều triển khai không tương thích.

Tại sao cùng một JSONPath cho kết quả khác nhau trong các công cụ khác nhau?

Bởi vì JSONPath không được chuẩn hóa cho đến RFC 9535 (tháng 2 năm 2024). Trước đó, mỗi triển khai đưa ra lựa chọn riêng về cú pháp bộ lọc, hỗ trợ regex, định danh gốc, quy tắc thoát, và các trường hợp cạnh (mảng trống, khóa thiếu, ép kiểu trong bộ lọc). Một nghiên cứu của nhóm công tác IETF năm 2023 đã kiểm tra 41 triển khai trên cùng một đầu vào và nhận được 41 bộ kết quả khác nhau. RFC 9535 sửa chữa điều này cho các thư viện mới và được cập nhật; các thư viện cũ hơn sẽ phân kỳ cho đến khi chúng di chuyển. Luôn kiểm tra xem thư viện của bạn có tuyên bố «tuân thủ RFC 9535» không.

Tôi có thể sửa đổi JSON với JSONPath, hay chỉ đọc?

RFC 9535 định nghĩa JSONPath nghiêm ngặt là một ngôn ngữ truy vấn: nó trả về các giá trị từ một tài liệu, nó không biến đổi. Để sửa đổi JSON, sử dụng JSON Patch (RFC 6902), sử dụng các đường dẫn JSON Pointer và các hoạt động add/remove/replace/copy/move/test. Một số thư viện kết hợp cả hai (ví dụ: jsonpath-plus trong JavaScript có một phần mở rộng đột biến apply()) nhưng đó không phải JSONPath tiêu chuẩn.

JSONPath có hỗ trợ biểu thức chính quy trong bộ lọc không?

RFC 9535 đã thêm hai hàm regex: match(node, regex) khớp toàn bộ chuỗi, search(node, regex) khớp bất kỳ chuỗi con nào. Ví dụ: $.book[?(match(@.isbn, "^978-"))]. Hương vị regex là I-Regexp (RFC 9485, một hồ sơ của regex XML Schema), không phải PCRE hoặc regex JavaScript. Các thư viện cũ hơn sử dụng hương vị regex của ngôn ngữ chủ của họ, điều này làm cho các truy vấn regex đặc biệt không thể chuyển đổi được.

JSON của tôi có được gửi đi đâu khi tôi sử dụng công cụ này không?

Không. Đánh giá đường dẫn chạy hoàn toàn trong động cơ JavaScript của trình duyệt của bạn. Mở tab Mạng trong DevTools và chạy một truy vấn, bạn sẽ thấy không có yêu cầu đi ra trong khi đánh giá. An toàn cho các phản hồi API với các bí mật, các bãi rác cơ sở dữ liệu với PII, hoặc các tệp cấu hình chứa thông tin xác thực.