Trình Xem Cây JSON

JSON, định dạng dữ liệu đã chiến thắng

Douglas Crockford đã công bố JSON trên json.org vào năm 2001 như một giải pháp thay thế nhẹ cho XML, lấy cú pháp trực tiếp từ các literal đối tượng của JavaScript. Định dạng này lần đầu tiên được tiêu chuẩn hóa thành Internet-Draft IETF trong RFC 4627 (tháng 7 năm 2006), sau đó được sửa đổi thành RFC 7159 (tháng 3 năm 2014), và cuối cùng được thiết lập trong RFC 8259 (tháng 12 năm 2017), đây là tiêu chuẩn hiện tại và được giữ phù hợp với ECMA-404 (phiên bản 1 tháng 10 năm 2013, phiên bản 2 tháng 12 năm 2017). RFC 8259 đã thêm một yêu cầu quan trọng: mã hóa ở tầng mạng phải là UTF-8. Hai đặc tả bổ sung hoàn thiện hệ sinh thái: RFC 6901 «JSON Pointer» (tháng 4 năm 2013) định nghĩa cú pháp /store/book/0/title để định địa chỉ các nút bên trong tài liệu, và RFC 6902 «JSON Patch» định nghĩa một tài liệu JSON mô tả các thay đổi để áp dụng cho một tài liệu JSON khác. JSON Schema (bản nháp IETF hiện tại 2020-12) thêm xác thực. Mọi thứ khác được xây dựng dựa trên đó, JSONC cho các bình luận tệp cấu hình, JSON5 cho cú pháp lỏng lẻo, NDJSON cho streaming, đã đến sau.

Sáu kiểu giá trị JSON (và điều gì còn thiếu)

RFC 8259 §3 định nghĩa chính xác sáu kiểu giá trị. Không có gì khác.

• đối tượng: tập hợp không thứ tự các cặp tên-giá trị được phân định bởi dấu ngoặc nhọn. Khóa luôn là chuỗi.
• mảng: danh sách giá trị có thứ tự được phân định bởi dấu ngoặc vuông. Có thể chứa các loại hỗn hợp.
• chuỗi: ký tự Unicode trong dấu ngoặc kép. Dấu ngoặc đơn không phải JSON hợp pháp.
• số: dấu phẩy động độ chính xác kép IEEE 754. Đặc tả không đảm bảo độ chính xác tùy ý; các số vượt quá Number.MAX_SAFE_INTEGER = 2⁵³ − 1 = 9 007 199 254 740 991 mất độ chính xác khi được phân tích cú pháp.
• true / false: literal boolean, chữ thường, không có dấu nháy.
• null: literal null, chữ thường, không có dấu nháy. Một khóa có giá trị null khác với một khóa vắng mặt.

Những gì JSON không có: kiểu ngày (quy ước là chuỗi ISO 8601 với múi giờ), bình luận (sử dụng trường siêu dữ liệu riêng), dấu phẩy cuối, chuỗi nháy đơn, số thập lục phân, undefined, NaN, hoặc Infinity. Bất kỳ điều nào trong số đó sẽ khiến JSON.parse ném SyntaxError.

JSON nghiêm ngặt, JSONC, JSON5: ai là ai

JSON nghiêm ngặt (RFC 8259) là những gì trình xem này chấp nhận: không có bình luận, không có dấu phẩy cuối, khóa nháy kép, chuỗi nháy kép. JSONC là quy ước của Microsoft được vận chuyển trong VS Code cho phép bình luận dòng // và bình luận khối /* ... */ trong khi giữ mọi thứ khác nghiêm ngặt; bạn thấy nó trong tsconfig.json, .vscode/settings.json, và gói npm jsonc-parser. JSON5 (2017, https://json5.org) là một superset thêm chuỗi nháy đơn, khóa không nháy, dấu phẩy cuối, số thập lục phân, các giá trị đặc biệt IEEE 754 (NaN, Infinity), và cả bình luận dòng và khối; gói npm json5 có khoảng 10 triệu lượt tải xuống hàng tuần. NDJSON / JSON Lines (https://jsonlines.org) là một biến thể streaming trong đó mỗi dòng là một tài liệu JSON độc lập, được sử dụng bởi các log shipper và pipeline thu nhận big-data. Loại bỏ các bình luận và dấu phẩy cuối trước khi dán nếu nguồn của bạn là JSONC hoặc JSON5.

Nơi mà trình xem cây thực sự kiếm được tiền lương của mình

• Kiểm tra phản hồi API. Stripe, GitHub, Slack, Twilio: mọi API hiện đại đều trả về JSON lồng nhau. Dán vào trình xem cây làm cho hình dạng trở nên rõ ràng.
• Tệp cấu hình. package.json, tsconfig.json, composer.json, kubeconfig, và phần đuôi dài của các config JSON nhà cung cấp đám mây đều trở nên dễ kiểm tra hơn dưới dạng cây.
• Kiểm tra xuất cơ sở dữ liệu. Đầu ra MongoDB find(), các hàng PostgreSQL row_to_json, danh sách hit ElasticSearch.
• Khám phá lược đồ. Khi một API không có tài liệu, trình xem cây là tài liệu.
• Chuẩn bị diff. Trước khi chạy json-diff hoặc jq giữa hai tệp, hãy kiểm tra từng tệp trong trình xem để phát hiện thủ công các sự khác biệt rõ ràng.
• Kiểm tra payload webhook. Stripe, GitHub, SendGrid và các dịch vụ tương tự đều gửi webhook JSON. Dán payload vào trình xem là cách nhanh nhất để xác minh những gì endpoint của bạn sẽ nhận được.
• Tạo dữ liệu mẫu. Xây dựng một fixture kiểm thử bằng cách nhập JSON và xem cây cập nhật từng bước; bắt được các dấu ngoặc bị thiếu trước khi bạn lưu tệp.

