If my json is too complicated to be readable I just use jq to find the things I want out of it.
FracturedJson
111–120 of 173 posts
Re: FracturedJson
#112Earlier quoted context omitted.
A new spec version doesn’t mean we stop having the problem. E.g. kubernetes wrote about solving this only five months ago[1] and by moving from yaml to kyaml, a yaml subset. [1]: https://kubernetes.io/blog/2025/07/28/kubernetes-v1-34-sneak...
The 1.1 spec was released about _twenty_ years ago, I explicitly used the word _implemented_ for a reason. As in: Our Yaml lib vendor had begun officially supporting that version more than ten years ago.
Note that you reference 1.1, I think that version still had the norway behavior.
Re: FracturedJson
#113I have a JSON formatter called Virtuous (https://marketplace.visualstudio.com/items?itemName=karyfoun...) and till now I thought that is the best way to format JSON, and I most confess that I'll throw away my own formatter in favor of this one. What a great job.
Re: FracturedJson
#114I ported it to Rust with a cli tool that allows you to format json in this format:
https://github.com/fcoury/fracturedjson-rs
https://crates.io/crates/fracturedjson
And install with:
cargo install fracturedjson
> $ fjson --help
Rust port of FracturedJsonJs: human-friendly JSON formatter with optional comment support.
Usage: fjson [OPTIONS] [FILE]...
Arguments:
[FILE]... Input file(s). If not specified, reads from stdin
Options:
-o, --output
Output file. If not specified, writes to stdout
-c, --compact
Minify output (remove all whitespace)
-w, --max-width
Maximum line length before wrapping [default: 120]
-i, --indent
Number of spaces per indentation level [default: 4]
-t, --tabs
Use tabs instead of spaces for indentation
--eol
Line ending style [default: lf] [possible values: lf, crlf]
--comments
How to handle comments in input [default: error] [possible values: error, remove, preserve]
--trailing-commas
Allow trailing commas in input
--preserve-blanks
Preserve blank lines from input
--number-align
Number alignment style in arrays [default: decimal] [possible values: left, right, decimal, normalize]
--max-inline-complexity
Maximum nesting depth for inline formatting (-1 to disable) [default: 2]
--max-table-complexity
Maximum nesting depth for table formatting (-1 to disable) [default: 2]
--simple-bracket-padding
Add padding inside brackets for simple arrays/objects
--no-nested-bracket-padding
Disable padding inside brackets for nested arrays/objects
-h, --help
Print help
-V, --version
Print versionRe: FracturedJson
#115I really like this, I think I'd find it useful fairly often and I like the idea of just making something that I use irregularly but not that rarely a bit better. But then I found it's in C#. And apparently the CLI app isn't even published any more (apparently nobody wanted it? Surprises me but ok). Anyway, I don't think I want this enough to install .NET to get it, so that's that. But I'd have liked a version in Go o…
I'm the maintainer of FracturedJson. The decision to stop publishing a binary for the CLI version was made a long time ago: fewer features, fewer users, less mature .NET tooling (as far as I knew). And as you say, .NET isn't a common language for distributing CLI tools.
I plan to take a new look at that when I have the time. But a port to a more CLI-friendly platform could probably do a better job.
Re: FracturedJson
#116This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…
This is very interesting, though the limitations for 'security' reasons seem somewhat surprising to me compared to the claim "Anything JSON can do, it can do. Anything JSON can't do, it can't do.". Simplest example, "a\u0000b" is a perfectly valid and in-bounds JSON string that valid JSON data sets may have in it. Doesn't it end up falling short of 'Anything JSON can do, it can do" to refuse to serialize that string?
"a\u0000b" ("a" followed by a vertical tabulation control code) is also a perfectly valid and in-bounds BONJSON string. What BONJSON rejects is any invalid UTF-8 sequences, which shouldn't even be present in the data to begin with.
Re: FracturedJson
#117Earlier quoted context omitted.
With mutation testing you can guarantee that all the behavior in the code is tested.
You can guarantee that all the cases in the code are tested. That doesn't necessarily mean that all the behaviour is tested. If two implementations use very different approaches, which happen to have different behaviour on the Mersenne primes (for deep mathematical reasons), but one of them special-cases byte values using a lookup table generated from the other, you wouldn't expect mutation testing to catch the discr…
I think if you hit full path coverage in each of them independently and run all the cases through both and check they're consistent you're still done.
Or branch coverage for the lesser version, the idea is still to generate interesting cases based on each implementation, not based solely on one of them.
Re: FracturedJson
#118This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…
Can you tell me what was the context that lead you to create this? Unrelated JSON experience: I worked on a serializer which save/load json files as well as binary file (using a common interface). From my own use case I found JSON to be restrictive for no benefit (because I don't use it in a Javascript ecosystem) So I change the json format into something way more lax (optional comma, optional colon, optional quotes,…
Have you heard of EDN? It's mostly used in Clojure and ClojureScript, as it is to Clojure what JSON is to JS.
If you need custom data types, you can use tagged elements, but that requires you to have functions registered to convert the data type to/from representable values (often strings).
It natively supports quite a bit more than JSON does, without writing custom data readers/writers.
Re: FracturedJson
#119This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…
I think JSON is too limited and has some problems, so BONJSON has mostly the same problems. There are many other formats as well, some of which add additional types beyond JSON and some don't. Also, a few programs may expect (and possibly require) that files may contain invalid UTF-8, even though it is not proper JSON (I think it would be better that they should not use JSON, due to this and other issues), so there is that too. Using normalized Unicode has its own problems, as does allowing 64-bit integers when some programs expect it and others don't. JSON and Unicode are just not good formats, in general. (There is also a issue with JSON.stringify(-0) but that is an issue with JavaScript that does not seem to be relevant with BONJSON, as far as I can tell.)
Nevertheless, I believe your claims are mostly accurate, except for a few issues with which things are allowed or not allowed, due to JavaScript and other things (although in some of these cases, the BONJSON specification allows options to control this). Sometimes rejecting certain things is helpful, but not always; for example sometimes you do want to allow mismatched surrogates, and sometimes you might want to allow null characters. (The defaults are probably reasonable, but are often the result of a bad design anyways, as I had mentioned above.) Also, the top of the specification says it is safe against many attacks, but these are a feature of the implementation, which would also be the case if you are implement JSON or other formats (although the specification for BONJSON does specify that implementations are supposed to check for these things to make them safe).
(The issue of overlong UTF-8 encodings in IIS web servers is another security issue, which is using a different format for validation and for usage. In this case there are actually two usages though, because one of these usages is the handling of relative URLs (using the ASCII format) and the other is the handling of file names on the server (which might be using UTF-16 here; in addition to that is the internal format of the file paths into individual pieces with the internal handling of relative file paths). There are reasons to avoid and to check for overlong UTF-8 encodings, although this is a different more general issue than the character encoding.)
Another issue is canonical forms; the canonical form of JSON can be messy, especially for numbers (I don't know what the canonical form for numbers in JSON is, but I read that apparently it is complicated).
I think DER is better. BONJSON is more compact but that also makes the framing more complicated to handle than DER (which uses consistent framing for all types). I also wrote a program to convert JSON to DER (I also made up some nonstandard types, although the conversion from JSON to DER only uses one of these nonstandard types (key/value list); the other types it needs are standard ASN.1 types). Furthermore, DER is already canonical form (and I had made up SDER and SDSER for when you do not want canonical form but also do not want the messiness of BER; SDSER does have chunking and does not require the length to be known ahead of time, so more like BONJSON in these ways). Because of the consistent framing, you can easily ignore any types that you do not use; even though there are many types you do not necessarily need all of them.
Re: FracturedJson
#120This is great! The more human-readable, the better! I've also been working in the other direction, making JSON more machine-readable: https://github.com/kstenerud/bonjson/ It has EXACTLY the same capabilities and limitations as JSON, so it works as a drop-in replacement that's 35x faster for a machine to read and write. No extra types. No extra features. Anything JSON can do, it can do. Anything JSON can't do, it can…
What about compression rates?