Định dạng JSON

JSON—JavaScript Object Notation—là định dạng dựa trên văn bản phổ biến để trao đổi dữ liệu có cấu trúc. Nó được chuẩn hóa bởi cả IETF với tên gọi RFC 8259 và bởi Ecma International với tên gọi ECMA-404, cùng nhau xác định cú pháp nhỏ gọn, không phụ thuộc vào ngôn ngữ, cung cấp năng lượng cho các API, nhật ký, cấu hình và cơ sở dữ liệu hiện đại.

Cú pháp và mã hóa: các bit chính xác giúp các hệ thống giao tiếp

Một giá trị JSON là một đối tượng, mảng, chuỗi, số, hoặc một trong các giá trị chữ true, false, hoặc null; các đối tượng ánh xạ chuỗi tới các giá trị và các mảng chứa các giá trị có thứ tự—với khoảng trắng không đáng kể được phép xung quanh các ký tự cấu trúc (RFC 8259, ECMA-404). Mặc dù JSON có nguồn gốc từ JavaScript, nó độc lập với ngôn ngữ và được hỗ trợ ở hầu hết mọi nơi (MDN: JSON). Trên đường truyền, mã hóa trên thực tế và được khuyến nghị là UTF-8 (RFC 8259 §8.1). Để tăng cường tính tương thích, hồ sơ I-JSON (RFC 7493) thắt chặt các quy tắc về mã hóa và phạm vi số.

Trong JavaScript, đối tượng toàn cục JSON cung cấp hai công cụ chính:JSON.parse (với một reviver tùy chọn) và JSON.stringify (với replacer/spacing để in đẹp), như được ghi lại trên MDN (parse, stringify).

Số: trông đơn giản nhưng lại rất sắc bén

Ngữ pháp số của JSON là thập phân, nhưng đặc tả không quy định độ chính xác hoặc sự phân biệt số nguyên/số thực. Các triển khai tự chọn cách biểu diễn chúng (RFC 8259 §6). Trong JavaScript và Node.js, Number là độ chính xác kép IEEE-754, có nghĩa là chỉ các số nguyên trong [−(2^53−1), 2^53−1] mới thực sự an toàn—xem Number.MAX_SAFE_INTEGER và kiểu BigInt. Đây là lý do tại sao các API công khai thường gửi ID dưới dạng chuỗi và xác thực "số nguyên an toàn" một cách rõ ràng.

Ngoài JSON thông thường: con trỏ, bản vá và bản vá hợp nhất

Khi việc sử dụng trở nên phổ biến, các tiêu chuẩn đã xuất hiện để định vị và sửa đổi JSON tại chỗ. JSON Pointer (RFC 6901) là một cú pháp nhỏ gọn, được phân tách bằng dấu gạch chéo để định vị các giá trị (ví dụ: /a/b/0) với các quy tắc thoát cho ~ và /. JSON Patch (RFC 6902) mô hình hóa các bản cập nhật một phần dưới dạng các thao tác có thứ tự (add, remove, replace, move, copy, test) và được truyền dưới dạng application/json-patch+json. Đối với các khác biệt đơn giản hơn, JSON Merge Patch (RFC 7386) sử dụng một phép hợp nhất có hình dạng tài liệu: các trường hiện có được thêm/thay thế; đặt một trường thành null sẽ xóa nó. Nhiều framework hỗ trợ một hoặc cả hai hình thức này ngay từ đầu.

Lược đồ và kiểu: xác thực và tạo

Bản thân JSON không có lược đồ, nhưng các hệ sinh thái dựa vào lược đồ để xác thực, tài liệu và tạo mã. Họ JSON Schema 2020-12 chỉ định các ràng buộc như type, properties, items, và các từ khóa σύνθεσης, và nó phù hợp với OpenAPI 3.1. Đối với các quy trình làm việc tập trung vào việc tạo mã, JSON Type Definition (RFC 8927) cung cấp một ngôn ngữ có chủ ý ít biểu cảm hơn, có thể ánh xạ một cách có thể dự đoán được tới các hệ thống kiểu chính thống.

Luồng và dữ liệu lớn: các dòng và chuỗi JSON

JSON cổ điển mong đợi một văn bản hoàn chỉnh cho mỗi tải trọng, điều này làm phức tạp việc truyền phát nhật ký và các phản hồi kéo dài. Hai mẫu giúp ích:

• Chuỗi văn bản JSON (RFC 7464): một luồng các văn bản JSON UTF-8, mỗi văn bản được bắt đầu bằng Dấu phân tách bản ghi (U+001E) và kết thúc bằng LF; được đăng ký là application/json-seq.
• NDJSON / JSON Lines: mỗi dòng là một giá trị JSON độc lập— dễ dàng theo dõi, nén gzip và map-reduce (ndjson.org, jsonlines.org). Nó phổ biến trong các API hàng loạt, ví dụ: API hàng loạtcủa Elasticsearch.

Các anh em họ nhị phân: khi văn bản không đủ nhỏ gọn

