Comma-Separated Values (CSV) is arguably the most ubiquitous data exchange format in the world, largely because it is human-readable and supported by every spreadsheet software. At its core, each line is a record, and each field is separated by a comma.
However, CSV is notoriously difficult for developers because for decades there was no strict standard. Implementations vary wildly. The closest thing to a standard is RFC 4180, which defines strict rules for handling edge cases like line breaks, embedded commas, and quotes within the data itself.
The quoting rule for embedded commas
The most obvious problem with CSV is handling a field that legitimately contains a comma. For example, a location field containing 'Springfield, IL'. If placed raw into a CSV, a parser will split it into two separate fields, breaking the column structure.
RFC 4180 dictates that any field containing a comma must be enclosed in double quotes. The record becomes: John,Smith,"Springfield, IL". The parser knows to ignore commas found inside the double quotes.
Escaping quotes within quotes
The quoting rule solves the comma problem but introduces a new one: what if the data itself contains a double quote? For example, a product description like: Monitor 24" LED. If you wrap the field in quotes, the internal quote terminates the field prematurely.
The CSV escaping rule states that to represent a literal double quote inside a quoted field, you must double it. The correct encoding is: "Monitor 24"" LED". Failure to handle this specific escape sequence is the number one reason custom-written CSV parsers fail in production environments, highlighting why developers should always use established CSV parsing libraries.