csv形式は正規表現で定義できますか？

同僚と私は最近、純粋な正規表現がcsv形式を完全にカプセル化できるかどうかを議論しました。これにより、任意のエスケープ文字、引用文字、および区切り文字を含むすべてのファイルを解析できます。

正規表現は、作成後にこれらの文字を変更できる必要はありませんが、他のエッジケースで失敗してはなりません。

これはトークナイザーだけでは不可能だと主張しました。これを行うことができる唯一の正規表現は、トークン化だけでなく、非常に複雑なPCREスタイルです。

私は次のラインに沿って何かを探しています：

... csv形式はコンテキストのない文法であるため、正規表現のみで解析することは不可能です...

それとも私は間違っていますか？POSIX正規表現だけでcsvを解析することは可能ですか？

たとえば、エスケープ文字と引用文字の両方がの"場合、これらの2行は有効なcsvです。

"""this is a test.""",""
"and he said,""What will be, will be."", to which I replied, ""Surely not!""","moving on to the next field here..."

理論的には素晴らしいが、実際にはひどい

CSV Iで説明したように規則を意味と仮定するつもりですRFC 4180。

基本的なCSVデータを照合するのは簡単ですが、

"data", "more data"

注：ところで、.split（ '/ n'）。split（ '"'）関数を使用すると、このような非常にシンプルで適切に構造化されたデータを使用する方がはるかに効率的です。正規表現はNDFSM（非決定性有限ステートマシン）は、エスケープ文字などのエッジケースの追加を開始すると、バックトラッキングに多くの時間を無駄にします。

たとえば、私が見つけた文字列に一致する最も包括的な正規表現は次のとおりです。

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

改行としてのエッジケースだけで、野生で見つかったRegExベースのパーサーの99.9999％を破るのに十分です。唯一の「合理的な」代替手段は、高レベルの分析に使用されるステートマシンとペアになった基本制御/非制御文字（つまり、端末と非端末）のトークン化にRegExマッチングを使用することです。

出典：広範な痛みと苦痛として知られている経験。

私はjquery-CSVの著者であり、世界で唯一のJavaScriptベースで完全にRFCに準拠したCSVパーサーです。私は何ヶ月もこの問題に取り組み、多くの知的な人々と話し、コアパーサーエンジンの3つの完全な書き直しを含む異なる実装を試してみました。

tl; dr-話の教訓、PCREだけで、最も単純で厳密な通常の（Ie Type-III）文法以外の構文解析は得策ではありません。とはいえ、終端文字列と非終端文字列のトークン化には便利です。

正規表現は通常の言語を解析でき、再帰的な文法のような派手なものは解析できません。しかし、CSVはかなり規則的なようで、正規表現で解析できます。

定義から作業してみましょう。許可されているのは、シーケンス、選択肢からの選択（|）、繰り返し（Kleene star、the *）です。

• 引用符で囲まれていない値は通常です：[^,]*＃カンマ以外の任意の文字
• 引用された値は規則的です："([^\"]|\\\\|\\")*"＃引用"またはエスケープされた引用\"またはエスケープされたエスケープ以外のシーケンス\\
  • 一部のフォームには、("")*"上記の式にバリアントを追加する、引用符による引用符のエスケープが含まれる場合があります。
• 許可される値は通常です：<unquoted-value> |<quoted-value>
• 単一のCSV行は通常です：<値> (,<値>)*
• で区切られた一連の行\nも明らかに規則的です。

私はこれらの表現のそれぞれを綿密にテストせず、キャッチグループを定義しませんでした。私はまた、いくつかの代わりに使用できる文字の変形のような専門的、上で練り,、"または行区切り：これらは、規則性を壊さない、あなただけのいくつかのわずかに異なる言語を取得します。

この証明で問題を発見できる場合は、コメントしてください！:)

しかし、これにもかかわらず、純粋な正規表現によるCSVファイルの実用的な解析には問題がある場合があります。どのバリアントがパーサーに送られているかを知る必要がありますが、そのための標準はありません。1行が成功するまで各行に対して複数のパーサーを試すか、形式フォームのコメントを分割することができます。しかし、これには、正規表現以外の手段が効率的に、またはまったく必要になる場合があります。

簡単な答え-おそらくそうではありません。

最初の問題は、標準の欠如です。厳密に定義された方法でcsvを記述することはできますが、厳密に定義されたcsvファイルを取得することは期待できません。「あなたは何をするかに保守的であり、他人から受け入れるものに寛大であること」-ジョン・ポスタル

許容できる標準的なスタイルを持っていると仮定すると、エスケープ文字と、これらのバランスを取る必要があるかどうかの問題があります。

多くのcsv形式の文字列はとして定義されstring value 1,string value 2ます。ただし、その文字列にカンマが含まれている場合は、"string, value 1",string value 2です。引用符が含まれている場合、になり"string, ""value 1""",string value 2ます。

この時点では不可能だと思います。問題は、読み込んだ引用符の数と、値の二重引用符モードの内側または外側にコンマがあるかどうかを判断する必要があることです。括弧のバランスを取ることは、不可能な正規表現の問題です。一部の拡張正規表現エンジン（PCRE）はそれを処理できますが、それは正規表現ではありません。

