Hacker News Reader

Comment by arp242 | Hacker News Reader

In hindsight, semicolons are the better choice, given that commas are common in many languages as decimal separators.

I don't know where there's never been some effort to create a "CSV format specification"; for example the first line could indicate quoting, delimiter, etc. style used in the file.

Guess it's never been big enough of a problem for people to take action. "Good enough" (or rather, "not bad enough").

View on HN

> In hindsight, semicolons are the better choice, given that commas are common in many languages as decimal separators.

Or a pipe. Or the unprintable “field separator” character.

> I don't know where there's never been some effort to create a "CSV format specification"; for example the first line could indicate quoting, delimiter, etc. style used in the file.

Fundamentally CSV or any delimited format requires agreement between parties for interchange. At that point standards don’t really help because the parties can just agree to anything that works.

> Guess it's never been big enough of a problem for people to take action. "Good enough" (or rather, "not bad enough").

Exactly.

It's very annoying that ascii includes file and record separator characters and csv still exists

The problem there is those code-points are usually non-printable, making the resulting file less human-readable which is often a stated desire for a data transfer file format. Some text editors will show those code points, but others will completely omit them (or worse, reject them as invalid).

If they were something people used then editors would support them

How do you type those in modern text editors?

You used to be able to ctrl + letter to input control keys on traditional terminals — was it (ord(char) - 0x20), but outside Emacs, vi and similar editors, I am sure you can't do that anymore.

If you are questioning existence of human-readable/writeable (typeable?) data formats, you might want to check out SGML/XML, JSON, YAML... Are you surprised that being able to type it out holds true for all of these? Esp on standard keyboards?

It's more interesting how SGML-derived languages have kept <> symbols so accessible on keyboards regular people use.

Or a tab. It's what tabs are for, after all.

Or ASCII 0x1C, 0x1D, 0x1E, and 0x1F. Because those are in the spec exactly for records based files.

I've never understood why these characters aren't used more frequently.

Let's call it ASV - ASCII Separated Values.

FYI: Find some CSV format specifications (and tests) @ https://github.com/csvspecs

> I don't know where there's never been some effort to create a "CSV format specification"

RFC 4180 (https://tools.ietf.org/html/rfc4180) "Common Format and MIME Type for Comma-Separated Values (CSV) Files"

That's not exactly what I mean; that's just one of many different CSV variants (and just because it's an RFC doesn't make it "official" either). What I mean is something like:

  $ cat file.csv
  CSV,quote=always,quotechar=",header=yes,delim=,
  Col1,Col2
  "val","val2"
  [..]

Then you always know what you're dealing with, unambiguously.

There are other cases where embedding some "metadata" in CSV files is useful; for example the exports I create in my app are versioned by prefixing the first header with the version number. It works, but it's not exactly great.

Of course, the downside is legacy software not being able to process it.

There are CSV specs - see https://specs.frictionlessdata.io/csv-dialect/ and https://github.com/csvspecs , for example. Note: Both initiatives are ongoing and alive and kicking. The trouble is almost nobody cares - as your ignorance shows - just complaining and playing the know-it-all is so much easier and more fun, isn't?

You seem like a nice person. Want to be friends?

Reply on news.ycombinator.com