CSV to JSON Converter

A CSV file has no type information whatsoever. Every cell is a sequence of characters, and the difference between the number 42 and the string `"42"` simply is not recorded. JSON, by contrast, requires you to commit to a type for every value. So the conversion has to infer, and inference means guessing.

The usual rules are sensible and mostly right: something that looks like a number becomes a number, `true` and `false` become booleans, an empty cell becomes null or an empty string, and everything else stays a string. For most data this produces what you want without any intervention.

The failures are specific and worth knowing in advance. Identifiers made of digits - postcodes, phone numbers, account numbers, ISBNs - become numbers, which strips leading zeros and, above 15 digits, loses precision entirely. Version strings like `1.10` become the number 1.1. And a column that is numeric in most rows and textual in a few produces mixed types in the JSON, which then breaks strict consumers. When identifiers matter, turning type inference off and keeping everything as strings is the safer default.

RFC 4180 describes CSV, but it arrived after the format was already entrenched and it is honoured loosely. Real files vary in delimiter, quoting, line endings and encoding, and a parser has to cope with all of it.

Delimiters are the most visible variation. Comma is standard, but semicolon is normal wherever the decimal separator is a comma - much of Europe - and tab-separated files are common in scientific data. Quoting is the second: a field containing the delimiter must be quoted, and a quote inside a quoted field is escaped by doubling it, so `""` inside quotes means one literal quote character.

Encoding is the one that produces the most confusing symptoms. A UTF-8 byte order mark at the start of a file, which Excel adds when saving as CSV, will otherwise attach itself to the first column name - so `id` silently becomes `\ufeffid` and every lookup for `id` fails. A parser that strips the BOM saves you a genuinely baffling debugging session.

CSV is flat, but headers can encode hierarchy by convention. A column named `user.address.city` describes a path, and interpreting it that way rebuilds the nested object - which is exactly the inverse of what the JSON to CSV tool does when it flattens.

The same notation applies to arrays: `phones[0]` and `phones[1]` become an array of two elements. This makes a round trip through CSV largely faithful, provided the headers were generated rather than typed by hand.

The limitation is the one every dotted-path scheme has: a column name that legitimately contains a dot cannot be distinguished from a nesting separator. If your headers include something like `revenue.2024`, it will become a nested object rather than a single key. Renaming the column is the only reliable fix.