Nó có được chỉ định ở bất cứ đâu mà số nguyên JSON có thể lớn như thế nào không? Tôi đoán rằng chúng bị giới hạn ở các int thông thường (32 bit), nhưng tôi không thể tìm thấy bất kỳ nơi nào được viết ra. Tôi cần mã hóa các số nhận dạng dài trong Java, vì vậy tôi cho rằng tôi cần lưu trữ chúng dưới dạng chuỗi trong JSON để không có nguy cơ bị tràn.
Số nguyên JSON: giới hạn về kích thước
Câu trả lời:
Số JSON không bị giới hạn bởi thông số kỹ thuật .
Vì JSON là một định dạng trừu tượng không dành riêng cho JavaScript, nên môi trường đích thực tế sẽ xác định ranh giới của những gì có thể được diễn giải.
Cũng cần lưu ý rằng không có "Số nguyên JSON", chúng là một tập con của kiểu dữ liệu "Số".
12
Như một vấn đề thực tế, số nguyên Javascript được giới hạn trong khoảng 2 ^ 53 (không có số nguyên nào; chỉ IEEE trôi nổi). Nhưng thông số JSON khá rõ ràng rằng số JSON có kích thước không giới hạn.
—
Nelson
Mặc dù câu trả lời vẫn đúng về mặt kỹ thuật, nhưng nó đáng được cập nhật, vì RFC 7159 giúp làm rõ về phạm vi số nguyên nào nên được coi là có thể tương tác. (ví dụ
—
Tom Christie
[-(2**53)+1, (2**53)-1].) Nếu bạn đang làm việc bên ngoài phạm vi đó thì hãy sử dụng số nguyên được mã hóa chuỗi hoặc mong đợi việc triển khai mất độ chính xác.
@TomChristie Thông số JSON không đề cập đến RFC7159.
—
Tomalak
@Tomalak - Chắc chắn - RFC7159 xuất hiện sau đó (2014). Làm rõ một số trường hợp mâu thuẫn / cạnh tồn tại trước đó vv (Chẳng hạn như thiếu của bất kỳ đề cập về dãy số hoàn toàn khả thi)
—
Tom Christie
Hm, khi đọc chi tiết RFC, nó vẫn không giới hạn số lượng. Nó chỉ gợi ý rằng nhiều hệ thống sử dụng IEEE754 nội bộ và thực tế này có thể đặt ra những hạn chế thực tế về những gì người nhận có thể hiểu được, đó là những gì câu trả lời đã nói.
—
Tomalak
RFC 7159: Định dạng trao đổi dữ liệu ký hiệu đối tượng JavaScript (JSON)
Đặc điểm kỹ thuật này cho phép việc triển khai đặt giới hạn về phạm vi và độ chính xác của các con số được chấp nhận. Vì phần mềm triển khai các số IEEE 754-2008 binary64 (độ chính xác kép) [IEEE754] thường có sẵn và được sử dụng rộng rãi, nên khả năng tương tác tốt có thể đạt được bằng các triển khai mong đợi không có độ chính xác hoặc phạm vi cao hơn những gì cung cấp, theo nghĩa là các triển khai sẽ gần đúng với JSON số trong độ chính xác dự kiến. Số JSON chẳng hạn như 1E400 hoặc 3,141592653589793238462643383279 có thể chỉ ra các vấn đề tiềm ẩn về khả năng tương tác, vì nó gợi ý rằng phần mềm đã tạo ra nó mong đợi phần mềm nhận có khả năng về độ lớn và độ chính xác số cao hơn mức phổ biến rộng rãi.
'phổ biến rộng rãi' là một số ngôn ngữ mơ hồ, IMO. Trong khi đó, một số triển khai (như
—
Tomasz Gandor
jsonmô-đun tiêu chuẩn của Python ) phân tích cú pháp các số nguyên tùy ý, thậm chí vượt quá 64 bit (bignums tích hợp sẵn).
Tôi vừa thực hiện bài kiểm tra thực nghiệm sau bằng Bảng điều khiển Chrome (v.23 trên Mac):
> var j = JSON.parse("[999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999]")
undefined
> j[0]
1e+228
Nếu JSON được chuyển qua HTTP thì số sẽ được chuyển đổi trong Chuỗi từ Java trong mọi trường hợp và khi đó vấn đề có thể chỉ là trong Javascript.
Từ Đặc tả ngôn ngữ ECMAScript 4.3.19 :
4.3.19 Giá trị số
giá trị nguyên thủy tương ứng với giá trị IEEE 754 định dạng nhị phân 64 bit chính xác kép
CHÚ THÍCH: Giá trị Số là một thành viên của kiểu Số và là đại diện trực tiếp của một số.
Đó là những gì được định nghĩa trong định dạng dấu chấm động chính xác kép của wikipedia .
Cảm ơn. Cấu trúc JSON cụ thể này đang được cung cấp bởi dịch vụ web back-end trong Java, vì vậy, theo câu trả lời của @ Tomalak, tôi đoán tôi cần kiểm tra xem thư viện JSON phía máy chủ của mình đang thực sự làm gì.
—
Ian Dickinson
Và, đối với bản ghi, Jackson thực hiện phân tích cú pháp các số nguyên dài trong đầu vào JSON một cách chính xác thành các số dài Java.
—
Ian Dickinson
Và cũng có thể cho các hồ sơ, Jackson phát ra chờ đợi Java một cách chính xác, nhưng ít nhất các trình duyệt Chrome dựa trên thiết lập 3 thập phân cuối cùng để zero, tức là chiều dài của số này là chính xác, nhưng 3 số thập phân cuối cùng luôn luôn đọc 000
—
Johannes Jander