CSV viewer that reads the quotes properly

Because the value needed quotes around it, and something split the line on commas without checking for them. RFC 4180 says a field containing a comma, a double quote or a line break must be enclosed in double quotes — so "Doe, Jane" is one field and Doe, Jane is two. A parser that walks the line character by character, tracking whether it is inside a quoted field, gets this right; text.split(",") never can. This viewer does the former, which is why the sample file above keeps its comma-bearing names in a single column.

Because Excel writes CSV with the list separator of the machine's locale, and in most of continental Europe that is a semicolon. The reason is the decimal mark: where 1.234,56 is written with a comma, a comma cannot also separate fields without ruining every number. The same file therefore looks like one column to a comma parser and correct to a semicolon one. The detector here parses a sample with each of the four candidates and keeps whichever produces the same field count on the most rows, which usually settles it without you touching the menu.

Yes, as long as the field is quoted — RFC 4180 explicitly allows a line break inside quotes, and a shipping note or an address usually needs one. The consequence catches people out downstream rather than here: a row is no longer a line, so wc -l over-counts your records, split -l can cut a file in the middle of a value, and reading with readline() hands you half a row. Any embedded break is shown as an arrow inside the cell and counted under the table.

You write it twice: ""before noon"" inside the field becomes "before noon" in the data. That doubling is the whole of CSV's escaping mechanism — there is no backslash escape, and adding one produces a literal backslash in the value. Files written by hand often get this wrong and end up with an odd number of quotes on a line, which is what turns a single field into a runaway that swallows the rest of the file. The table reports that case as an unterminated quote with the row it started on.

Because a delimiter got into a value without quotes around it, and every field after it shifted along by one. That is what the amber rows in this table are: their field count differs from the count the rest of the file agrees on, and the tooltip on the row number says how many they have. A row that is one field long is the same fault seen from the other side — a quote opened earlier and has not closed yet, so several physical lines have merged into one record.

No, and nothing in the file can tell you. RFC 4180 makes the header optional and puts the flag outside the data entirely, in a MIME type parameter — text/csv; header=present — that almost nothing sets and no file on disk carries at all. Any tool that shows you column names is guessing, and this one guesses by looking for a first row of short unique non-numeric labels sitting above columns that are mostly numbers or dates. When the guess is wrong, the First row menu overrides it and the table redraws with generic A, B, C headings.

5 MB, roughly 60,000 rows of typical order data, and the size that matters is what gets drawn rather than what gets parsed. Parsing is one linear pass over the characters and takes about 90 milliseconds at that size; the table then renders only the thirty or so rows inside the scroll window plus a small overscan, with two spacer rows standing in for everything above and below. Sorting and searching work over the parsed rows rather than the DOM, so both stay instant while the browser is only ever holding a screenful of cells.