Хороший в теории, ужасный на практике
Под CSV я предполагаю, что вы имеете в виду соглашение, описанное в RFC 4180 .
Хотя сопоставление базовых данных CSV тривиально:
"data", "more data"
Примечание: Кстати, намного эффективнее использовать функцию .split ('/ n'). Split ('"') для очень простых и хорошо структурированных данных, подобных этой. Регулярные выражения работают как NDFSM (недетерминированный конечный State Machine), который тратит много времени на возврат, когда вы начинаете добавлять крайние случаи, такие как escape-символы.
Например, вот наиболее полная строка соответствия регулярного выражения, которую я нашел:
re_valid = r"""
# Validate a CSV string having single, double or un-quoted values.
^ # Anchor to start of string.
\s* # Allow whitespace before value.
(?: # Group for value alternatives.
'[^'\\]*(?:\\[\S\s][^'\\]*)*' # Either Single quoted string,
| "[^"\\]*(?:\\[\S\s][^"\\]*)*" # or Double quoted string,
| [^,'"\s\\]*(?:\s+[^,'"\s\\]+)* # or Non-comma, non-quote stuff.
) # End group of value alternatives.
\s* # Allow whitespace after value.
(?: # Zero or more additional values
, # Values separated by a comma.
\s* # Allow whitespace before value.
(?: # Group for value alternatives.
'[^'\\]*(?:\\[\S\s][^'\\]*)*' # Either Single quoted string,
| "[^"\\]*(?:\\[\S\s][^"\\]*)*" # or Double quoted string,
| [^,'"\s\\]*(?:\s+[^,'"\s\\]+)* # or Non-comma, non-quote stuff.
) # End group of value alternatives.
\s* # Allow whitespace after value.
)* # Zero or more additional values
$ # Anchor to end of string.
"""
Он разумно обрабатывает одинарные и двойные кавычки, но не переводит строки в новые значения, экранированные кавычки и т. Д.
Источник: Переполнение стека - Как я могу разобрать строку с помощью JavaScript
Это становится кошмаром, когда общие крайние случаи введены как ...
"such as ""escaped""","data"
"values that contain /n newline chars",""
"escaped, commas, like",",these"
"un-delimited data like", this
"","empty values"
"empty trailing values", // <- this is completely valid
// <- trailing newline, may or may not be included
Одного краевого случая новой строки как значения достаточно, чтобы сломать 99,9999% анализаторов на основе RegEx, найденных в дикой природе. Единственная «разумная» альтернатива - использовать сопоставление RegEx для базового токенизации управляющих / неконтрольных символов (т. Е. Терминал против нетерминала) в сочетании с конечным автоматом, используемым для анализа более высокого уровня.
Источник: опыт, иначе известный как сильная боль и страдание.
Я являюсь автором jquery-CSV , единственного в мире полностью совместимого с RFC парсера CSV на основе javascript. Я потратил месяцы на решение этой проблемы, общаясь со многими умными людьми и пробуя кучу разных реализаций, включая 3 полных переписывания ядра парсера.
tl; dr - Мораль истории, один только PCRE - отстой для анализа чего угодно, кроме самых простых и строгих регулярных (т. е. Type-III) грамматик. Хотя это полезно для токенизации терминальных и нетерминальных строк.