Indeed, as I noted in the article I linked to above, in practice there are so many varieties of escaping conventions, and even in the specifics of delimiting itself, that we find ourselves in a needlessly complicated world of horribly formatted data.AxWald wrote:I think we're talking about semantics here. For sure, CSV isn't a standard. An RFC for it exists, but it doesn't seem to have ever reached approval.
Exactly. And this is compounded by the common frequency of commas in textual data, making commas an ever worse choice beyond hope of redemption as a generalized format.Besides this, the term "Comma Separated Values" is grossly misleading, because this would make it unusable for large parts of the world, where the comma is used as decimal separator (Am I right that the comma is used in anglo-american notation as separator for thousands?). No fractional numbers possible, nor nicely formatted ones? This doesn't make sense at all.
SQL dumps use CSV, and many published data sets use it as well, as I noted in my article. I haven't used Microsoft Excel in years, but double-checking LibreOffice Calc this morning it uses comma as the default when I choose "Save As" with the "CSV" option.So, even if Wikipedia claims this name to be correct, it isn't. Nobody uses commas as field delimiters! The current common use is to have semicolons as field delimiters, check in your office software!
We can use any terms we like to describe anything, but being explicit is sometimes helpful.As mentioned, IMHO we're discussing semantics here. I may have another view of CSV as you, and you may not agree to my view of it as "Character Separated Values".
If I tell people I work for the "CIA" and provide no further clarification, I can hardly blame them if they belive I work for the Central Intelligence Agency when I might work for Catalina Island Aviation.
The Help file on CSV for LibreOffice explicitly defines "CSV" as "Comma-Separated Values":
https://help.libreoffice.org/Calc/Impor ... _CSV_Files
Microsoft Office's Help also defines "CSV" as "Comma Separated Values", using ".txt" for tab-separated values:
https://support.office.com/en-us/articl ... e8a008ba5c
When discussing delimited data in general, I find it's helpful to just use "delimited data", distinguishing from the decades-long history of the "C" in CSV" meaning "Comma".
To further distinguish tab-delimited data (arguably the sanest choice) specifically, in writing I describe it as "tab-delimited" and in file extensions I use "*.tab".
Relax. It's all good. Thankfully for all of us, I have no control over what anyone other than myself does with a keyboard.I'm (to be precise: the servers my LC standalones run on) sending literally thousands of CSV packets each hour, like this:(This is a real-world example of the acknowledgment of an order, and it's actually REAL CSV!Code: Select all
ORD received: 212445, 84, 53a2a591deb6d 0154120,2.3,6 9141000,3.14,12 7008510,4.15,6 0856030,8.93,6 0856010,9.64,6)
So, please abandon your evil desire to kill poor old CSV!
It hasn't done no harm to you, and it would break my heart would I be forced to replace this nice, cute, little piece of datagram with an XML equivalent, where alone the parentheses would be more than the actual data ...
As I describe in the article I've referred to but is apparently not interesting enough to have been read, the problem with commas is no more and no less than what you've noted yourself: commas often appear in data.
So using commas as a generalized solution for data exports is inherently prone to inefficiency and complexity.
This widely-used convention has indeed caused all of us harm, in millions of lost hours among both developers and end-users alike. At best it's wasted clock cycles, and at worst the complexity has led to bugs resulting in invalid imports.
If my advocacy for choosing any other delimiter is "evil", please note your comments above where you do so yourself.
I don't think either of us is being evil. I think we're both just trying to solve real-world problems in an efficient way.
Your data set above is a very good example, as are the many functions in HyperCard and LiveCode that return values delimited by commas.
The important distinction here is that commas are used as delimiters in LiveCode values only when it can be known that commas won't also appear in the data being delimited. For example, getting the rect of an object will return a comma-delimited value.
But when LiveCode needs to return data in which commas may appear, such as the cardNames, it uses return as the delimiter rather than comma.
When writing data used by systems you control, use whatever works.
But when a client asks you to generate CSV exports, I recommend - as you do - using tab-delimited instead.
All of this is discussed in my article. It's a shame I don't have David Sedaris' gift for entertaining writing style, because if the article were read as frequently as its argued against there would likely be less argument, since in the end we all seem to agree with what's proposed there.
