Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CSV 1.1 – CSV Evolved (for Humans)

csv11.github.io

Post reply on HN
Print view View original

31–40 of 81 posts

Re: CSV 1.1 – CSV Evolved (for Humans)

#31

Post by jstimpfle »

Some time ago I've worked on a similar, CSV-like thing that improves on readability and canonical representation, and which can hold multiple tables in a single file or stream like a database: http://jstimpfle.de/projects/wsl/main.html . (I hope it's not rude to reference it here)

Re: CSV 1.1 – CSV Evolved (for Humans)

#33

Post by kristofferR »

CSV is hell, glad to see improvements. Some idiot somewhere decided that Comma Separated Values in certain locales should be based on semicolons (who would have thought files would be shared across country borders!?), so when we open CSV files that are actually comma separated all the information is in the first cell (until a semicolon appears).

To get comma separated CSVs to show properly in Excel we have to mess around with OS language settings. CSV as a format should have died years ago, it's a shame so many apps/services only export CSV files. Many developers (mainly US/UK based) are probably not aware of how much of a headache they inflict on people in other countries by using CSV files.

Re: CSV 1.1 – CSV Evolved (for Humans)

#34

Post by int_19h »

kristofferR wrote: post #33

CSV is hell, glad to see improvements. Some idiot somewhere decided that Comma Separated Values in certain locales should be based on semicolons (who would have thought files would be shared across country borders!?), so when we open CSV files that are actually comma separated all the information is in the first cell (until a semicolon appears). To get comma separated CSVs to show properly in Excel we have to mess ar…

Semicolons come from many countries using the decimal comma in lieu of the decimal period. Of course, locale-specific number formatting should be a big no-no in any kind of a portable format anyway. But...

Re: CSV 1.1 – CSV Evolved (for Humans)

#35

Post by int_19h »

The best thing we have today for "CSV evolved" is JSON array of arrays, IMO. It's much better specified, everything agrees on how things should be quoted, it's perfectly human-readable if you do one array per line, its semantics follows straightforwardly from that of JSON, and we already have parsers for it that produce a reasonable output.

Is it slightly more verbose? Sure, but why does it matter? Having to quote all strings is really not a big deal.

Re: CSV 1.1 – CSV Evolved (for Humans)

#36

Post by fantispug »

legostormtroopr wrote: post #13

There are a ton of problems here: * From the documentation "No quotes needed for values ... Use dual quotes ... Use triple quotes" * You haven't solved the problem of describing what the columns are. In fact, its worse because you are encouraging people to put units in the field * Spaces matter! What if the data is literally " Word " vs "Word". This format makes them both the same. * For some reason, the header row i…

Regarding quotes, they're optional (e.g. when you need a comma, leading whitespace, or newline). With arguments by position possible I guess colons have to be quoted too.

It's not clear to me that it's possible to convert this to a standard CSV; it can't guess the header and guessing whether a column contains units (consistent units?) is asking for trouble.

More pragmatically I can't share these with other people because they're almost like a csv, but incompatible.

It's great to try to make CSV more readable (I like the leading whitespace, but it'd be finicky to maintain with simple text editors), but not worth the technical risk of format confusion.

Re: CSV 1.1 – CSV Evolved (for Humans)

#37

Post by eksemplar »

I’m sorry, but when do you ever need to read a CSV file in an environment where you don’t have a spreadsheet editor anyway?

I work in the public sector, we use a lot of CVS, even to non tech savvy people.

I’ve never heard the use case for this project.

Now that might not matter, but you’re breaking CVS to fulfill a nonexistent use case.

Re: CSV 1.1 – CSV Evolved (for Humans)

#38

Post by deathanatos »

wlesieutre wrote: post #26
hodgesrm wrote: post #15

Earlier quoted context omitted.

To your point it's hard to see how the referenced article qualifies as a standard. It does not deal with escape characters or missing values, two places where CSV implementations tend to vary in random ways.

I've recently been dealing with some CSV data exported from Excel. One of the columns has lengths measured in inches or feet. A column that says 14" exports as , '"14"""', It feels downright silly to me.

A cell w/

    14"
would be

    ,"14""",
And I verified that all four of Excel's CSV varieties write this, but this is also what RFC CSV writers would emit. Not saying you can't pick up oddities elsewhere, but as stated, it's not that bad. (Not that I condone use of CSV… it's an awful format.)

Re: CSV 1.1 – CSV Evolved (for Humans)

#39

Post by deathanatos »

jstimpfle wrote: post #32
enygmata wrote: post #8

This is not VCS friendly. Resize any column and you have to rewrite 99% of the file, tracking changes becomes hell on earth.

What do you mean by "resize any column"?

I presume the parent means changing the data s.t. the max length of strings in a column changes; this would cause the padding after that column to change, so as to keep subsequent columns aligned & looking nice. This doesn't play well w/ VCS diffs, as a bunch of data that isn't changing semantically is now changing syntactically, and a simplistic textual diff reflects now that syntactic change, whereas a human reader would want to see the semantic change.

Now… most diff tools also have options to ignore whitespace changes, for cases like this.

Post reply on HN