HTML vs. CSV vs. ASCII Comparison Output

The Comma Problem, Concretely

CSV (comma-separated values) splits a row into columns at every comma. That works perfectly until a value in the data itself contains a comma -- which construction activity names do constantly: “Install Doors, Frames & Hardware” or “Excavate, Backfill & Compact.” Without proper quoting, that single activity name silently splits into two or three spreadsheet columns instead of one, shifting every column after it one or two positions to the right for that entire row.

Both rows above are byte-for-byte identical text -- the difference is entirely in whether the value containing a comma was wrapped in quotation marks before being written, which a naive string-concatenation export can easily skip.

The fix on the writing side is straightforward -- wrap any field containing a comma (or a quote character, or a newline) in double quotes, and double up any literal quote characters inside it, per the standard CSV quoting rule. The failure mode is common precisely because that quoting step is easy to skip when a report is generated by simply joining values with commas rather than using a real CSV writer that handles quoting automatically.

Three Formats, Three Different Tradeoffs

ASCII / plain text

Readable directly as a document -- good for printing or a quick visual check, but not something a spreadsheet can parse into sortable columns without real work.

CSV

Importable into a spreadsheet for sorting and filtering -- exactly the comma-collision problem above if the export doesn’t quote fields correctly.

HTML

Each value lives inside its own table cell tag, so a comma or quote character inside the data never gets confused with a column boundary -- readable in any browser, but not directly importable into a spreadsheet without a conversion step of its own.

Frequently Asked Questions

Why not just always use tab-delimited instead of comma-delimited?

It avoids the comma-in-data problem specifically, but activity names or notes occasionally contain literal tab characters too (pasted from another document, for instance), and plenty of downstream tools still assume comma-separated by default -- there's no delimiter choice that's completely immune to appearing inside real-world text data.

What does 'ASCII' output actually mean in this context?

A fixed-width or plain-text report meant to be read as a monospaced document (or printed) rather than imported into another program -- readable directly, but not something a spreadsheet or database can parse into columns without extra work.

Is HTML output immune to all of this?

It sidesteps the delimiter-collision problem entirely, since each value lives inside its own explicit table cell tag rather than being separated by a character that might also appear in the data -- but an HTML report isn't directly importable into a spreadsheet for further sorting/filtering without an extra conversion step of its own.