Open john-shaffer opened 2 years ago
This issue description sounded concerning, so I dug in a bit and I don't actually think the situation is too bad.
Integer/float handling can be fixed by enabling the arbitrary_precision
and float_roundtrip
features in the serde_json
crate. Thanks to feature unification, users can enable this themselves by specifying serde_json
as a dependency, like so–
serde_json = { version = "1", features = ["arbitrary_precision", "float_roundtrip"] }
The Unicode handling test failures would need to be fixed in serde_json
, which takes the somewhat opinionated stance that codepoints which decode to semantically ambiguous/undefined Unicode should be rejected. See serde-rs/json#495 & related issues.
Integer/float handling can be fixed by enabling the arbitrary_precision and float_roundtrip features in the serde_json crate.
I'd vote to enable it by default then 👌
According to the readme,
However, the implementation does not follow the spec. Numbers are serialized very differently. For instance, canonicaljson-rs serializes
1E-2
where the spec requires1.0E-2
. Unicode handling is inverted. canonicaljson-rs escapes most unicode characters, but the spec requires "avoiding escape sequences for characters except those otherwise inexpressible in JSON".The list of failures on the canonicaljson-spec test suite: