The central problem (I'd almost say the fatal mistake) of these formats is that the text we want to send is very likely to contain the characters used to delimit it.
Like null pointers, this is something which is inherently error prone, insecure, and a continual source of bug reports.
The genius of ASCII (and the perceptiveness of the proposers of formats like USV) is that way back in 1960, they foresaw this problem and gave us a solution to it: ASCII has a very rich set of delimiting characters which are deliberately kept separate from the characters you most likely transmit as text.
At one stroke, this eliminates all the problems of which delimiting characters to use (commas? whitespace, vertical bars? newline? return? return and newline?) how to escape delimiting characters (put them in quotes? prefix them with backslash? use the ascii "ESC" character?) and how to escape the escape characters (using multiple ways to quote a string, single quote, double quotes,etc).
And it completely eliminates all the bugs caused by all the subtle difficulties needed to make such escaping actually work in a secure fashion. And the need to update all your code when somebody releases a new version of their CSV package, which fixes some bugs which other packages use as features....
ASCII gives us delimiting characters on 4 levels: field, record, group and file. It is far more capable than CSV files. It's powerful enough to represent the tabular data of a relational database, or a bunch of related spreadsheets. It even lets us specify a header where we can define column names, etc. It really is a shame we haven't been using those all along.
Its actually comparable to JSON in its ability to represent articulated data--arguably better, because it is table-based and not just key-value based. Any method used to swizzle JSON into tabular form for a relational database can encode JSON using these delimiting characters. And without having to quote all the key strings!!
Like null pointers, this is something which is inherently error prone, insecure, and a continual source of bug reports.
The genius of ASCII (and the perceptiveness of the proposers of formats like USV) is that way back in 1960, they foresaw this problem and gave us a solution to it: ASCII has a very rich set of delimiting characters which are deliberately kept separate from the characters you most likely transmit as text.
At one stroke, this eliminates all the problems of which delimiting characters to use (commas? whitespace, vertical bars? newline? return? return and newline?) how to escape delimiting characters (put them in quotes? prefix them with backslash? use the ascii "ESC" character?) and how to escape the escape characters (using multiple ways to quote a string, single quote, double quotes,etc).
And it completely eliminates all the bugs caused by all the subtle difficulties needed to make such escaping actually work in a secure fashion. And the need to update all your code when somebody releases a new version of their CSV package, which fixes some bugs which other packages use as features....
ASCII gives us delimiting characters on 4 levels: field, record, group and file. It is far more capable than CSV files. It's powerful enough to represent the tabular data of a relational database, or a bunch of related spreadsheets. It even lets us specify a header where we can define column names, etc. It really is a shame we haven't been using those all along.
Its actually comparable to JSON in its ability to represent articulated data--arguably better, because it is table-based and not just key-value based. Any method used to swizzle JSON into tabular form for a relational database can encode JSON using these delimiting characters. And without having to quote all the key strings!!