CSV в JSON

CSV кажется тривиальным для разбора — разбить каждую строку по запятым, первую строку считать заголовками, — пока в реальных данных не встретится значение, содержащее собственную запятую, а это происходит постоянно в настоящих экспортах из таблиц: адрес вида «123 Main St, Apt 4», название компании вида «Smith, Jones & Co» или описание товара, содержащее перечисление. Спецификация CSV, формализованная как RFC 4180, решает эту проблему, позволяя заключать поле в двойные кавычки: внутри них запятые, переносы строк и даже символы самих кавычек (экранируемые удвоением) считаются просто данными, а не структурой. Парсер, который наивно разбивает строку по каждой запятой, полностью игнорируя кавычки, портит именно такие строки — разбивая «Smith, Jones & Co» на два отдельных столбца, — причём обычно делает это незаметно, без единой ошибки, сигнализирующей, что что-то пошло не так, — именно это и делает такую ошибку опасной, а не просто раздражающей.

Правильный разбор с учётом кавычек отслеживает, находится ли считыватель в данный момент внутри поля в кавычках, и игнорирует символы разделителя и переноса строки до закрывающей кавычки — это единственный способ корректно восстановить поля, которые на законных основаниях содержат символы, иначе принимаемые за структуру.

Каждое значение в исходном CSV-файле — это текст, поскольку у CSV нет собственного понятия числа, логического значения или null: ячейка со значением `42` и ячейка со значением `hello` хранятся одинаково, как набор символов. Определение типов — это процесс угадывания, какие строки «на самом деле» должны были быть числами, значениями true/false или null, и соответствующего их преобразования, чтобы итоговый JSON содержал по-настоящему типизированные значения, а не всё подряд в кавычках как строку.

Однако угадывание должно быть осторожным, потому что немало значений, выглядящих как числа, вовсе не предназначены для того, чтобы становиться числами. Ведущий ноль — `007`, `042` — обычно указывает на идентификатор или код с дополнением, где начальный ноль значим и был бы незаметно уничтожен при преобразовании в число, ведь `7` и `007` — одно и то же число, но совершенно разные идентификаторы. Номер телефона вида `+44 20 7946 0958` выглядит отчасти числовым, но не является арифметическими данными. Значения за пределами безопасного диапазона целых чисел JavaScript теряют точность при любом преобразовании в число. Этот инструмент оставляет всё перечисленное строками именно потому, что ошибка в угадывании здесь означает незаметное повреждение данных, которое легко не заметить ещё очень долго.

Объект JSON не может иметь два ключа с одинаковым именем — второй из встретившихся просто перезаписывает первый, незаметно отбрасывая данные целого столбца, и нигде не возникает ни одной ошибки. Экспорт из таблиц порождает повторяющиеся заголовки чаще, чем можно подумать: отчёт с двумя столбцами «Итого» разного назначения или объединённый экспорт из двух источников, в каждом из которых оказался столбец «Имя». Обнаружение дубликатов и переименование второго вхождения в `name_2` сохраняет данные каждого столбца вместо того, чтобы незаметно потерять тот из них, что оказался первым в объекте строки. Пустые заголовки обрабатываются так же и по той же причине: в JSON нет способа представить ключ, являющийся просто пустой строкой, как значимое, адресуемое поле.