Công cụ dành cho nhà phát triển · JSON trình định dạng và xác thực
Cách trình xác thực JSON tìm thấy dòng và cột chính xác của lỗi
· Cách thức hoạt động
json xác nhận developer-workflow
Các công cụ trình duyệt báo cáo lỗi JSON.parse theo cách khác nhau và một số chỉ cung cấp phần bù ký tự. Bài đăng này giải thích cách trình xác thực biến nó thành một dòng và cột cũng như lý do vị trí đánh dấu nơi quá trình phân tích cú pháp dừng lại thay vì nơi bạn mắc lỗi.
Thông báo lỗi không cho bạn biết gì — tại sao 'Mã thông báo không mong đợi ở JSON ở vị trí 1432' lại vô dụng trong tệp dòng 400
Một lỗi như “Mã thông báo không mong đợi” gây khó chịu trong một cấu hình dài vì nó không cung cấp vị trí mà bạn có thể mở trong trình chỉnh sửa của mình. JSON.parse là trình phân tích cú pháp có thẩm quyền của trình duyệt nhưng văn bản chẩn đoán của nó khác nhau giữa các công cụ và phiên bản JavaScript. ToolAcre không đoán vị trí bằng cách khớp chuỗi lỗi tiếng Anh không ổn định. Nếu JSON.parse không thành công, một trình quét nghiêm ngặt riêng biệt sẽ quét văn bản gốc để xác định ký tự đầu tiên mà ngữ pháp JSON không thể chấp nhận.
Trình phân tích cú pháp JSON thực sự làm gì khi nó đọc - hướng dẫn cách mã hóa và ngữ pháp gốc đệ quy tiêu thụ một giá trị tại một thời điểm
JSON có sáu ký tự cấu trúc—dấu ngoặc nhọn, dấu ngoặc, dấu hai chấm và dấu phẩy—và các giá trị có thể là chuỗi, số, mảng, đối tượng, đúng, sai hoặc rỗng. Máy quét cần biết liệu nó có nằm trong chuỗi trích dẫn hay không trước khi gọi dấu phẩy là dấu phân cách: {"note://A,B"} có một giá trị chứ không phải hai. Nó duyệt qua một giá trị hoặc một thành viên đối tượng và kiểm tra những gì có thể tuân theo một cách hợp pháp tiếp theo. RFC 8259 xác định ngữ pháp này và không giống như JavaScript đối tượng bằng chữ, nó không cho phép nhận xét hoặc dấu phẩy ở cuối.
Từ độ lệch ký tự đến dòng và cột — đếm dòng mới cho đến phần bù lỗi và tại sao CRLF phần cuối và ký tự nhiều byte lại làm phức tạp việc đếm
Máy quét thường bắt đầu bằng giá trị chênh lệch dựa trên 0 trong chuỗi JavaScript ban đầu. Để làm cho điều đó trở nên hữu ích, hãy đếm số lần ngắt dòng trước phần bù và tìm xem lỗi nằm cách điểm ngắt cuối cùng bao xa. CRLF phải được coi là một dòng trực quan kết thúc chứ không phải hai dòng; các vị trí trong chuỗi JavaScript đếm UTF-16 đơn vị mã chứ không phải UTF-8 byte trên đĩa. Biểu tượng cảm xúc không phải BMP có thể chiếm hai đơn vị mã trong trình chỉnh sửa hiển thị trực quan một ký tự. Giao diện người dùng báo cáo một dòng, cột và đoạn trích để bạn có thể kiểm tra dấu mũ đối với tệp bạn đã dán.
Nơi dừng phân tích cú pháp không phải là nơi xảy ra lỗi - dấu phẩy bị thiếu được báo cáo ở phím tiếp theo và dấu ngoặc kép đi lạc có thể đẩy lỗi xuống nhiều dòng
Mã thông báo không thể đầu tiên thường xuất hiện sau lỗi ban đầu. Trong một đối tượng, việc quên dấu phẩy sau true sẽ khiến trích dẫn bắt đầu thuộc tính tiếp theo trở thành bất hợp pháp: trình phân tích cú pháp đang mong đợi dấu phẩy hoặc dấu ngoặc nhọn đóng. Chuỗi không kết thúc có thể khiến lỗi xuất hiện ở ngắt dòng sau hoặc ở cuối đầu vào. Đọc ngược từ điểm báo cáo để tìm dấu phân cách bị thiếu; đừng cho rằng ký tự bên dưới dấu mũ phải bị xóa.
Ví dụ đã hoạt động: một cấu hình bị thiếu một dấu phẩy — vị trí được báo cáo, các mã thông báo xung quanh và cách quay ngược lại nguyên nhân thực sự
Hãy thử tài liệu ba dòng theo nghĩa đen {"name://demo", theo sau là "enabled":true trên dòng hai và "port":8080} trên dòng ba, không có dấu phẩy sau true. ToolAcre báo cáo dòng 3, cột 1, offset 31: nó cần có dấu phẩy hoặc } sau thuộc tính trước đó và nó hiển thị dấu mũ bên dưới trích dẫn đầu tiên của "port". Chèn dấu phẩy vào cuối dòng thứ hai, sau đó xác nhận lại. Đây là chẩn đoán về trở ngại cú pháp đầu tiên, không phải là phán đoán rằng từ “port” là sai.
Các công cụ trình duyệt khác nhau như thế nào - V8, SpiderMonkey và JavaScriptCore diễn đạt cùng một lỗi khác nhau, đó là lý do tại sao báo cáo dòng và cột nhất quán sẽ giúp ích
V8, SpiderMonkey và JavaScriptCore đã sử dụng cách diễn đạt khác nhau và đôi khi là các đoạn mã theo ngữ cảnh khác nhau cho cùng một lỗi JSON.parse. Trình quét của ToolAcre cung cấp lý do cấu trúc và vị trí của chính nó khi trình phân tích cú pháp gốc từ chối giá trị. Nếu máy quét không đồng ý với JSON.parse, công cụ sẽ trả về lỗi động cơ thay vì tạo ra một vị trí. Cách dự phòng đó an toàn hơn là tự tin chỉ vào một nhân vật được đoán.
Điều này không bao gồm những vấn đề về ngữ nghĩa như sai loại, thiếu trường hoặc vi phạm lược đồ mà trình xác thực cú pháp sẽ không bao giờ gắn cờ
Đối tượng hợp lệ về mặt cú pháp vẫn có thể sai đối với ứng dụng của bạn: thiếu trường bắt buộc, độ tuổi được viết dưới dạng văn bản, hai khóa trùng lặp hoặc tham chiếu đến tệp không tồn tại không tự động không hợp lệ JSON. RFC 8259 cho biết tên thành viên phải là duy nhất để có khả năng tương tác nhưng việc phân tích cú pháp đơn thuần không thực thi lược đồ API của bạn. Xác thực cú pháp ở đây và xác thực các ràng buộc ngữ nghĩa trong chương trình sử dụng tài liệu.
Bài học rút ra: đọc vị trí là 'mã thông báo đầu tiên mà ngữ pháp không thể chấp nhận' — và cách trình định dạng & trình xác thực JSON báo cáo dòng và cột đó mà không cần tải văn bản lên
Hãy coi vị trí được báo cáo là “mã thông báo đầu tiên mà ngữ pháp này không thể chấp nhận”. Hãy quay ngược lại nguyên nhân, khắc phục một sự cố và chạy lại. JSON trình định dạng & trình xác thực thực hiện việc này cục bộ mà không cần tải lên cấu hình đã dán. Không dán thông tin xác thực sản xuất thực vào bất kỳ trang web công cộng nào nếu thay vào đó, trình chỉnh sửa ngoại tuyến có thể chẩn đoán tệp.