Công cụ dành cho nhà phát triển · JSON trình định dạng và xác thực
Tại sao dấu phẩy ở cuối lại ngắt JSON và nơi trình xác thực chỉ ra
· Cách thức hoạt động
json developer-workflow xác nhận
Dấu phẩy ở cuối là lỗi JSON phổ biến nhất và lỗi không bao giờ xảy ra ở chính dấu phẩy. Tìm hiểu những gì ngữ pháp yêu cầu sau dấu phẩy và cách đọc vị trí được báo cáo.
Lỗi một ký tự phải mất mười phút để tìm ra
Lỗi một ký tự mất mười phút để tìm thấy — một cấu hình được chỉnh sửa thủ công, dấu phẩy được để lại sau thuộc tính cuối cùng và một bản dựng không thành công. Trình phân tích cú pháp nghiêm ngặt tuân theo chuỗi mã thông báo thực sự có trong tài liệu. Hãy xem xét một đối tượng kết thúc bằng `'enabled': true,` và một mảng kết thúc bằng `'blue',`: cả hai dấu phân cách đều hứa hẹn một mục khác mặc dù mã thông báo tiếp theo sẽ đóng vùng chứa.
ToolAcre không lấy được vị trí từ thông báo của công cụ trình duyệt. JSON.parse trước tiên quyết định tính hợp lệ; chỉ sau khi thất bại, trình quét kho lưu trữ mới duyệt văn bản và báo cáo ký tự đầu tiên không được chấp nhận. Đối với dấu phẩy ở cuối, ký tự đó là dấu ngoặc nhọn hoặc dấu ngoặc đóng và lý do rõ ràng là "Dấu phẩy cuối". Trong một đối tượng, thiếu tên thành viên được trích dẫn khác; trong một mảng, một giá trị hoàn chỉnh khác bị thiếu.
Ngữ pháp JSON nói gì sau dấu phẩy
Ngữ pháp JSON nói gì sau dấu phẩy — RFC 8259 sử dụng dấu phẩy để phân tách các giá trị trong mảng và các thành phần trong đối tượng. Do đó, dấu phân cách cần một mục hợp lệ ở mỗi bên. Sau dấu phẩy đối tượng, trình phân tích cú pháp cần có tên được trích dẫn kép, dấu hai chấm và một giá trị. Sau dấu phẩy mảng, nó sẽ có bất kỳ giá trị JSON hợp lệ nào. Dấu phân cách đóng không đáp ứng được cả quá trình sản xuất.
Dấu phân cách thuộc về hai thành viên hoặc phần tử, không bao giờ nằm sau phần tử cuối cùng. Việc xóa dấu phẩy cuối cùng không thay đổi giá trị hoặc thứ tự; nó khôi phục ngữ pháp đóng vùng chứa ngay sau giá trị cuối cùng của nó. Đây cũng là lý do tại sao dấu phẩy có thể xuất hiện sau mỗi mục trước đó mà không gặp rắc rối: mỗi dấu phẩy đó được theo sau bởi mục tiếp theo mà nó hứa hẹn.
Tại sao lỗi lại nằm ở dấu ngoặc đóng
Tại sao lỗi xảy ra ở dấu ngoặc đóng - dấu phẩy là hợp lệ ở giữa vùng chứa, vì vậy trình phân tích cú pháp không thể từ chối nó chỉ khi nhìn thấy. Nó sử dụng dấu phân cách và thay đổi trạng thái để mong đợi một tên hoặc giá trị khác. Sự mâu thuẫn chỉ trở nên chắc chắn khi `}` hoặc `]` xuất hiện thay thế. Dấu phân cách đó là nơi mục đã hứa không xuất hiện, mặc dù dấu phẩy trước đó đã gây ra sự chuyển đổi trạng thái.
Do đó, dấu phân cách được báo cáo là bằng chứng về trạng thái của trình phân tích cú pháp, không phải là gợi ý xóa dấu ngoặc nhọn hoặc dấu ngoặc. Đọc một mã thông báo ở bên trái. Nếu mã thông báo đó là dấu phẩy và dấu phân cách đóng cùng một vùng chứa, hãy xóa dấu phẩy và giữ nguyên dấu đóng. Máy quét của ToolAcre đặt tên cho điều kiện có dấu phẩy ở cuối và cung cấp vị trí nguồn sau khi JSON.parse từ chối tài liệu.
JavaScript, Python và các linters hiện đại cho phép điều đó, JSON thì không
JavaScript, Python và các linters hiện đại cho phép điều đó, JSON thì không — nghĩa đen trong ngôn ngữ nguồn thường cho phép dấu phẩy sau mục cuối cùng vì nó làm cho các dòng được sắp xếp lại và các phần bổ sung trong tương lai dễ dàng xem lại hơn. Trình định dạng thậm chí có thể chèn hoặc giữ nguyên kiểu đó. Những tiện ích đó thuộc về ngữ pháp của từng ngôn ngữ. Từ điển Python hoặc từ điển đối tượng `.js` có thể là nguồn hợp lệ trong khi dấu câu hiển thị tương tự vẫn không hợp lệ trong tài liệu RFC 8259 JSON.
Do đó, trình chỉnh sửa được định cấu hình cho JavaScript có thể không hiển thị cảnh báo khi đoạn được dán kết thúc bằng dấu phẩy. Trình phân tích cú pháp đích vẫn kiểm soát việc chấp nhận. Sử dụng chế độ ngôn ngữ JSON cho văn bản `.json` và xác thực tải trọng chính xác được gửi tới trường API hoặc trường cấu hình. Sự khoan dung trong tệp nguồn, kẻ nói dối hoặc trình phân tích cú pháp JSON5 không phải là bằng chứng có thể chuyển nhượng về người tiêu dùng JSON nghiêm ngặt.
Ví dụ hoạt động: ba dấu phẩy ở cuối trong một tệp
Ví dụ đã hoạt động: ba dấu phẩy ở cuối trong một tệp — giả sử `features` kết thúc bằng `"beta",`, đối tượng chứa nó kết thúc bằng `"enabled": true,` và thành viên gốc thứ hai cũng mắc lỗi tương tự. Quá trình xác thực đầu tiên dừng ở dấu ngoặc đóng sau `beta`. Việc xóa dấu phẩy đó cho phép tiếp tục phân tích cú pháp cho đến dấu ngoặc đóng sau `true` và việc sửa vị trí thứ hai sẽ hiển thị lỗi đối tượng cấp gốc còn lại.
Trình tự này được mong đợi vì các trình phân tích cú pháp thường báo cáo điểm đầu tiên không thể tiếp tục, chứ không phải mọi lỗi sau này. Ánh xạ từng dòng và cột tới dấu phân cách đóng của nó, kiểm tra dấu phân cách ngay trước nó, thực hiện một thay đổi có chủ ý và chạy lại xác thực. Không xóa hàng loạt tất cả dấu phẩy: cần có dấu phân cách giữa các hàng xóm thực tế. Việc xác thực nhiều lần sẽ phân biệt ba dấu phẩy cuối không hợp lệ với các dấu phẩy hợp lệ trong cùng một tài liệu.
Các biến thể tạo ra lỗi giống nhau
Các biến thể tạo ra lỗi phân tách liên quan — dấu phẩy ở đầu, hai dấu phẩy liên tiếp và dấu phẩy sau giá trị gốc đều sử dụng sai ký tự giống nhau nhưng vi phạm các trạng thái phân tích cú pháp khác nhau. Dấu phẩy ở đầu không có mục nào được hoàn thành ở bên trái. Dấu phẩy liên tiếp không cung cấp mục nào giữa các dấu phân cách. Dấu phẩy sau giá trị gốc hoàn chỉnh xuất hiện sau khi văn bản JSON đã đạt đến phần cuối hợp lệ.
Những trường hợp đó không nên tự động được gắn nhãn dấu phẩy ở cuối. Lý do chính xác phụ thuộc vào vị trí và trạng thái vùng chứa. Bên trong `{"a":1,,"b":2}`, dấu phẩy thứ hai nằm ngoài dự đoán nơi tên thành viên được trích dẫn sẽ bắt đầu. Trong `[ ,1]`, dấu phẩy đầu tiên xuất hiện khi bắt buộc phải có giá trị. Kiểm tra mã thông báo chẩn đoán và mã thông báo xung quanh thay vì áp dụng quy tắc chung “xóa dấu phẩy trước” bên ngoài mẫu dấu phân cách đóng.
Điều này không bao gồm những gì
Điều này không bao gồm những gì — JSON5 và một số quy trình công việc JSON có nhận xét cố tình cho phép dấu phẩy ở cuối. Một tệp được viết cho một trong những ngữ pháp đó phải sử dụng trình phân tích cú pháp, phần mở rộng và công cụ được khai báo của nó. Việc coi nó là JSON nghiêm ngặt sẽ tạo ra lỗi phản ánh định dạng không khớp, không nhất thiết là lỗi tác giả. Ngược lại, việc chấp nhận nó bằng một trình phân tích cú pháp cho phép sẽ không làm cho nguồn được an toàn khi gửi đến điểm cuối JSON nghiêm ngặt.
Việc thay đổi trình phân tích cú pháp chỉ để tắt chẩn đoán này sẽ thay đổi ngôn ngữ được chấp nhận và có thể che giấu sự không tương thích với người dùng cuối cùng. Nhận xét, tên không có dấu ngoặc kép và chuỗi có dấu ngoặc đơn có thể đi kèm dấu phẩy ở cuối định dạng, tạo thêm lỗi khi văn bản vượt quá ranh giới. Xác nhận hợp đồng đích đầu tiên. Nếu nó nói JSON, hãy xóa cú pháp tiện ích mở rộng; nếu nó ghi JSON5 hoặc JSONC, hãy xác thực bằng công cụ triển khai định dạng chính xác đó.
Takeaway: nhìn một mã thông báo ở bên trái vị trí được báo cáo
Rút ra: nhìn một mã thông báo ở bên trái của vị trí được báo cáo — khi dấu mũ nằm bên dưới `}` hoặc `]`, dấu phẩy trước đó có thể đã hứa hẹn một thành viên hoặc thành phần chưa bao giờ xuất hiện. Giữ nguyên dấu phân cách đóng cần thiết về mặt cấu trúc và chỉ xóa dấu phân cách đầu cuối đó. Sau đó, xác thực lại toàn bộ tài liệu vì vị trí được sửa chữa đầu tiên có thể phát hiện ra một dấu phẩy ở cuối trong vùng chứa sau này.
ToolAcre giữ trách nhiệm trong phạm vi hẹp: JSON.parse quyết định rằng tài liệu không hợp lệ và máy quét cục bộ cung cấp lý do cấu trúc ổn định cùng với dòng và cột sau lỗi. Sử dụng tọa độ đó để kiểm tra ngữ cảnh của trình phân tích cú pháp thay vì đổ lỗi cho ký tự được đánh dấu một cách cô lập. Dấu phẩy ở cuối là bản chỉnh sửa một ký tự, nhưng việc hiểu lý do lỗi xuất hiện trên dấu phân cách sau sẽ giúp chẩn đoán tương tự trở nên đáng tin cậy trên các đối tượng, mảng và cấu hình lồng nhau sâu.