C# 文字列操作 カンマと分割

CSV と似た処理になりますが、特殊です。
何故なら、プログラム言語のソース解読 で使うから。
カンマ区切りで記述されますが、
其の中に　文字列の一部としてカンマが紛れ込んだら ... 。


カンマ区切りで引数を記述した文 (Python) を解読し、
値を読み取って行くのですが、
ある場所のみ、各項目中にカンマが出現する可能性があります。
素直に、カンマで分解して仕舞うと、
後続する処理が狂って仕舞います。

一例を示せば、

[ (PF_STRING, "fn_Number_string", ("Numbering Start String (nnnn): "), "0000"),
  (PF_ADJUSTMENT, "fn_Seq_Int", ("Sequential Number (nn): "), 18, ( 1, 99, 1)),
  (PF_TOGGLE, "IsSavingFiles", ("Save Files ?  (Set Name Only, You Must Save!) : "), True)
],

但し、５番目に登場する可能性のある ( x, y, z) のカンマは分解されても問題はありません。
寧ろ、分解された方が、後続の処理には 好都合 なのです。
ですから、３番目のみ、項目中にカンマがあっても分割したくは無い ... と。
また、３番目は、括弧の有無が不定です。　　あったり、無かったり。

さて、どうしましょ。
最初は、　正規表現　を使う事を考えました。
括弧が必ずあるなら、外の括弧 が外れた状態で、 ¥(.+?¥)　等で Hit しますし、
" で探すなら、"(.*?)"　の２番目ですね。
中身だけとか、中のカンマだけとなると、　私にゃ～もう～ ... です。　　X(

　　正直に書きます。
　　私、　正規表現、全く、分かっていません。
　　お手上げ！ ... 。
　　仮に、今回書けても、将来の変更 にはとても付いて行け無いでしょう。

文字操作が 永遠と続く 如くな、此の Program 。
此処でだけ、慣れ無い 正規表現 を導入しても、
メンテナンス時に 壊しそうな 気がしまして、
コツコツと書く事にしました。

方針は、
該当箇所を探り出し、カンマを別文字で置換の上、カンマで分割し、再び、別文字をカンマに戻す ... 。


Subroutine の中での記述を引用しましょう。
Loop 的に呼ばれ、各項目を処理します。
各項目は (PF_ ～ ), 或いは (PF_ ～ ) 改行 ], です。

// If 3rd Param.(Description) Include "," , Replace "☒" Before Split by ","

bool hasShowingComma = false;   // 3rd Param.
string commaBeforeSplit = "☒";
string item = itemRaw.Replace("¥r¥n", "").Trim();

int itemIdx1 = item.IndexOf(","); // Start PF_type
int itemIdx2 = item.IndexOf(",", itemIdx1 + 1);     // Start argName
int itemIdx3f = item.IndexOf("¥"", itemIdx2 + 1);   // Start ShowingString
int itemIdx3t = item.IndexOf("¥"", itemIdx3f + 1);  // End ShowingString
string showingStr = item.Substring(itemIdx3f, itemIdx3t - itemIdx3f - 1);

// For Split
if (showingStr.Contains(","))
{
    hasShowingComma = true;
    string showingStr2 = showingStr.Replace(",", commaBeforeSplit);
    item = item.Replace(showingStr, showingStr2);
}

// Replace By PF_XXX Style
string[] items2 = item.Split(Convert.ToChar(","));
items2[2] = items2[2].Replace(commaBeforeSplit, ",");   // 3rd Param Comma Again!

此れで、何とか、目的は達成 ... 。


いやぁ～、　文字列操作には　例外的処理 が付き物。
此れ等、ほんの一例に過ぎません。

世の常として、
汎用的を目指せば、特殊な例が紛れ込むケースが多く、難儀しますね。
事前に、　どの位の特殊例 を想定出来るかで、　出来が決まります。
検証例が多く多岐に亘る程、精度も上がる ... なのですね。
無論、其れだけ、頭を抱え悩む頻度も上がる訳ですが ... 。