Am 02.08.2015 um 19:14 schrieb Dmitry Olshansky:
Actually JSON is defined as subset of EMCASCript-262 spec hence it may not ciontain anything other 64-bit5 IEEE-754 numbers period. See: http://www.ecma-international.org/ecma-262/6.0/index.html#sec-terms-and-definitions-number-value http://www.ecma-international.org/ecma-262/6.0/index.html#sec-ecmascript-language-types-number-type Anything else is e-hm an "extension" (or simply put - violation of spec), I've certainly seen 64-bit integers in the wild - how often true big ints are found out there? If no one can present some run of the mill REST JSON API breaking the rules I'd suggest demoting BigInt handling to optional feature.
This is not true. Quoting from ECMA-404:
JSON is a text format that facilitates structured data interchange between all programming languages. JSON is syntax of braces, brackets, colons, and commas that is useful in many contexts, profiles, and applications. JSON was inspired by the object literals of JavaScript aka ECMAScript as defined in the ECMAScript Language Specification, third Edition [1]. It does not attempt to impose ECMAScript’s internal data representations on other programming languages. Instead, it shares a small subset of ECMAScript’s textual representations with all other programming languages. JSON is agnostic about numbers. In any programming language, there can be a variety of number types of various capacities and complements, fixed or floating, binary or decimal. That can make interchange between different programming languages difficult. JSON instead offers only the representation of numbers that humans use: a sequence of digits. All programming languages know how to make sense of digit sequences even if they disagree on internal representations. That is enough to allow interchange.
