Trình xác thực JSON miễn phí

Về xác thực JSON

Một trình xác thực JSON trả lời một câu hỏi nhị phân, đây có phải là một tài liệu JSON đúng định dạng không?, bằng cách chuyển đầu vào cho cùng một bộ phân tích cú pháp mà trình duyệt sử dụng nội bộ và báo cáo liệu nó có chấp nhận cú pháp hay không. Công cụ này làm điều đó và chỉ điều đó. Nó không kiểm tra liệu dữ liệu bên trong tài liệu có nghĩa là những gì bạn dự định hay không. Câu hỏi thứ hai đó, tài liệu có hình dạng, kiểu và ràng buộc mà ứng dụng của bạn mong đợi không?, là xác thực schema, lãnh thổ của các công cụ như Ajv (được trình bày bên dưới). Hai hoạt động bổ sung lẫn nhau và trả lời các câu hỏi khác nhau; sử dụng một khi bạn muốn cái kia là một lỗi danh mục. Một sự tương tự hữu ích là sự phân biệt spelling-check / grammar-check trong các trình xử lý văn bản: spelling check (cú pháp) cho bạn biết mỗi từ có phải là từ thật hay không; grammar check (schema) cho bạn biết câu có ý nghĩa hay không; cả hai đều hữu ích, không có cái nào thay thế cái kia, và không có cái nào cho bạn biết bài luận có hay hay không. {"phoneNumber": 12345} là JSON đúng định dạng, nhưng nếu ứng dụng của bạn mong đợi một chuỗi được định dạng là "+1-555-555-1234", nó sai, và trình xác thực cú pháp không thể cho biết.

Ngoài kiểm tra cú pháp, công cụ này cũng cung cấp một pass "Sửa các vấn đề phổ biến" nỗ lực tốt nhất viết lại bốn cách phổ biến nhất mà các nhà phát triển vô tình viết JSON không hợp lệ: trailing comma, chuỗi trích dẫn đơn, khóa không có trích dẫn, và literal undefined (được viết lại thành null). Đó là một heuristic, không phải một parser, vì vậy hãy luôn xem xét đầu ra đã sửa trước khi áp dụng nó.

Lịch sử Ngắn của JSON

JSON có một tiểu sử ngắn đáng chú ý. Từ viết tắt được đặt ra tại State Software, Inc., một công ty tư vấn nhỏ mà Douglas Crockford và Chip Morningstar đồng sáng lập vào tháng 3 năm 2001 để xây dựng những gì sau này được gọi là ứng dụng web Ajax. Tin nhắn JSON đầu tiên được gửi vào tháng 4 năm 2001 từ một máy tính trong nhà để xe ở Vùng Vịnh của Morningstar. Crockford không tuyên bố đã phát minh ra JSON, định dạng đã tồn tại bên trong ngôn ngữ JavaScript như một tập con literal đối tượng; đóng góp của ông là tách nó ra, đặt tên cho nó, lập một trang web (json.org lên mạng vào năm 2002 với mô tả về ngữ pháp bằng ba ký hiệu và một parser tham chiếu JavaScript), và vận động cho sự áp dụng. Tháng 12 năm 2005 là khoảnh khắc mà hầu hết các nhà sử học chỉ ra là JSON băng qua dòng chính: tháng đó, Yahoo! bắt đầu cung cấp một số dịch vụ web của mình bằng JSON. IETF tiếp theo nhận nó lên: RFC 4627 ("The application/json Media Type for JSON"), do chính Crockford viết, được xuất bản vào tháng 7 năm 2006 dưới dạng tài liệu thông tin, không phải Standards Track. Các cơ quan tiêu chuẩn bắt kịp vào năm 2013-2014: ECMA-404 ấn bản đầu tiên vào tháng 10 năm 2013 (cố ý tối thiểu, sáu trang nội dung thực chất), RFC 7159 vào tháng 3 năm 2014 (nới lỏng hạn chế cấp cao nhất để bất kỳ giá trị JSON nào, không chỉ đối tượng và mảng, có thể là một tài liệu hoàn chỉnh), và cặp hiện tại vào tháng 12 năm 2017: RFC 8259 (hiện là Internet Standard STD 90) và ECMA-404 ấn bản thứ hai được căn chỉnh bình thường. Hai cái này ghép đôi: mỗi cái tham chiếu cái kia một cách quy phạm và chứa cam kết giữ chúng nhất quán. Cũng được xuất bản dưới dạng ISO/IEC 21778:2017.

