Preserve strings, choose escapes
03A character can arrive through an escape or directly. Decode it, preserve the resulting Unicode data, then serialize with the required escapes.
The application may interpret "055" as a big integer later. Replacing the canonicalized string with "55" changes the data and is stopped here.
Source for this drawing: RFC 8785 · Read RFC section 3.2.2.2 ↗
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.
Changing a string’s meaning is not canonicalization.
- Control characters U+0000–U+001F MUST use lowercase \uhhhh, except backspace, tab, newline, form feed and carriage return, which MUST use \b, \t, \n, \f and \r. Quote and backslash MUST be escaped. Other valid characters are emitted as is, inside double quotes.
- Parsed string data MUST NOT be altered during later serialization. JCS does not perform Unicode normalization: precomposed é and e plus combining acute remain distinct strings.
- Appendix E requires stream/schema parsers to preserve subtypes as immutable JSON strings and convert to native types subsequently. A string such as "055" must not become "55" in the signed data.
The escape example includes é, newline, U+000F, a quote, a backslash and a slash. Slash does not need escaping in JCS. Verified editorial erratum 6292 corrects the referenced ECMAScript string algorithm to §24.5.2.2. Appendix E is additional reading: https://www.rfc-editor.org/rfc/rfc8785.html#appendix-E .
Read the RFC section ↗