CSV's missing standard: what RFC 4180 covers and what it leaves open

Whose CSV is correct? — two exports of the same table, one with semicolons and one with commas, both called CSV

ToolAcre can emit comma-, semicolon- or tab-delimited output from JSON. It does not read two competing CSV exports or declare either one correct. CSV is write-only here, so delimiter choice is an explicit output option rather than a detection algorithm.

That distinction prevents a common factual slip. An interface that can write semicolons has not proved it can identify semicolons in an unknown file, handle locale decimals or interpret headers. Those are separate input responsibilities deliberately excluded.

Two delimiter choices are output options, not evidence that this panel reads either file

The repository contains no source for early spreadsheet or database history, so the article does not invent a chronology. It starts with the current writer and its tests: records, fields, delimiters, CRLF termination and quote escaping.

Historical context can be added later with reviewed sources. A converter implementation is evidence for what the product writes today, not for when a convention first appeared or why vendors diverged.

CSV history before RFC 4180 is outside repository evidence

A field containing the delimiter, double quote, carriage return or line feed is enclosed in double quotes, and each embedded quote is doubled. Leading or trailing whitespace is also quoted to prevent common spreadsheet trimming. Records end with CRLF and the file is terminated.

These behaviours follow RFC 4180-style rules tested in the repository. The article avoids claiming universal compliance because the writer also supports alternative delimiters and adds security handling outside the narrow grammar.

The writer uses RFC 4180-style quoting and CRLF without claiming full standard compliance

CSV cells do not preserve JSON types. Null and empty string both become empty cells, while booleans and numbers become text representations. UTF-8 content is passed through and an optional BOM can be prefixed for consumers that need it.

Locale interpretation is not embedded. A semicolon delimiter can coexist with decimal commas, but the writer does not reformat numbers by locale or encode a date type. The receiving application still decides how to interpret each field.

Encoding, type and locale boundaries remain explicit in this writer

The implemented variations are comma, semicolon and tab, plus an optional BOM. Formula-like text beginning with `=`, `+`, `-`, `@`, tab or carriage return is prefixed with an apostrophe by default so spreadsheets treat it as text. Users can disable that protection and receive a warning.

There is no `sep=` hint or backslash-escape mode in this writer. Mentioning those as shipped options would be false. Embedded quotes use doubling, exactly as the tests assert.

Observed spreadsheet variations are limited to options and protections implemented here

Every assumption in this route starts from parsed JSON: which value supplies rows, how nesting flattens into dotted columns and which keys become headers. No assumption is made about an incoming CSV dialect because incoming CSV is rejected.

This correction reverses the workbook’s requested direction. A CSV-to-JSON workflow must choose delimiter, quoting, header and cell types in another tool. ToolAcre’s error explains that refusal rather than quietly guessing.

Conversion assumptions apply to JSON-to-CSV only because CSV input is refused

Repairing malformed CSV is outside scope. Broken quotes, mixed encodings and accidental delimiters need the CSV Cleaner or another parser with explicit diagnostics. The syntax converter receives strict JSON, not damaged CSV text.

Output can still be unsuitable for a target when a nested tree creates ambiguous dotted columns or exceeds 2,000 columns. Warnings and caps expose those table-shape failures before download.

Takeaway: CSV is a convention, not a format — and how the Syntax converters panel turns a well-formed file into JSON you can inspect

Treat CSV as a convention whose choices must be visible. ToolAcre documents its output choices and refuses the under-specified reverse. That is more reliable than using one button for two fundamentally different jobs.

Inspect delimiter, quotes, CRLF, BOM and formula escaping against the receiving system. If input parsing is required, use a tool that asks instead of transferring the writer’s conventions onto an unknown file.

A practical acceptance check opens the generated file in the intended consumer and also examines the raw bytes or text. The consumer view catches display and import problems; the raw view confirms delimiter, doubled quotes, CRLF and an optional BOM without spreadsheet reinterpretation. Test formula-like strings as inert text and a negative number as a number. Those paired checks verify the writer’s actual contract without claiming that every program implements CSV conventions identically.