3 ms·

Couldn't tools that read CSV files scan them first and see which variant best matches the file? The questions arise about which end of line character(s) are us

Couldn't tools that read CSV files scan them first and see which variant best matches the file? The questions arise about which end of line character(s) are used and how double-quotes and commas are handled. There can't be that many ways to escape them, and there are three sets of end of line characters mentioned - just see which one is used (i.e. don't assume only \n if you run into \r\n or \r alone). The assumption that most software uses is that the import file will be in the same variant of the format as what that tool exports. That seems to be more of a problem than anything else.

masklinn 5y ago
> Couldn't tools that read CSV files scan them first and see which variant best matches the file? Sure, and they sometimes do that if they have to ingest CSVs whose origin they don't control (although not every system implementor cares enough to do it). But that's still just a bunch of shitty faillible heuristics which would not be necessary if the format was not so horrible.
- Macha 5y ago
  It also doesn't prevent a human or other system doing: cat input1.csv input2.csv > output.csv resulting in a single file containing multiple formats. Also, what variant is this: 1,5,Here is a string "" that does stuff,2021-1-1 What is the value of the third column? Is this a CSV file without quoting? Then it's Here is a string "" that does stuff Or is it a CSV file with double quote escaping? Then it's Here is a string " that does stuff This is fundamentally undecidable without knowledge of what the format it is. You can decide to just assume RFC compliant CSVs in the event of ambiguity, but then you absolutely will get bugs from users with non-RFC compliant CSV files.
  - godshatter 5y ago
    That's true. You could scan the file and see if there are any other types of double quote escaping happening, but if there isn't any that wouldn't help either. It's also negated by the multiple formats in the same file point. So, yeah. Can't really be done without making too many assumptions that will break later.
hermitcrab 5y ago
>Couldn't tools that read CSV files scan them first and see which variant best matches the file? Yes. And my software does that. But it is always going to be a guess which the user needs to be able to override.

masklinn 5y ago

> Couldn't tools that read CSV files scan them first and see which variant best matches the file? Sure, and they sometimes do that if they have to ingest CSVs whose origin they don't control (although not every system implementor cares enough to do it). But that's still just a bunch of shitty faillible heuristics which would not be necessary if the format was not so horrible.

Macha 5y ago
It also doesn't prevent a human or other system doing: cat input1.csv input2.csv > output.csv resulting in a single file containing multiple formats. Also, what variant is this: 1,5,Here is a string "" that does stuff,2021-1-1 What is the value of the third column? Is this a CSV file without quoting? Then it's Here is a string "" that does stuff Or is it a CSV file with double quote escaping? Then it's Here is a string " that does stuff This is fundamentally undecidable without knowledge of what the format it is. You can decide to just assume RFC compliant CSVs in the event of ambiguity, but then you absolutely will get bugs from users with non-RFC compliant CSV files.
- godshatter 5y ago
  That's true. You could scan the file and see if there are any other types of double quote escaping happening, but if there isn't any that wouldn't help either. It's also negated by the multiple formats in the same file point. So, yeah. Can't really be done without making too many assumptions that will break later.

hermitcrab 5y ago

>Couldn't tools that read CSV files scan them first and see which variant best matches the file? Yes. And my software does that. But it is always going to be a guess which the user needs to be able to override.