Công cụ dành cho nhà phát triển · JSON trình định dạng và xác thực
Lịch sử tiêu chuẩn của JSON: RFC 4627 tới RFC 8259 và ECMA-404
· Lý lịch
json tiêu chuẩn xác nhận
JSON đã được hai cơ quan tiêu chuẩn chỉ định ít nhất bốn lần. Bài đăng này theo dõi đường dẫn từ json.org của Douglas Crockford đến RFC 8259 và ECMA-404, đồng thời giải thích những gì thực sự đã thay đổi đối với các nhà phát triển trong quá trình thực hiện.
Trình phân tích cú pháp của tôi tuân theo thông số kỹ thuật nào?
Trình phân tích cú pháp tuân theo thông số kỹ thuật nào? Câu trả lời thường được nhìn thấy ở các cạnh hơn là trong các đối tượng và mảng thông thường. Kiểm tra chuỗi cấp cao nhất, chẳng hạn như `"ready"`, dấu thứ tự byte ở đầu, tên thành viên trùng lặp và số lượng lớn bất thường. Các tài liệu khác nhau thảo luận về cú pháp và khả năng tương tác ở các cấp độ khác nhau, trong khi việc triển khai thêm các kiểu dữ liệu và hành vi lỗi của riêng chúng. Việc đặt tên cho một tiêu chuẩn chỉ hữu ích khi hợp đồng trình phân tích cú pháp được quan sát được tách biệt khỏi các giả định về mọi triển khai JSON.
Bằng chứng kho lưu trữ cho ToolAcre là cụ thể và hẹp hơn so với lịch sử tiêu chuẩn chung. Trình định dạng sử dụng `JSON.parse` để tạo ra các giá trị và `JSON.stringify` để phát ra chúng; sau khi phân tích cú pháp không thành công, máy quét cục bộ sẽ cung cấp vị trí và lý do chẩn đoán ổn định.
json.org và mô tả ban đầu về JSON
json.org trình bày JSON dưới dạng ký hiệu thu gọn bắt nguồn từ cú pháp đối tượng theo nghĩa đen của JavaScript và ghi lại cấu trúc cốt lõi của nó bằng một ngữ pháp nhỏ. Mô tả ban đầu đó đã giúp cung cấp cho các nhà phát triển một tên chung và tham chiếu cho các đối tượng, mảng, chuỗi, số, boolean và null. Sẽ an toàn hơn khi mô tả trang này như một lời giải thích công khai sớm hơn là tuyên bố, không có bằng chứng lịch sử được trích dẫn ở đây, rằng một trang hoặc một người đã tự tay phát hiện ra một định dạng hoặc thiết lập việc áp dụng nó.
Các nguồn kho lưu trữ hiện tại không bao gồm lịch sử lưu trữ của json.org, việc sử dụng trình duyệt hoặc các cuộc thảo luận của ủy ban. Chúng cho thấy cách ứng dụng này phân tích cú pháp và chẩn đoán JSON hôm nay. Theo đó, các tuyên bố lịch sử trong bài viết này bám sát các tài liệu tiêu chuẩn cũ và tránh quy kết các động cơ hoặc tác động thị trường mà các hồ sơ địa phương đó không thể chứng minh được.
RFC 4627 trong 2006 — mô tả IETF đầu tiên, loại phương tiện ứng dụng/json và quy tắc rằng văn bản phải là một đối tượng hoặc mảng
RFC 4627, xuất bản năm 2006, được mô tả JSON để trao đổi Internet và đăng ký `application/json` loại phương tiện truyền thông. Định nghĩa của nó về một JSON văn bản yêu cầu một đối tượng hoặc mảng ở cấp cao nhất, mặc dù các chuỗi, số và chữ tồn tại dưới dạng giá trị bên trong các vùng chứa đó. Hạn chế đó là một sự khác biệt lịch sử hữu ích vì một tài liệu chỉ chứa `"ready"` có thể là một giá trị hợp lệ trong công thức sau này khi nằm ngoài RFC 4627'S JSON-định nghĩa văn bản
Tài liệu cũng thảo luận về các mối lo ngại về mã hóa và bảo mật trong bối cảnh triển khai có sẵn tại thời điểm đó. Không nên đọc nó dưới dạng nhật ký thay đổi cho kho lưu trữ này: ToolAcre không chứa chế độ tương thích RFC 4627 và đường dẫn trình phân tích cú pháp của nó ủy quyền việc xây dựng giá trị cho công cụ JavaScript của máy chủ.
ECMA-404 trong 2013 — Tiêu chuẩn tối thiểu chỉ có cú pháp của Ecma và lý do tại sao hai tổ chức lại mô tả một định dạng
ECMA-404, được xuất bản lần đầu trong 2013, chỉ định cú pháp JSON ở dạng cô đọng có chủ ý. Trọng tâm của nó là ngữ pháp của văn bản JSON hợp lệ thay vì cấu hình trao đổi hoàn chỉnh cho mọi mục đích sử dụng trên mạng. Phạm vi đó giúp giải thích lý do tại sao ECMA-404 và các tài liệu IETF có thể mô tả cùng một ký hiệu cơ bản trong khi lại khác nhau về hướng dẫn về khả năng tương tác xung quanh mà chúng nhấn mạnh. Sự tồn tại của hai cơ quan tiêu chuẩn không hàm ý hai định dạng không tương thích trong sử dụng thông thường.
Tuyên bố về lý do tại sao các tổ chức chọn đường dẫn xuất bản cụ thể yêu cầu các nguồn tài liệu ngoài cơ sở mã này, vì vậy bài viết này không suy luận động cơ của ủy ban dựa trên ngày tháng của tiêu chuẩn. Điểm thực tế có liên quan là RFC 8259 và ECMA-404 nhằm mục đích căn chỉnh theo cú pháp, trong khi RFC 8259 cung cấp các đề xuất quan trọng đối với hoạt động trao đổi có thể tương tác.
RFC 7159 và RFC 8259
RFC 7159 đã thay thế RFC 4627 trong 2014 và mở rộng định nghĩa của văn bản JSON thành bất kỳ giá trị được xê-ri hóa nào, loại bỏ quy tắc cấp cao nhất chỉ đối tượng hoặc mảng. RFC 8259 đã thay thế RFC 7159 trong 2017 và vẫn là tài liệu tham khảo IETF thường được trích dẫn cho JSON. Nó yêu cầu UTF-8 cho JSON được trao đổi giữa các hệ thống bên ngoài hệ sinh thái khép kín và ghi lại các cảnh báo về khả năng tương tác xung quanh các số, tên trùng lặp, Unicode và dấu thứ tự byte thay vì chỉ giả vờ ngữ pháp để đảm bảo kết quả giống hệt nhau ở mọi nơi.
`true` cấp cao nhất là một cách nhỏ gọn để tuân thủ quy tắc giá trị gốc hiện đại trong ToolAcre vì `JSON.parse` chấp nhận nó. Kết quả đó thể hiện hành vi triển khai này; nó không tái tạo lại khi mọi trình duyệt, máy chủ hoặc API đều áp dụng định nghĩa rộng hơn.
Điều gì đã thay đổi đối với các nhà phát triển đang làm việc
Đối với các nhà phát triển đang hoạt động, những thay đổi về thông số kỹ thuật rõ ràng nhất là sự chấp nhận hiện đại đối với mọi giá trị JSON ở gốc và hướng dẫn mạnh mẽ hơn về mã hóa có thể tương tác. Bài học ít thấy hơn là cú pháp hợp lệ vẫn để lại các lựa chọn triển khai. Tên đối tượng trùng lặp có thể bị thu gọn, thứ tự thành viên không phải là hợp đồng ngữ nghĩa, số lượng rất lớn có thể mất độ chính xác và các chuỗi Unicode bất thường có thể di chuyển khác nhau qua các thư viện. Do đó, một tài liệu tuân thủ các tiêu chuẩn có thể xứng đáng có những ràng buộc bổ sung từ lược đồ ứng dụng.
Trong trình định dạng này, tên trùng lặp và mã thông báo số trước tiên sẽ chuyển qua `JSON.parse`, do đó, định dạng sau này phản ánh giá trị JavaScript thu được thay vì tài liệu từ vựng gốc. Máy quét góp phần chẩn đoán sau khi thất bại; nó không bảo toàn các thành viên trùng lặp hoặc các số có độ chính xác tùy ý. Đó là những quan sát được hỗ trợ bởi kho lưu trữ.
Điều này không bao gồm những gì
Nội dung này không bao gồm các thông số kỹ thuật được xếp chồng lên trên JSON. JSON Lược đồ mô tả các ràng buộc về hình dạng và giá trị của tài liệu; JSON Con trỏ đánh địa chỉ các vị trí trong tài liệu; JSON Bản vá thể hiện những thay đổi. Chúng giải quyết các vấn đề khác nhau từ ngữ pháp cơ bản và không được coi là phiên bản sau này của chính JSON. JSONC, JSON5 và các định dạng tác giả tương tự cũng mở rộng hoặc thay đổi cú pháp được chấp nhận và yêu cầu trình phân tích cú pháp riêng thay vì được xếp vào xác thực nghiêm ngặt một cách âm thầm.
Bài viết này cũng tránh lịch sử xã hội toàn diện về việc áp dụng JSON, hỗ trợ trình duyệt hoặc cạnh tranh với XML vì các nguồn kho lưu trữ được liệt kê không thể chứng minh tường thuật đó. Không có trích dẫn bên ngoài nào được phát minh để lấp đầy khoảng trống.
Bài học rút ra: RFC 8259 là tài liệu tham khảo để trích dẫn
RFC 8259 là tài liệu tham khảo IETF thực tế để trích dẫn cú pháp JSON hiện tại và hướng dẫn về khả năng tương tác, với ECMA-404 cung cấp tiêu chuẩn cú pháp Ecma được căn chỉnh. RFC 4627 và RFC 7159 vẫn hữu ích để hiểu định nghĩa đã xuất bản đã thay đổi như thế nào, đặc biệt là ở cấp cao nhất. Trích dẫn tài liệu hỗ trợ cho tuyên bố chính xác thay vì sử dụng “thông số JSON” như một lời kêu gọi mơ hồ đối với cơ quan có thẩm quyền và phân biệt các quy tắc quy phạm với hành vi triển khai được quan sát trong một trình phân tích cú pháp cụ thể.
Đối với ToolAcre, tuyên bố có thể bảo vệ là kho lưu trữ sử dụng trình phân tích cú pháp và trình tuần tự hóa JSON của JavaScript, đồng thời thêm một trình quét cục bộ nghiêm ngặt để chẩn đoán sau các lỗi. Kiểm tra các giá trị cấp cao nhất, dấu câu không đúng định dạng và xử lý số mô tả tuyến đường đó; chúng không phải là nguồn lịch sử.