我有一系列不同複雜程度的文件名。基本上,它們總是被[_] {ASSET} _ [OPTIONAL_DESCRIPTION] _v {######}。{EXT}分割。 ([]在這種情況下是可選的)。在這種格式下,每件作品都可以任意複雜。 (領先_s是任意)正則表達式匹配一個或多個組太多
character_thing_v001.md
character_Description_v001.md
character_Some_Long_Description_v001.md
character_thing_with_additional_info_v001.md
character_thing_with_additional_info_Description_v001.md
character_thing_with_additional_info_More_Description_Info_v001.md
character_with_additional_info_Complete234ly_arbitrary_Description_v001.md
_character_thing_v001.md
___character_Description_v001.md
____character_Some_Long_Description_v001.md
__character_thing_with_additional_info_v001.md
__character_thing_with_additional_info_Description_v001.md
___character_thing_with_additional_info_More_Description_Info_v001.md
我做了一個預測先行斷言,以單獨的資產和說明,一切運行良好,直到最近,當我的老闆在系統中扔扳手。現在我必須支持其慣例可能是「some_undercase」或「CAPS _ ###」的資產。我修改爲允許A-Z並使descriptionText與任何內容匹配。這是混亂開始的地方。
(?:[_]+)?
(?P<assetText>[a-zA-Z0-9]+
(?=_[a-zA-Z0-9]+)? # lookahead and optionally assert _Capital
(?:(?:_[a-zA-Z0-9]+)+)? # match next group if it exists
) # get full match
(?:[_]+)?
\_(?P<descriptionText>.+)?
\_v(?P<versionIncrement>\d+)
\.(?:\.)?
(?P<extension>(?:md|some|other|extension|options))
這讓我的存在方式的一部分,但它有問題,你可以查看,here
現在,該資產能夠有資金,先行匹配太多資產,並且開始進入的描述。這種模式是自動生成的幾個模式之一,所以我正在尋找一種解決問題根源的方法,而不是寫在問題的根源上。任何指導將非常感激,謝謝。
我會澄清和修改原來的職位。資產始終是under_case(例如:character_thing)或(現在)CAPS _ ###(例如:DOLL_101),說明是Capital_Case。所以僅僅獲得一場比賽是不夠的。每個部分必須以正確的點開始和結束。例如,用你的正則表達式,「character_thing_with_additional_info_More_Description_Info_v001.md 」的資產是「字符」,描述是「thing_with_additional_info_More_Description_Info」,而我正在尋找資產爲「character_thing_with_additional_info」,描述爲「More_Description_Info」 – ColinKennedy
因此要回答你的問題第二,是的,我同意,這個公約是不明確的。但我認爲它基本上是「資產不足,在這種情況下,資產和描述之間的分割是第一個資本,除非它們是CAPS _ ###,在這種情況下,資產和描述之間的分割在數字之後,而不是第一個資本在描述中「。 – ColinKennedy
好的,我已在'assetText'行添加了一個子表達式。我認爲它現在可以完成你想要的工作 – jez