... продолжает эту мудрую идею ...?
Поскольку вы делаете это как учебное упражнение, вы можете углубиться в lexing и парсинг теория.Ваш текущий подход довольно быстро покажет свои недостатки, как описано в Хватит качать собственный CSV-парсер! .Дело не в том, что анализ CSV-данных затруднен.(Это не так.) Просто большинство проектов парсеров CSV рассматривают проблему как проблему разделения текста, а не как проблему синтаксического анализа.Если вы потратите время на определение "языка" CSV, то синтаксический анализатор почти напишет сам.
RFC 4180 определяет грамматику для данных CSV в ABNF форме:
file = [header CRLF] record *(CRLF record) [CRLF]
header = name *(COMMA name)
record = field *(COMMA field)
name = field
field = (escaped / non-escaped)
escaped = DQUOTE *(TEXTDATA / COMMA / CR / LF / 2DQUOTE) DQUOTE
non-escaped = *TEXTDATA
COMMA = %x2C
CR = %x0D ;as per section 6.1 of RFC 2234
DQUOTE = %x22 ;as per section 6.1 of RFC 2234
LF = %x0A ;as per section 6.1 of RFC 2234
CRLF = CR LF ;as per section 6.1 of RFC 2234
TEXTDATA = %x20-21 / %x23-2B / %x2D-7E
Эта грамматика показывает, как создаются отдельные символы для создания более сложных языковых элементов.(Как написано, определения идут в обратном направлении от сложного к простому.)
Если вы начинаете с грамматики, вы можете написать функции синтаксического анализа, которые отражают нетерминальные элементы грамматики (строчные элементы).Джулиан М. Бакнолл описывает процесс в Написание парсера для данных CSV .Взгляните на Test-Driven Development с ANTLR для примера того же процесса с использованием генератора синтаксического анализатора.
Имейте в виду, что нет единого принятого определения CSV.Данные CSV в дикой природе не гарантируют реализацию всех предложений RFC 4180.