Khi băng thông hoặc tốc độ chiếm ưu thế, các định dạng "JSON nhị phân" bảo tồn mô hình dữ liệu của JSON trong khi đánh đổi khả năng đọc của con người để lấy hiệu quả:

• BSON (định dạng gốc của MongoDB) thêm các kiểu như nhị phân, ngày giờ và số nguyên có kiểu (bsonspec.org).
• MessagePack nhỏ gọn và không có lược đồ, được triển khai rộng rãi trên các ngôn ngữ (msgpack.org).
• CBOR chuẩn hóa một định dạng có thể mở rộng, nhỏ gọn (với hướng dẫn chuyển mã JSON) và phổ biến trong các ngữ cảnh IoT/hạn chế (RFC 8949, cbor.io).
• Smile (từ hệ sinh thái Jackson) mã hóa JSON với các tham chiếu ngược tùy chọn cho các tên/giá trị lặp lại (jackson-dataformat-smile).

Ghi chú bảo mật: các thủ thuật cũ và các bản sửa lỗi hiện đại

Bởi vì JSON chỉ là văn bản, hầu hết các rủi ro đến từ cách bạn vận chuyển và xử lý nó:

• JSONP (yêu cầu dữ liệu qua <script> với một cuộc gọi lại) là một giải pháp thay thế trước CORS cho các yêu cầu từ các nguồn khác nhau nhưng nguy hiểm—nó thực thi tập lệnh tùy ý. Ưu tiên CORS với các phản hồi application/json thực (OWASP: Lạm dụng JSONP).
• Chiếm quyền điều khiển JSON: các điểm cuối GET ngây thơ trả về các mảng nhạy cảm có thể bị đánh cắp qua các thẻ tập lệnh từ các nguồn khác nhau trong các trình duyệt cũ hơn; các biện pháp giảm thiểu bao gồm POST với bảo vệ CSRF hoặc tiền tố bằng một sentinel không phải JSON (OWASP: Chiếm quyền điều khiển JSON).
• Tiêm nhiễm JSON: coi JSON là dữ liệu, không phải mã; thoát cẩn thận và xác thực đầu vào (OWASP: Tiêm nhiễm JSON).

Các loại phương tiện và di sản

JSON ra mắt dưới RFC 4627 (2006); loại phương tiện đã đăng ký là application/json, đặc tả của nó hiện trỏ đến RFC 8259. Các tham số "charset" trên các phản hồi JSON thường không cần thiết vì UTF-8 là mặc định trên internet công cộng.

Các mẹo thực tế cho JSON mạnh mẽ trong sản xuất

• Mặc định sử dụng UTF-8 ở mọi nơi; giả định UTF-8 ở đầu vào và đầu ra (RFC 8259 §8.1).
• Rõ ràng với các số nguyên lớn: nếu một ID có thể vượt quá 2^53−1, hãy gửi nó dưới dạng một chuỗi và ghi lại nó (MDN: MAX_SAFE_INTEGER).
• Xác thực tải trọng với JSON Schema 2020-12 (hoặc JTD cho các ngăn xếp nặng về tạo mã). Xuất bản các lược đồ bên cạnh tài liệu API của bạn (OpenAPI 3.1).
• Vá một cách khôn ngoan: sử dụng JSON Patch cho các khác biệt ở cấp độ hoạt động và Merge Patch cho các bản cập nhật đơn giản có hình dạng tài liệu.
• Truyền phát ở quy mô lớn: chọn Chuỗi văn bản JSON hoặc NDJSON cho các nhật ký và các phản hồi kéo dài; làm cho loại phương tiện rõ ràng.
• Sử dụng nhị phân ( BSON, MessagePack, CBOR, Smile) khi văn bản là nút thắt cổ chai—nhưng đảm bảo cả hai đầu đều đồng ý về các kiểu.

Một vài lời về "các JSON thân thiện hơn"

Các nhà phát triển thường muốn có các bình luận, dấu phẩy ở cuối hoặc các chuỗi được trích dẫn đơn trong các cấu hình. Điều đó nằm ngoài JSON tiêu chuẩn, nhưng JSON5 cung cấp một siêu tập hợp được ghi chép đầy đủ cho các tệp do con người chỉnh sửa. Tránh gửi JSON5 qua các API công khai trừ khi bạn kiểm soát cả hai đầu.

Thành công của JSON đến từ một bề mặt nhỏ, hỗ trợ ngôn ngữ rộng rãi và một vòng các tiêu chuẩn liền kề—con trỏ, vá, lược đồ, chuỗi—bao gồm các thực tế lộn xộn của các hệ thống phân tán. Hiểu các nguyên tắc cơ bản (cú pháp, mã hóa, số), dựa vào các tiêu chuẩn liền kề phù hợp, và nó sẽ tiếp tục mang lại lợi ích trên các ngăn xếp và dịch vụ (RFC 8259, ECMA-404, RFC 6901, RFC 6902, RFC 7386, JSON Schema, JTD, RFC 7464, NDJSON).