I noticed a repository’s .gitattributes entry for *.csv used text eol=crlf so I investigated and found this.
I hate that the pleasant news about standardization of CSV come with the let-down that is using two bytes for new lines.
Don’t worry, it’s not really standardised despite this attempt. You can use UNIX line endings and nothing bad will happen.
Unless you open it in Excel. In which case bad things will happen no matter what you have in the CSV…
If I am using Excel, I am using Windows and I will be changing all text to use CR-LF newline format (if sending from a Linux system) anyway.
It’s not pleasant news, just interesting news.
I think csv is a bad format, if you can even call it that. Yes, there are some cases where it makes sense. I worked with an oscilloscope at uni which output csv. But other than that, I consider it more of a concept than an interface / exchange standard
more of a concept
And it’s better to be considered so.
The name itself suggests a Comma as a separator, but we know how inconvenient that is and that tab characters tend to be useful in most cases.
Even LibreOffice Calc asks the user what they expect as the separator when given a csv file, even if it has enough commas to feel correct.
We want to move down to the next line (line feed) but also to the beginning of that line (carriage return) after all.
