A "canonical JSON" format is provided in order to provide meaningful and repeatable hashes of JSON-encoded data. Canonical JSON is parsable with any full JSON parser, but security-conscious applications will want to verify that input is in canonical form before authenticating any hash or signature on that input.
[3] 同名のもの含め、似たようなものは他にもあります。
[2] Talk:Canonical JSON - OLPC, , https://wiki.laptop.org/go/Talk:Canonical_JSON
Strings are uninterpreted bytes, with only two escaped byte values. Because only two byte values are escaped, be aware that JSON-encoded data may contain embedded control characters and nulls. It is suggested that unicode strings be represented as the UTF-8 encoding of unicode Normalization Form C (UAX #15). However, arbitrary content may be represented as a string: it is not guaranteed that string contents can be meaningfully parsed as UTF-8.
[5] UTF-8 にするといいがそうとは限らないと。たしかに JSON も UTF-8 とは決めていないが... それは JSON がどの文字符号化とも限定してないからで、 バイト列構文は文字符号化を確定しないと相互運用性が保証できないのでは...
A previous version of this specification required strings to be valid unicode, and relied on JSON's \u escape. This was abandoned as it doesn't allow representing arbitrary binary data in a string, and it doesn't preserve the identity of non-canonical unicode strings.
[7] これは文字列でないバイト列を扱うために敢えてその制限を外してるってこと? そうするとそもそもこれ JSON じゃないよね、って話に。 JSON は文字列あるけどバイト列ないので。
A previous version of this specification suggested Normalization Form D for unicode strings. This was changed to Normalization Form C to better comply with the recommendations of RFC 3987.
[9] なぜ RFC 3987 (IRI) に「より良く準拠する」のか謎だけど、 IRI の一部に埋め込みたいみたいな話?