[hiddew]

I think for "untyped" files with records, using the ASCII file, (group) and record separators (hex 1C, 1D and 1E) work nicely. The only constraint is that the content cannot contain these characters, but I found that that is generally no problem in practice. Also the file is less human readable with a simple text editor.

For other use cases I would use newline separated JSON. Is has most of the benefits as written in the article, except the uncompressed file size.

[akie]

I agree that JSONL is the spiritual successor of CSV with most of the benefits and almost none of the drawbacks.

It has a downside though: wherever JSON itself is used, it tends to be a few kilobytes at least (from an API response, for example). If you collect those in a JSONL file the lines tend to get verrrry long and difficult to edit. CSV files are more compact.

JSONL files are a lot easier to work with though. Less headaches.

[k_bx]

The drawbacks are quite substantial actually – uses much more data per record. For many cases it's a no-go.

[taftster]

Honestly yes. If text editors would have supported these codes from the start, we might not even have XML, JSON or similar today. If these codes weren't "binary" and all scary, we would live in much different world.

I wonder how much we have been hindered ourselves by reinventing plain text human-readable formats over the years. CSV -> XML -> JSON -> YAML and that's just the top-level lineage, not counting all the branches everywhere out from these. And the unix folks will be able to name plenty of formats predating all of this.