/programming/8629763/csv-parsing-with-a-context-free-grammarが役立つ場合があります。

修正済み：

私はエスケープ文字のフォーマットを見てきましたが、任意のカウントを必要とするものは見つかりませんでした-それはおそらく問題ではありません。

ただし、エスケープ文字とレコード区切り文字（最初から）の問題があります。 http://www.csvreader.com/csv_format.phpは、野生のさまざまな形式に関する優れた資料です。

• 引用符付き文字列のルール（単一引用符付き文字列または二重引用符付き文字列の場合）は異なります。
  • 'This, is a value' 対 "This, is a value"
• エスケープ文字の規則
  • "This ""is a value""" 対 "This \"is a value\""
• 埋め込みレコード区切り文字（{rd}）の処理
  • （生埋め込み）"This {rd}is a value"vs（エスケープ）"This \{rd}is a value"vs（翻訳済み）"This {0x1C}is a value"

ここで重要なことは、常に複数の有効な解釈を持つ文字列を使用できることです。

関連する質問（エッジケースの場合）「受け入れられる無効な文字列を持つことは可能ですか？」

あるアプリケーションによって作成されたすべての有効なCSVと一致し、解析できないすべてのcsvを拒否できる正規表現があることを、私はまだ強く疑っています。

最初にCSVの文法を定義し（テキストに表示される場合、フィールド区切り記号は何らかの方法でエスケープまたはエンコードされますか？）、正規表現で解析可能かどうかを判断できます。最初の文法：2番目のパーサー：http : //www.boyet.com/articles/csvparser.htmlこのメソッドはトークナイザーを使用することに注意する必要があります-しかし、すべてのエッジケースに一致するPOSIX正規表現を構築することはできません。CSV形式の使用が不規則で、文脈に依存しない場合...あなたの答えはあなたの質問にあります。概要：http : //nikic.github.com/2012/06/15/The-true-power-of-regular-expressions.html

RFCで説明されているように、この正規表現は通常のCSVをトークン化できます。

/("(?:[^"]|"")*"|[^,"\n\r]*)(,|\r?\n|\r)/

説明：

• ("(?:[^"]|"")*"|[^,"\n\r]*) -引用符付きまたは引用符なしのCSVフィールド
  • "(?:[^"]|"")*" -引用されたフィールド。
    • [^"]|""-各文字はでないか"、または"エスケープされています""
  • [^,"\n\r]* -引用符で囲まれていないフィールド。 , " \n \r
• (,|\r?\n|\r)-次の区切り文字、,または改行
  • \r?\n|\r -改行、 \r\n \n \r

この正規表現を繰り返し使用して、CSVファイル全体を照合および検証できます。次に、引用符で囲まれたフィールドを修正し、区切り文字に基づいて行に分割する必要があります。

正規表現に基づいたJavaScriptのCSVパーサーのコードは次のとおりです。

var csv_tokens_rx = /("(?:[^"]|"")*"|[^,"\n\r]*)(,|\r?\n|\r)/y;
var csv_unescape_quote_rx = /""/g;
function csv_parse(s) {
    if (s && s.slice(-1) != '\n')
        s += '\n';
    var ok;
    var rows = [];
    var row = [];
    csv_tokens_rx.lastIndex = 0;
    while (true) {
        ok = csv_tokens_rx.lastIndex == s.length;
        var m = s.match(csv_tokens_rx);
        if (!m)
            break;
        var v = m[1], d = m[2];
        if (v[0] == '"') {
            v = v.slice(1, -1);
            v = v.replace(csv_unescape_quote_rx, '"');
        }
        if (d == ',' || v)
            row.push(v);
        if (d != ',') {
            rows.push(row)
            row = [];
        }
    }
    return ok ? rows : null;
}

この答えがあなたの議論を解決するのに役立つかどうかは、あなたが決めることです。小さくてシンプルで正しいCSVパーサーがあればうれしいです。

私の意見では、lexプログラムは多かれ少なかれ大きな正規表現であり、それらはCプログラミング言語などのはるかに複雑な形式をトークン化できます。

RFC 4180定義を参照して：

1. 改行（CRLF）-正規表現はより柔軟で、CRLF、LF、またはCRを使用できます。
2. ファイル内の最後のレコードには、終了改行がある場合とない場合があります-正規表現には最終改行が必要ですが、パーサーはそのために調整します。
3. オプションのヘッダー行があるかもしれません-これはパーサーに影響を与えません。
4. 各行には、ファイル全体で同じ数のフィールドが含まれている必要があります-強制されていない
   スペースはフィールドの一部と見なされ、無視されるべきでは
   ありません-OK
5. 各フィールドは、二重引用符で囲まれていてもいなくてもかまいません...-わかりました
6. 改行（CRLF）、二重引用符、およびコンマを含むフィールドは二重引用符で囲む必要があります-OK
7. フィールド内に現れる二重引用符は、その前に別の二重引用符を付けてエスケープする必要があります-わかりました

正規表現自体は、RFC 4180要件のほとんどを満たしています。他の人には同意しませんが、パーサーを調整してそれらを実装するのは簡単です。