Sai lầm phổ biến khi làm việc với JSON

• Dấu phẩy cuối. {"a": 1,} là JavaScript hợp pháp nhưng JSON không hợp pháp. JSON.parse ném SyntaxError: Unexpected token '}'. Loại bỏ chúng hoặc chuyển sang JSON5.
• Bình luận. // như thế này hoặc /* như thế này */ hợp lệ trong JavaScript và JSONC nhưng không hợp lệ trong JSON nghiêm ngặt.
• Mất độ chính xác số nguyên lớn. ID Twitter và Stripe có thể vượt quá 2⁵³; JSON.parse("9007199254740993") trả về 9007199254740992. Nhận chúng dưới dạng chuỗi nếu độ chính xác quan trọng.
• Nhầm lẫn null với vắng mặt. {"foo": null} có foo được định nghĩa là null; {} có foo không xác định. Sự phân biệt này quan trọng đối với các hợp đồng API và xử lý NULL của cơ sở dữ liệu.
• Khóa trùng lặp. RFC 8259 nói rằng hành vi không được định nghĩa; trong thực tế mọi engine JS đều giữ giá trị cuối cùng. {"a": 1, "a": 2} phân tích thành {a: 2}.
• Tham chiếu vòng tròn. JSON.stringify ném TypeError: Converting circular structure to JSON. Phẳng hóa các chu kỳ, sử dụng replacer, hoặc sử dụng thư viện như flatted.
• Chuỗi ngày không có múi giờ. "2026-05-12" là mơ hồ; "2026-05-12T18:30:00Z" là ISO 8601 không mơ hồ trong UTC. Luôn bao gồm offset.

Thêm câu hỏi thường gặp

Trình xem này có thể xử lý tệp JSON lớn đến mức nào?

Phân tích cú pháp 1 MB với JSON.parse mất khoảng 10 ms trong V8. Kết xuất 100.000 nút DOM thu gọn có thể đóng băng trình duyệt trong vài giây. Trong thực tế, trình xem này thoải mái lên đến khoảng 5 MB; vượt quá đó, mong đợi độ trễ đáng chú ý trong quá trình kết xuất. Đối với các tài liệu lớn hơn, sử dụng trình phân tích streaming như stream-json trong Web Worker, hoặc phân trang đầu vào thành các phần.

Tại sao số nguyên lớn của tôi trả về sai?

Các số JavaScript là float độ chính xác kép IEEE 754. Số nguyên lên đến 2⁵³ − 1 = 9 007 199 254 740 991 sống sót qua một chuyến đi-về chính xác; vượt quá đó, độ chính xác bị mất. ID snowflake Twitter (64-bit), ID khách hàng Stripe, ID giao dịch blockchain, và nhiều khóa thay thế cơ sở dữ liệu vượt quá giới hạn này. JSON.parse sẽ âm thầm cắt cụt. Khắc phục là nhận ID dưới dạng chuỗi (hầu hết các API hiện đại làm điều này) hoặc phân tích bằng thư viện hỗ trợ BigInt.

JSON Pointer là gì, và tôi sẽ sử dụng nó ở đâu?

RFC 6901 (tháng 4 năm 2013) định nghĩa một cú pháp đường dẫn để định địa chỉ các nút bên trong tài liệu JSON: /store/book/0/title chọn tiêu đề của cuốn sách đầu tiên trong mảng store. JSON Pointer là nền tảng của JSON Patch (RFC 6902), thể hiện các delta tài liệu dưới dạng mảng các cặp pointer-và-operation. Máy chủ API Kubernetes sử dụng JSON Patch cho các cập nhật gia tăng; API REST của GitHub và nhiều hệ thống khác cũng vậy.

NDJSON / JSON Lines có hoạt động trong trình xem này không?

Không. NDJSON là một giá trị JSON độc lập trên mỗi dòng, không có mảng bao bọc. JSON.parse trên toàn bộ tệp ném vì dòng thứ hai bắt đầu nơi đối tượng đầu tiên kết thúc. Bọc toàn bộ nội dung trong [ và ] và thay thế mỗi dòng mới giữa các đối tượng bằng dấu phẩy, hoặc dán mỗi lần một dòng, hoặc sử dụng trình xem NDJSON chuyên dụng.

JSON của tôi có được gửi đi đâu không?

Không. JSON.parse chạy trong engine JavaScript của trình duyệt của bạn, cây được kết xuất dưới dạng các nút DOM cục bộ, và không có bản sao dữ liệu của bạn được gửi qua mạng. Điều này an toàn cho các phản hồi API với bí mật, dữ liệu khách hàng hoặc PII. Mở tab Mạng trong DevTools và dán một mẫu: bạn sẽ thấy không có yêu cầu đi ra nào trong quá trình phân tích và kết xuất.