[FIG(quote)[
[FIGCAPTION[
[1] [CITE@en[Canonical JSON - OLPC]]
([TIME[2015-02-27 15:01:35 +09:00]])
<http://wiki.laptop.org/go/Canonical_JSON>
]FIGCAPTION]

> 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.

]FIG]



[3] 同名のもの含め、似たようなものは他にもあります。
[SEE[ [[JSONもどき]] ]]


[2] [CITE@en[Talk:Canonical JSON - OLPC]], [TIME[2022-11-08T20:30:29.000Z]], [TIME[2023-03-14T04:50:16.269Z]] <https://wiki.laptop.org/go/Talk:Canonical_JSON>


[4] >>1

>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]] がどの[[文字符号化]]とも限定してないからで、
[[バイト列]]構文は[[文字符号化]]を確定しないと[[相互運用性]]が保証できないのでは...



[6] >>1

>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]] は[[文字列]]あるけど[[バイト列]]ないので。


[8] >>1

>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]] の一部に埋め込みたいみたいな話?



[10] [[LBRY]] が採用しています。