Choosing between tsv and csv

TSV-utils makes an interesting comparison, copied here after. In a nutshell, use TSV.

Comparing TSV and CSV formats

The differences between TSV and CSV formats can be confusing. The obvious distinction is the default field delimiter: TSV uses TAB, CSV uses comma. Both use newline as the record delimiter.

By itself, using different field delimiters is not especially significant. Far more important is the approach to delimiters occurring in the data. CSV uses an escape syntax to represent comma and newlines in the data. TSV takes a different approach, disallowing TABs and newlines in the data.

The escape syntax enables CSV to fully represent common written text. This is a good fit for human edited documents, notably spreadsheets. This generality has a cost: reading it requires programs to parse the escape syntax. While not overly difficult, it is still easy to do incorrectly, especially when writing one-off programs. It is good practice is to use a CSV parser when processing CSV files. Traditional Unix tools like cut, sort, awk, and diff do not process CSV escapes, alternate tools are needed.

By contrast, parsing TSV data is simple. Records can be read using the typical readline routines found in most programming languages. The fields in each record can be found using split routines. Unix utilities can be called by providing the correct field delimiter, e.g. awk -F "\t", sort -t $'\t'. No special parser is needed. This is much more reliable. It is also faster, no CPU time is used parsing the escape syntax.

The speed advantages are especially pronounced for record oriented operations. Record counts (wc -l), deduplication (uniq, tsv-uniq), file splitting (head, tail, split), shuffling (GNU shuf, tsv-sample), etc. TSV is faster because record boundaries can be found using highly optimized newline search routines (e.g. memchr). Identifying CSV record boundaries requires fully parsing each record.

These characteristics makes TSV format well suited for the large tabular data sets common in data mining and machine learning environments. These data sets rarely need TAB and newline characters in the fields.

The most common CSV escape format uses quotes to delimit fields containing delimiters. Quotes must also be escaped, this is done by using a pair of quotes to represent a single quote. Consider the data in this table:

In Field-2, the first value contains a comma, the second value contain both quotes and a comma. Here is the CSV representation, using escapes to represent commas and quotes in the data.

Field-1,Field-2,Field-3
abc,"hello, world!",def
ghi,"Say ""hello, world!""",jkl

In the above example, only fields with delimiters are quoted. It is also common to quote all fields whether or not they contain delimiters. The following CSV file is equivalent:

"Field-1","Field-2","Field-3"
"abc","hello, world!","def"
"ghi","Say ""hello, world!""","jkl"

Here's the same data in TSV. It is much simpler as no escapes are involved:

Field-1 Field-2 Field-3
abc hello, world!   def
ghi Say "hello, world!" jkl

The similarity between TSV and CSV can lead to confusion about which tools are appropriate. Furthering this confusion, it is somewhat common to have data files using comma as the field delimiter, but without comma, quote, or newlines in the data. No CSV escapes are needed in these files, with the implication that traditional Unix tools like cut and awk can be used to process these files. Such files are sometimes referred to as "simple CSV". They are equivalent to TSV files with comma as a field delimiter. Traditional Unix tools and tsv-utils tools can process these files correctly by specifying the field delimiter. However, "simple csv" is a very ad hoc and ill defined notion. A simple precaution when working with these files is to run a CSV-to-TSV converter like csv2tsv prior to other processing steps.

Note that many CSV-to-TSV conversion tools don't actually remove the CSV escapes. Instead, many tools replace comma with TAB as the record delimiter, but still use CSV escapes to represent TAB, newline, and quote characters in the data. Such data cannot be reliably processed by Unix tools like sort, awk, and cut. The csv2tsv tool in tsv-utils avoids escapes by replacing TAB and newline with a space (customizable). This works well in the vast majority of data mining scenarios.

To see what a specific CSV-to-TSV conversion tool does, convert CSV data containing quotes, commas, TABs, newlines, and double-quoted fields. For example:

$ echo $'Line,Field1,Field2\n1,"Comma: |,|","Quote: |""|"\n"2","TAB: |\t|","Newline: |\n|"' | <csv-to-tsv-converter>

Approaches that generate CSV escapes will enclose a number of the output fields in double quotes.

References:

• Wikipedia: Tab-separated values - Useful description of TSV format.
• IANA TSV specification - Formal definition of the tab-separated-values mime type.
• Wikipedia: Comma-separated-values - Describes CSV and related formats.
• RFC 4180 - IETF CSV format description, the closest thing to an actual standard for CSV.
• brendano/tsvutils: The philosophy of tsvutils - Brendan O'Connor's discussion of the rationale for using TSV format in his open source toolkit.
• So You Want To Write Your Own CSV code? - Thomas Burette's humorous, and accurate, blog post describing the troubles with ad-hoc CSV parsing. Of course, you could use TSV and avoid these problems!

The choice depends on the application. In a nutshell, if your fields don't contain commas, use CSV; otherwise TSV is the way to go.

TL;DR

In both formats, the problem arises when the delimiter can appear within the fields, so it is necessary to indicate that the delimiter is not working as a field separator but as a value within the field, which can be somewhat painful.

For example, using CSV: Kalman, Rudolf, von Neumann, John, Gabor, Dennis

Some basic approaches are:

• Delete all the delimiters that appear within the field.

  E.g. Kalman Rudolf, von Neumann John, Gabor Dennis

• Escape the character (usually pre-appending a backslash \).

  E.g. Kalman\, Rudolf, von Neumann\, John, Gabor\, Dennis

• Enclose each field with other character (usually double quotes ").

  E.g. "Kalman, Rudolf", "von Neumann, John", "Gabor, Dennis"

CSV

The fields are separated by a comma ,.

For example:

Name,Score,Country
Peter,156,GB
Piero,89,IT
Pedro,31415,ES

Advantages:

• It is more generic and useful when sharing with non-technical people, as most of software packages can read it without playing with the settings.

Disadvantages:

• Escaping the comma within the fields can be frustrating because not everybody follows the standards.
• All the extra escaping characters and quotes add weight to the final file size.

TSV

The fields are separated by a tabulation <TAB> or \t

For example:

Name<TAB>Score<TAB>Country
Peter<TAB>156<TAB>GB
Piero<TAB>89<TAB>IT
Pedro<TAB>31415<TAB>ES

Advantages:

• It is not necessary to escape the delimiter as it is not usual to have the tab-character within a field. Otherwise, it should be removed.

Disadvantages:

• It is less widespread.

TSV is a very efficient for Javascript/Perl/Python to process, without losing any typing information, and also easy for humans to read.

The format has been supported in 4store since its public release, and it's reasonably widely used.

The way I look at it is: CSV is for loading into spreadsheets, TSV is for processing by bespoke software.

You can see here the technical specification of each here.