Ngữ pháp JSON trong 200 Từ

Một tài liệu JSON là một giá trị duy nhất, tùy chọn được bao quanh bởi khoảng trắng. Có chính xác sáu kiểu giá trị: đối tượng, một tập hợp không có thứ tự gồm không hoặc nhiều cặp tên/giá trị, được viết {"k": v, "k2": v2}; mảng, một chuỗi có thứ tự, [v, v2, v3] (mảng bảo toàn thứ tự theo đặc tả); chuỗi, một chuỗi các ký tự Unicode được bao quanh trong dấu nháy kép (dấu nháy đơn không được phép; backslash escape \", \\, \/, \b, \f, \n, \r, \t cộng với \uXXXX; các ký tự điều khiển U+0000 đến U+001F phải được escape); số, dạng ASCII nghiêm ngặt (dấu trừ tùy chọn, phần nguyên không có số 0 đứng đầu, phần phân số tùy chọn, số mũ tùy chọn với e hoặc E); true / false, boolean JSON, chỉ chữ thường; null, sự vắng mặt của giá trị, chỉ chữ thường. Khoảng trắng giữa các token được cho phép và bị bỏ qua. Không có bình luận. Không có trailing comma. Khóa đối tượng phải là chuỗi nháy kép. Ngữ pháp vừa với một trang. Dạng số nghiêm ngặt cấm hex (0xFF), bát phân (0777), dấu +, Infinity, NaN, và dấu thập phân trailing như 1.; điều này bắt bất cứ ai viết JSON bằng tay trong môi trường chấp nhận các dạng số ECMAScript lỏng lẻo hơn, phổ biến nhất, bất cứ ai đã từng dán mã màu hex vào tệp JSON.

Tại sao Ngữ pháp Quá Nghiêm ngặt, Lựa chọn Thiết kế của Crockford

Hai sự thiếu sót cố ý chiếm phần lớn sự ma sát mà người dùng cảm thấy khi viết JSON bằng tay. Không có bình luận. JavaScript có cả bình luận // và /* */; JSON, tập con của JavaScript, không có cái nào. Lý do được Crockford nêu, đăng trên Google+ vào năm 2012, đã được trích dẫn hàng nghìn lần kể từ đó: "Tôi đã xóa các bình luận khỏi JSON vì tôi thấy mọi người đang sử dụng chúng để giữ các chỉ thị phân tích cú pháp, một thực hành sẽ phá hủy khả năng tương tác. Tôi biết rằng việc thiếu bình luận làm cho một số người buồn, nhưng không nên." Lập luận là các bình luận mời gọi sự mở rộng, nếu // @schema foo.json nằm trong config của bạn và công cụ của bạn đọc nó, thì tệp config của bạn không còn là JSON nữa. Không có trailing comma. Dấu phẩy là dấu phân cách, không phải dấu kết thúc. [1, 2, 3] là hợp pháp nhưng [1, 2, 3,] thì không. Lý do giống như đối với bình luận: tính đơn giản của ngữ pháp và tính đồng nhất giữa các parser. Chi phí là bất cứ ai chỉnh sửa một đối tượng JSON nhiều dòng, thêm một thuộc tính, sắp xếp lại các thuộc tính, xóa thuộc tính cuối cùng, phải nghĩ về dấu phẩy. Không có undefined. JavaScript có undefined; JSON thì không. Sử dụng null hoặc bỏ qua thuộc tính hoàn toàn. BOM trong đầu vào. Một byte-order mark (U+FEFF) ở đầu một tài liệu JSON bị cấm trong JSON được truyền, nhưng các parser CÓ THỂ bỏ qua một cái nếu nó xuất hiện. Trong thực tế, các tệp được lưu dưới dạng "UTF-8 với BOM" bởi các trình chỉnh sửa Windows cũ hơn âm thầm làm hỏng một số parser và âm thầm hoạt động ở những parser khác.

Lỗi JSON phổ biến:

• Dấu phẩy cuối: phần tử cuối cùng của đối tượng hoặc mảng không thể có dấu phẩy
• Dấu nháy đơn thay vì dấu nháy kép: JSON chỉ cho phép dấu nháy kép cho chuỗi
• Khóa không có dấu nháy: các khóa đối tượng phải luôn nằm trong dấu nháy kép
• Chú thích: JSON không hỗ trợ chú thích (mặc dù một số công cụ chấp nhận chúng)
• Backslash không được escape. Bên trong một chuỗi JSON, \ là ký tự escape. "C:\Users\Alice" thất bại vì \U và \A không phải là escape được nhận biết. Phương thuốc là nhân đôi mỗi backslash: "C:\\Users\\Alice".
• Ký tự điều khiển không được escape. Một dòng mới literal, tab, hoặc ký tự khác trong U+0000-U+001F bên trong một chuỗi JSON bị cấm. Hầu hết người dùng gặp điều này khi họ dán một chuỗi nhiều dòng vào một giá trị JSON mà không escape các dòng mới thành \n.
• NaN và Infinity. Không phải là một phần của ngữ pháp JSON. JSON.parse của trình duyệt sẽ từ chối chúng. JSON.stringify tạo ra null khi được yêu cầu tuần tự hóa NaN hoặc Infinity, vì vậy chuyến đi vòng âm thầm mất thông tin.
• Đầu vào trống. Ném "Unexpected end of JSON input." Cái bẫy là một phản hồi HTTP đã quay lại với Content-Type: application/json nhưng nội dung trống tạo ra lỗi này trong chuỗi fetch().then(r => r.json()).

JSON Schema, Tiêu chuẩn cho Xác thực Hình dạng

JSON Schema là một từ vựng dựa trên JSON để mô tả cấu trúc và các ràng buộc của các tài liệu JSON. Đề xuất đầu tiên được Kris Zyp gửi vào tháng 10 năm 2007; loạt IETF Internet-Draft bắt đầu với draft-zyp-json-schema-00 vào ngày 5 tháng 12 năm 2009. Các bản nháp kế tiếp đã phát triển thông qua một nửa tá tác giả và biên tập viên trong thập kỷ rưỡi tiếp theo. Phiên bản ổn định hiện tại là bản nháp 2020-12 (tên "2020-12" đề cập đến snapshot phát triển mà nó được rút ra từ đó; phát hành chính thức thực tế là ngày 16 tháng 6 năm 2022). Bốn từ khóa khẳng định được sử dụng nhiều nhất gánh phần lớn công việc hàng ngày: type (ràng buộc một giá trị vào một trong sáu kiểu JSON hoặc một danh sách các kiểu chấp nhận được), required (một danh sách tên thuộc tính mà một đối tượng phải chứa), properties (một bản đồ từ tên thuộc tính đến sub-schema cho giá trị), và items (một schema được áp dụng cho mọi phần tử của một mảng). Kết hợp với minimum, maximum, minLength, maxLength, pattern (regex), format (date-time, email, IPv4, v.v.) và các từ khóa hợp thành (allOf, anyOf, oneOf, not), JSON Schema có thể diễn đạt hầu như bất kỳ ràng buộc "hình dạng" nào mà dữ liệu của bạn cần thỏa mãn. Schema tự nó là một tài liệu JSON, đệ quy theo cách mà một số người thấy thanh lịch và một số người thấy chóng mặt.

Ajv, Trình Xác thực Schema JavaScript Thống trị

Nếu bạn muốn thực hiện xác thực schema trong JavaScript, câu trả lời kinh điển là Ajv (Another JSON Schema Validator) của Evgeny Poberezkin. Thủ thuật của nó là biên dịch schema thành JavaScript được tối ưu hóa: thay vì đi qua schema và cây dữ liệu khi chạy, nó tạo ra một hàm hard-code mọi kiểm tra và chạy ở tốc độ native. Điều này làm cho nó nhanh hơn đáng kể so với các trình xác thực ngây thơ trên các tài liệu lớn và trên các đường xác thực nóng. Ajv hỗ trợ các bản nháp JSON Schema 04, 06, 07, 2019-09 và 2020-12; đây là trình xác thực được tích hợp trong express-validator, xác thực yêu cầu AWS API Gateway và nhiều framework Node.js chính. Đối với Python, lựa chọn kinh điển là jsonschema của Julian Berman; đối với Java, json-schema-validator của Networknt. Điểm là xác thực schema là một vấn đề đã được giải quyết, trưởng thành, được trang bị tốt, nhưng đó là một vấn đề bạn phải chọn tham gia bằng cách viết schema. Công cụ này không viết schema cho bạn; nó chỉ thực hiện xác thực cú pháp.

JSON5 và JSONC, Các Superset Thoải mái

JSON5 là một superset chính thức của JSON được chỉ định tại json5.org, ban đầu được Aseem Kishore thiết kế vào năm 2012 và hiện được Jordan Tucker duy trì. Nó cho phép mọi thứ mà JSON nghiêm ngặt cấm: bình luận (cả // và /* */), trailing comma, chuỗi nháy đơn, khóa đối tượng không trích dẫn (khi chúng là định danh ECMAScript hợp lệ), số thập lục phân, dấu thập phân đầu/cuối (.5 hoặc 5.), Infinity và NaN, và số có dấu. Các tài liệu JSON5 thường sử dụng đuôi .json5 và được phân tích bởi các thư viện như gói npm json5. JSONC là chế độ "JSON với Bình luận" không chính thức của Microsoft, được sử dụng trong các tệp cài đặt VS Code (settings.json, launch.json, tasks.json). Bình luận được cho phép theo đặc tả; trailing comma được parser tham chiếu dung thứ nhưng bị đánh dấu bằng cảnh báo. Các dạng thoải mái dành cho các tệp cấu hình được chỉnh sửa bởi con người nơi kỷ luật của JSON nghiêm ngặt gây trở ngại; đối với trao đổi dữ liệu máy-với-máy, JSON nghiêm ngặt vẫn là lựa chọn đúng. Công cụ này sử dụng JSON.parse nghiêm ngặt của trình duyệt và do đó sẽ từ chối cả hai, hãy loại bỏ bình luận và trailing comma trước khi dán, hoặc sử dụng parser JSON5/JSONC để chuyển đổi sang JSON nghiêm ngặt trước.

Trình xác thực Streaming cho Đầu vào Rất Lớn

JSON.parse của trình duyệt tải toàn bộ tài liệu vào bộ nhớ dưới dạng một cây đối tượng duy nhất. Đối với hầu hết các đầu vào, điều này tốt; đối với các tệp log, xuất API đa-gigabyte hoặc các bản dump dữ liệu cảm biến, không. Cách tiếp cận streaming là tiêu thụ tài liệu dưới dạng dòng token và phát ra các sự kiện ("bắt đầu mảng", "giá trị chuỗi", "khóa đối tượng") mà không bao giờ giữ toàn bộ cấu trúc trong bộ nhớ cùng lúc. clarinet của Marak Squires là parser JSON streaming Node.js kinh điển, được mô hình hóa trên mẫu parser SAX XML. Oboe.js của Jim Higson (xuất xứ trong luận văn năm 2013 của ông) là tương đương thân thiện với trình duyệt, được thiết kế để tiêu thụ JSON qua fetch khi nó truyền vào và phát ra các sự kiện cho mỗi JSONPath phù hợp; nó không còn được duy trì tích cực nhưng kỹ thuật mà nó tiên phong vẫn hữu ích. JSONStream trên npm bọc clarinet cho việc sử dụng Node thân thiện với pipe. Một công cụ trình duyệt thuần như cái này bị giới hạn bởi bộ nhớ có sẵn; nếu bạn đang xác thực JSON quy mô gigabyte, hãy chạy một parser streaming trong Node hoặc sử dụng jq --stream tại dòng lệnh.

Nơi Xác thực JSON Quan trọng trong Quy trình Thực tế

Các tệp cấu hình là trường hợp đòn bẩy cao nhất: tsconfig.json, package.json, configs ESLint và Prettier, Docker Compose, các chính sách AWS IAM. Một ký tự không hợp lệ duy nhất có thể phá vỡ build; một trình xác thực cú pháp bắt nó trước khi build bắt. Các phản hồi API là tiếp theo: phát triển dựa trên một API bên ngoài thường có nghĩa là nhìn chằm chằm vào một payload và hỏi "cái này có thực sự là JSON hợp lệ không?" trước khi đuổi theo một lỗi parse sâu hơn trong code. Các payload webhook, sự kiện Stripe, các trigger GitHub Actions, các incoming webhooks Slack, là JSON; một dán-và-xác thực nhanh bắt các trường hợp mà một chữ ký bị lỗi hoặc một byte lạc đã làm hỏng nội dung. Các mục log (log có cấu trúc Splunk, Datadog, Loki) là JSON được phân định bởi dòng; một dòng tệ làm hỏng toàn bộ pipeline thu nạp. Các tệp JSON được tạo (lockfiles, build manifests, fixtures kiểm tra) đôi khi trôi dạt theo những cách ồn ào trong quá trình phát triển bình thường; một trình xác thực cú pháp bắt các trường hợp mà chính bước tạo đã thất bại.

Giới hạn Trung thực của một Trình xác thực Chỉ-Cú pháp

Một trình xác thực cú pháp không thể bắt các lỗi logic. Nó không thể cho bạn biết rằng một trường "số điện thoại" chứa một số nguyên thay vì một chuỗi; rằng một chuỗi "ngày" bị lỗi nhưng tình cờ là một chuỗi hợp lệ; rằng một trường bắt buộc bị thiếu; rằng một số nên dương lại âm; rằng hai trường nên khớp lại không khớp. Tất cả đều là các vấn đề xác thực schema. Pipeline đúng cho một hệ thống sản xuất là: (1) xác thực cú pháp như cổng đầu tiên, cái này có phân tích cú pháp như JSON không? (2) xác thực schema như cổng thứ hai, nó có hình dạng bạn mong đợi không? (3) xác thực logic kinh doanh như cổng thứ ba, dữ liệu có ý nghĩa khi xem xét trạng thái khác không? Các công cụ tồn tại cho cả ba lớp; cái này chỉ xử lý lớp đầu tiên. Lợi thế của việc dán một payload vào một trình xác thực cú pháp đầu tiên là nó cô lập chế độ thất bại rẻ nhất, phổ biến nhất (một dấu phẩy lạc, một dấu ngoặc nhọn bị thiếu) khỏi các lỗi schema đắt hơn mà nếu không sẽ làm chìm chúng.

Quyền riêng tư: Tại sao chỉ-Trình duyệt Quan trọng ở đây

Xác thực JSON trên một máy chủ yêu cầu tải lên tài liệu. Đối với các ví dụ dữ liệu công cộng thông thường, điều này là vô hại. Đối với các phản hồi API chứa token xác thực, PII khách hàng, hồ sơ nhân viên nội bộ, bí mật cấu hình, hoặc dữ liệu sản phẩm chưa phát hành, thì không. Ngay cả với chính sách xóa cẩn thận nhất, việc tải lên nằm trong nhật ký máy chủ, có thể trong cache CDN, có thể trong một pipeline phân tích, có thể trong một bản sao lưu. Công cụ này chạy JSON.parse trong trình duyệt của bạn qua JavaScript. Tài liệu được dán không bao giờ băng qua mạng, xác minh trong tab Network của DevTools khi bạn nhấp một nút, hoặc đưa trang offline (chế độ máy bay) sau khi tải xong và xác nhận trình xác thực vẫn hoạt động. An toàn để xác thực các payload webhook với bí mật, các phản hồi API với header xác thực, các tệp cấu hình với thông tin xác thực cơ sở dữ liệu, hoặc bất kỳ JSON nào khác mà bạn không muốn được sao chép vào ổ cứng của người lạ.

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

JSON hợp lệ là gì?

JSON hợp lệ phải là một trong các kiểu sau: đối tượng ({}), mảng ([]), chuỗi (""), số, boolean (true/false) hoặc null. Tất cả chuỗi và khóa đối tượng phải sử dụng dấu nháy kép. Số không thể có số 0 ở đầu. Khoảng trắng được phép giữa các phần tử.

« Sửa các vấn đề phổ biến » làm gì?

Việc sửa cố gắng tự động sửa các lỗi phổ biến: dấu phẩy cuối, dấu nháy đơn được chuyển thành dấu nháy kép, khóa không có dấu nháy và giá trị undefined được chuyển thành null. Đây là công cụ heuristic có thể không sửa được mọi thứ, hãy xem lại kết quả cẩn thận.

Làm thế nào để xác thực JSON trong ứng dụng của tôi?

Trong JavaScript: dùng JSON.parse() và bắt lỗi. Trong Node.js: fs.readFileSync() + JSON.parse(). Trong Python: json.loads() hoặc json.load(). Hầu hết các ngôn ngữ đều có thư viện JSON tích hợp.

Tôi có thể xác thực JSON5 hoặc JSONC (JSON với bình luận) không?

Không trực tiếp. Công cụ này sử dụng JSON.parse nghiêm ngặt của trình duyệt, tuân theo RFC 8259, bình luận, trailing comma, nháy đơn và khóa không trích dẫn là lỗi cú pháp. Nếu đầu vào của bạn là JSON5 (json5.org, Aseem Kishore 2012, được Jordan Tucker duy trì) hoặc JSONC của VS Code, hãy cài đặt gói npm json5 hoặc gói jsonc-parser, chuyển đổi sang JSON nghiêm ngặt, sau đó xác thực. Pass "Sửa các vấn đề phổ biến" xử lý một tập con của các khác biệt nhưng không phải là parser JSON5 / JSONC đầy đủ.

Có giới hạn kích thước không?

Không có giới hạn cứng, nhưng JSON.parse của trình duyệt tải toàn bộ tài liệu vào bộ nhớ dưới dạng một cây đối tượng duy nhất. Hàng chục ngàn dòng hoạt động thoải mái; các dump log đa-gigabyte sẽ làm cạn bộ nhớ. Đối với JSON rất lớn, hãy chạy một parser streaming như clarinet (Marak Squires) hoặc Oboe.js (Jim Higson, 2013), hoặc sử dụng jq --stream tại dòng lệnh, có thể xử lý các tài liệu kích thước tùy ý mà không bao giờ tải toàn bộ.

Các tài liệu JSON của tôi có được tải lên không?

Không. JSON.parse chạy trong trình duyệt của bạn qua JavaScript. Tài liệu được dán không bao giờ băng qua mạng, xác minh trong tab Network của DevTools khi bạn nhấp Validate, hoặc đưa trang offline sau khi tải xong và xác nhận công cụ vẫn hoạt động. An toàn để xác thực các payload webhook với bí mật, các phản hồi API với header xác thực, hoặc các tệp cấu hình với thông tin xác thực cơ sở dữ liệu.