Serialize numbers and literals
02Different number spellings can parse to the same binary64 value. JCS uses the specified ECMAScript serialization, with no whitespace between tokens.
A program-created Infinity is not valid JSON. JCS fails rather than silently converting it to null.
Source for this drawing: RFC 8785 · Read RFC section 3.2.2.3 ↗
New to this? Start hereA quick picture + helpful background
First, agree how to read the message.
An encoding tells a reader how to interpret bytes. A format tells it how values fit together. Correctly reading a value does not make that value trustworthy.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Canonicalize the parsed value, not its original spelling.
- Numbers MUST use the ECMAScript number serialization specified in §3.2.2.3, including its Note 2 rule. Input decimals may round when parsed to binary64.
- The literals null, true and false MUST serialize as null, true and false. Whitespace between JSON tokens MUST NOT be emitted; spaces inside strings remain data.
- NaN and Infinity MUST cause an appropriate error. Higher precision or longer integers are RECOMMENDED as strings; Appendix D requires string wrapping for numbers outside the natural JSON ecosystem. Canonicalization does not recover precision already lost.
The figure uses small exact-value examples, not a decimal arithmetic algorithm. Appendix B supplies harder rounding/boundary vectors. Negative-zero parsing advice is in chapter one; do not confuse it with the underlying serializer’s 0 output.
Read the RFC section ↗