| commit | 865df622e74332e6690eea689f0f1508011beeec | [log] [tgz] |
|---|---|---|
| author | Adrian Taylor <adetaylor@chromium.org> | Mon Feb 10 04:09:38 2020 |
| committer | Adrian Taylor <adetaylor@chromium.org> | Mon Feb 10 04:09:38 2020 |
| tree | 9881e45e831aff1288416eb1c891e65b104023d4 | |
| parent | 8ec30234102e7f7518a5f9543c848d74050a8d7c [diff] | |
| parent | d7cedcce1557d810ecf69af53b677ba844662166 [diff] |
Merge remote-tracking branch 'adetaylor-jsonrc/always-substitute-invalid-characters' into all-prs-merged-2 Change-Id: Iebed0ad1c56debece8b2abe7b32681cfb4b43bb8
This is a lenient JSON parser forked from the serde_json crate that is that is designed to parse JSON written by humans (e.g., JSON config files). This means that it supports:
/* and // style comments.\v and \xDD literal escapes (for vertical tab and two-digit hexadecimal characters)I am still playing with the idea of making it more lenient, which could include taking more features from the JSON5 spec.
When I created this crate, my immediate goal was to create a fast parser for a config file for a work project. I wanted a file format that would be familiar to developers, but restrictive in what it accepted. I had encountered this problem several times in my career, which always faced the same set of tradeoffs:
When considering the relative downsides of each of these options, it was clear that what I really wanted was a more lenient JSON. The next question was how to get a lenient JSON parser (in Rust, in my case). I considered the following options:
This was my first choice, but the maintainer wanted to keep the scope of serde_json limited to strict JSON, so we respectfully agreed that forking was the way to go.
The json5 crate supports the superset of JSON specified at https://json5.org/. In principle, the feature set met my needs, but in practice, I discovered the implementation was not nearly as performant as serde_json, even for small files. (Also, it cannot parse streams: only strings.)
The serde-hjson crate provies a parser for a different superset of JSON named Hjson (“JSON for humans”). I am not a fan of Hjson because the language it accepts is not valid JavaScript, so it's not nearly intuitive as JSON.
Ultimately, I would like to see a more lenient form of JSON standardized that experiences the same level of ubiquity as JSON today. I would like this crate to be a reference implementation of that new, more lenient specification.
I suspect that being more conservative in adding new features to the spec has the best chance of getting widespread buy-in, which is why I am not immediately gravitating towards implementing all of JSON5. Instead, I am starting with my suggested improvements to JSON from way back in 2011.
Finally, my gut feeling is that a new version of JSON should still be valid JavaScript. For example, one other shortcoming of JSON today is a lack of support for multiline strings. JSON5 addresses this by allowing \ for continued lines, but at this point, I think backtick (`) would be a more intuitive solution because that would be consistent with ES6 (though string interpolation would not be supported).
Because serde_jsonrc is a fork of serde_json, it maintains the original licence, which means it is licensed under either of
at your option.
Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in serde_jsonrc by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.