Why quoted fields need real parsing, not a simple split

The naive way to parse CSV — split every line on commas — breaks the moment a field itself legitimately contains a comma, which RFC 4180 handles by allowing a field to be wrapped in double quotes, inside which commas and even newlines are literal data rather than delimiters. A doubled quote (`""`) inside a quoted field represents one literal quote character, which is how CSV escapes a quote without needing a separate escape character. Correctly handling this means tracking whether the parser is currently "inside quotes" as it scans character by character, not just splitting on the delimiter — a genuinely different algorithm than a naive split, and the reason a properly RFC-4180-aware parser handles real-world CSV exports (which very commonly include commas inside free-text fields) correctly where a naive splitter would silently misalign columns.

Why the delimiter is a manual choice, not auto-detected

CSV, TSV, and semicolon-delimited exports (common from European locales, where comma is already the decimal separator) all look superficially similar, and auto-detecting the delimiter reliably is genuinely ambiguous — a comma-delimited file with no commas in any field looks identical to a single-column file no matter what delimiter you guess. Rather than guess and risk silently misparsing the data, this tool asks directly: pick the delimiter that matches the actual source. Getting it wrong is immediately obvious anyway — one giant unsplit column is a clear, unambiguous sign the wrong delimiter was selected, which is easier to diagnose and fix than a guess that's wrong in a way that isn't immediately visible.