Một mảng có thể là văn bản JSON cấp cao nhất không?


Câu trả lời:


126

Có, một mảng là hợp pháp dưới dạng văn bản JSON cấp cao nhất.

Có ba tài liệu tiêu chuẩn xác định JSON: RFC 4627 , RFC 7159 (loại bỏ RFC 4627) và ECMA-404 . Chúng khác nhau ở chỗ cho phép các phần tử cấp cao nhất, nhưng tất cả đều cho phép một đối tượng hoặc một mảng là phần tử cấp cao nhất.

  • RFC 4627: Đối tượng hoặc mảng.
    "Văn bản JSON là một đối tượng hoặc mảng được tuần tự hóa."
  • RFC 7159: Bất kỳ giá trị JSON nào.
    "Văn bản JSON là một giá trị được tuần tự hóa."
  • ECMA-404: Bất kỳ giá trị JSON nào.
    "Văn bản JSON là một chuỗi các mã thông báo được hình thành từ các điểm mã Unicode tuân theo ngữ pháp giá trị JSON."

2
Kể từ RFC mới hơn này , "Văn bản JSON là một chuỗi mã thông báo. Bộ mã thông báo bao gồm sáu ký tự cấu trúc, chuỗi, số và ba tên chữ".
antak

63

, nhưng bạn nên xem xét việc đặt gốc trở thành một đối tượng thay thế trong một số trường hợp do bị tấn công JSON . Đây là một lỗ hổng tiết lộ thông tin dựa trên việc ghi đè hàm tạo mảng trong JavaScript.


11
Vâng, đó là dấu hiệu của một câu trả lời tuyệt vời - không chỉ nói với OP những gì họ muốn biết, mà còn những gì họ nên biết (nhưng không nhận ra). Trên thực tế, có một loạt các lỗ hổng liên quan đến JSON phân tích cú pháp thành Javascript, việc chiếm quyền điều khiển JSON chỉ là một ví dụ.
sleske


4

Đây là từ đặc tả ECMAScript.

JSONText:
    JSONValue

JSONValue:
    JSONNullLiteral 
    JSONBooleanLiteral 
    JSONObject 
    JSONArray 
    JSONString 
    JSONNumber

1
Tuy nhiên, điều này hơi gây hiểu lầm vì ECMAScript cho phép bạn phân tích cú pháp các chuỗi JSON không phải là văn bản cấp cao nhất. Theo RFC, "Văn bản JSON là một đối tượng hoặc mảng được tuần tự hóa."
Matthew Flaschen

@Matthew - Kỳ lạ, tôi tự hỏi Crockford cảm thấy thế nào về điều đó. Họ sẽ làm thế nào để dung hòa sự khác biệt giữa RFC và ECMA?
ChaosPandion

3
Tôi chỉ nhìn và thấy họ nhận ra sự khác biệt. Từ ECMAScript 5 §15.12, "Việc sản xuất JSONText cấp cao nhất của ngữ pháp ECMAScript JSON có thể bao gồm bất kỳ JSONValue nào thay vì bị hạn chế là JSONObject hoặc JSONArray như được chỉ định bởi RFC 4627." Tôi không biết liệu IETF có thay đổi RFC hay không.
Matthew Flaschen

@Matthew - Cảm ơn vì điều đó, tôi đã bối rối kinh khủng. Mô tả json.org không đề cập đến khái niệm hạn chế hơn của "json-text" ở tất cả , và loại mơ hồ về ý nghĩa của nó của RFC.
mrec

Câu trả lời này là về ECMAScript, nhưng câu hỏi là về JSON. Mặc dù chúng (cố tình) trông giống nhau, chúng có thông số kỹ thuật khác nhau .
sleske

2

vâng, hãy thử nó ở đây.

http://www.jsonlint.com/

và đưa vào [{}]


3
Nó thậm chí còn dễ dàng hơn thế. Đặt vào []và nó sẽ xác thực.
sorpigal

Liên kết đã chết, vui lòng cập nhật hoặc xóa, câu trả lời này — gần như chỉ có liên kết — câu trả lời.
Anthon

1

Có một số nhầm lẫn, được thấy trong các bình luận khác. Loại phương tiện "ứng dụng / json" chỉ cho phép đối tượng hoặc mảng ở cấp cao nhất đối với văn bản JSON , trên mỗi JSON RFC . Tuy nhiên, đối với trình phân tích cú pháp, bất kỳ giá trị JSON nào đều có thể chấp nhận được, như đã thấy trong đặc tả ECMAScript.


Mọi giá trị JSON làm phần tử cấp cao nhất đều có thể chấp nhận được đối với trình phân tích cú pháp ECMAScript , nhưng không được chấp nhận đối với trình phân tích cú pháp JSON (tuân thủ) - sự khác biệt quan trọng.
sleske

Đó là một sự khác biệt thú vị, nhưng tôi không hiểu bạn đang nói gì. Định nghĩa của trình phân tích cú pháp JSON "(tuân thủ)" là gì?
cdunn2001

1
Chà, trình phân tích cú pháp JSON là trình phân tích cú pháp cho ngữ pháp JSON. Mặc dù JSON trông giống với Javascript nhưng nó là một ngữ pháp khác (đơn giản hơn nhiều). Xem tools.ietf.org/html/rfc7159 , mô tả ngữ pháp JSON. "tuân thủ" chỉ có nghĩa là trình phân tích cú pháp thực sự tuân theo ngữ pháp (mà bất kỳ trình phân tích cú pháp tốt nào cũng nên làm).
sleske

3
RFC 4627 đã lỗi thời, vui lòng không theo dõi nó nữa. RFC mới cũng cho phép các giá trị đơn giản ở cấp cao nhất.
Matthias Dieter Wallnöfer
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.