Regex (-match, -replace, -cmatch, -creplace)

A dzsókerek nagyon praktikusak, de egy csomó mindenre nem jók. Például szeretnénk megvizsgálni, hogy egy szöveg e-mail cím formátumú-e? Vagy van-e a szövegben valahol egy webcím, vagy telefonszám? Mivel ilyen jellegű vizsgálatok nagyon gyakoriak a számítástechnikában, ezért erre külön „tudományág” alakult, matematikai alapját pedig a formális nyelvek képezik.

Az ilyen jellegű szövegminta vizsgálatok kifejezéseit hívják Regular Expression -nek, vagy röviden Regex -nek. Miután ez ténylegesen külön tudomány, Regular Expression kifejezésekről számtalan könyv látott napvilágot, ezért itt most nem vállalkozom arra, hogy még csak közelítő részletességgel tárgyaljam ezt a témát, de azért a főbb elveket és jelöléseket megpróbálom bemutatni.

Van-e benne vagy nincs?

Elsőként nézzünk a legegyszerűbb esetet, amikor egy szövegről el akarjuk dönteni, hogy van-e benne általunk keresett mintára hasonlító szövegrész:

A fenti két példa még nem igazán mutatja meg a regex erejét, akár a –like operátor is használható lett volna:

De vajon mit tennénk, ha a „napfény”-t nem tekintenénk a mintánkkal egyezőnek, csak az önálló „nap”-ot? Az önállóságot persze sokfajta karakter jelölheti: szóköz, pont, zárójel, stb. A regex-szel ez nagyon egyszerű, használni kell a „szóvég” jelölő „\b” karakterosztály szimbólumot a mintában:

 Azaz keresek egy olyan mintát, amely áll egy szóelválasztó karakterből, a „nap”-ból, és megint egy szóelválasztó karakterből.

Vagy keresem, hogy van-e a szövegben szám:

A \d a számjegy jelölője. Ezen jelölőknek van „negáltjuk” is, \B – a nem szóelválasztó karakter, \D – a nem számjegy.

Vagy keresem a Soós nevűeket, akik lehetnek „Sós”-ok is, de azért „Sooós” ne legyen:

A „?” 0 vagy 1 darabot jelöl az azt megelőző regex kifejezésből. A * bármennyi darabot jelent, akár 0-t is. A + legalább 1 darabot jelöl. Tetszőleges darabszámot jelölhetünk {min,max} formában, ahol a maximum akár el is hagyható.

Kereshetem az „s”-sel kezdődő, „s”-sel végződő háromkarakteres szavakat:

Alaphelyzetben a „.” minden karaktert helyettesít, kivéve a sortörést.

Egyszerűen vizsgálhatom, hogy van-e a szövegben ékezetes betű:

A [] zárójelpár közti betűk vagylagosan kerülnek vizsgálat alá, ezt is úgy hívjuk, hogy karakterosztály (meg a \d, \w, stb. kifejezéseket is). Ezzel karakter tartományokat is meg lehet jelölni:

Természetesen ezeket az alapelemeket kombinálni is lehet. Keresem a legfeljebb négyjegyű hexadecimális számot:

A fenti karakterosztályokban használhatunk negált változatot is. Például tartalmaz olyan karaktert, ami nem szóköz jellegű karakter:

A „nem szóköz”-nek van egyszerűbb jelölése is:

Ennek analógiájára van „nem szókarakter” - \W, „nem számjegy” - \D.

A szögletes zárójelek között csak karaktereket használhatok „vagylagos” értelemben. Ha azt akarom vizsgálni, hogy a szövegben vagy „PowerShell” vagy „PS” található, azt így vizsgálhatom:

Hogy egy kicsit trükkösebb legyen, nézzük az alábbi két példát:

A [42]-es sorban azért kaptunk hamis eredményt, mert kerestünk egy nem „a”, de nem is „b” karaktert, de az „ab”-ben csak ilyen van, így hamis eredményt kaptam. A [43]-as sorban kerestem egy vagy nem „a”, vagy nem „b” karaktert, márpedig az „ab” első „a”-jára igaz, hogy az nem „b”, tehát van találat!

További karakterosztályok

Láthattuk, hogy szögletes zárójelek között vizsgálhatunk többfajta karakter létét vagy hiányát a mintánkban. Ennek van még továbbfejlesztett módja is. Például tagadást másként is ki lehet fejezni:

Itt azt vizsgáltam, hogy a mintában van-e olyan karakter, ami „a” és „z” közötti, kivéve „h” és „i”. Ez itt igaz volt. Ellenben:

Ez már hamisra értékelődött. Ezt még mélyebb beágyazással is lehetne bonyolítani:

A fenti bonyolult kifejezést így kell értelmezni: vesszük a teljes angol abc-t, ebből kiszedem a „h” és „k” közötti karaktereket, majd „visszarakom” az „i” és „j” közöttieket.

További lehetőségeink vannak Unicode karakterek esetében, márpedig a PowerShell alaphelyzetben a szövegeket unicode-ként kezeli. Ez pedig a \p{tulajdonság} formátumú hivatkozás:

 Ezek vizsgálatához az alábbi kifejezést használtam:

A [83]-as sorban létrehoztam egy olyan sztringet, amelyik tartalmazza az összes alap karaktert, majd a [85]-ös sorban készítettem egy olyan regex kifejezést, ami használta ezt a tulajdonság-alapú mintát, és amely visszaadta az összes karaktert egy egyesített sztring formában, amely karakterek kielégítették a regex kifejezést. Látható, hogy a „\p{P}”-re az összes elválasztó karaktert kaptam vissza, a [86]-os sorban a „\p{Ll}” az összes kis betűt.

Van benne, de mi?

Az eddigiekben a –match operátorral arra kaptunk választ egy $true vagy $false formájában, hogy a keresett minta megtalálható-e a szövegünkben vagy sem. De egy bonyolultabb mintánál, ahol „vagy” feltételek vagy karakterosztályok is vannak, egy $true válasz esetében nem is tudjuk, hogy most mit is találtunk meg. Nézzük meg ezt a kettővel előző fejezet [43]-as sorának példája kapcsán:

Mint látható, a PowerShell automatikusan generál egy $matches  változót, amely tartalmazza, hogy mit is találtunk a –match operátor alkalmazása során. Jelen esetben megtalálhattuk volna a „b”-t is, hiszen arra is igaz, hogy „nem a”, de a –match operátor szigorúan balról jobbra halad, így először az „a” karakterre vizsgálja a mintát. Ha ott sikert ér el, akkor nem is halad tovább, megelégszik az eredménnyel és abbahagyja a keresgélést.

A $matches igazából nem is egy tömböt, hanem egy hashtáblát tartalmaz, amelynek 0-s kulccsal hivatkozható eleme a megtalált sztring. Nézzünk erre néhány példát:

Kerestük a kettőspontot és utána tetszőleges számú karaktert, illetve látható, hogy a $matches tényleg hashtábla.

A mohó regex

A –match mögött meghúzódó regex motor „mohó”, azaz ha rá bízzuk a mennyiségeket, akkor ő alapesetben annyit vesz belőle, amennyit csak tud a –match kielégítése mellett. Ez nem biztos, hogy nekünk mindig jó:

Mi történt itt? Ugye xTalálatx-re számítottunk, de „mohóság” miatt az első x megtalálása után a „.*” minta a szövegem végéig kielégíti a feltételt. Csak az utolsó karakter elérése után döbben rá a regex motor, hogy lemaradt az utolsó feltétel, a második x teljesítése, és ekkor kezd visszafele lépkedni, hogy hátha még ezt is tudja teljesíteni valahol. A visszafele lépkedés során eljut a harmadik x-ig, és ott áll meg. Mit lehetett volna tenni, hogy a kívánt találatot kapjuk meg? A regex „mohóságát” ki is lehet kapcsolni, ehhez egy „?”-et kell tenni az ilyen meghatározatlan számú többszörözők után. Ekkor csak a minimális darabszámot veszi a mintából, és ha az nem elég, akkor növeli azt:

Vagy pontosíthatjuk a „.*” mintát, hiszen ha például a két x között szókarakterek lehetnek csak, akkor pontosabb ez a minta:

Vagy ez is lehet megoldás:

Itt azzal tettem a regexet szerényebbé, hogy az x utáni „nem x” karaktereket keresem x-ig. Ez azért is jó, mert jóval hatékonyabb ennek az ellenőrzése, nincs felesleges ide-oda járkálás a mintában. Nagytömegű feldolgozásnál sokkal gyorsabban eredményre jutunk.

Escape a Regex-ben

Ezen utóbbi példáknál gondot jelenthet, ha az „x”-nél valami észszerűbb szeparátor szerepel a keresett szövegrészünk határaként. Ilyen elválasztó karakter szokott lenni mindenfajta zárójel, perjel, stb. Ezek a regexben is legtöbbször funkcióval bírnak, így ha rájuk keresünk, akkor „escape” karakterrel kell megelőzni ezeket. A regexben az „escape” karakter a visszafele-perjel (\), nem pedig a PowerShellben megszokott visszafele aposztróf (`)!

A fenti „x”-es példát cseréljük () zárójel-párra:

Tudjuk, hogy mi, de hol van?

Most már tudjuk, hogy van-e a mintánknak megfelelő szövegrészünk, azt is tudjuk, hogy mi az, csak azt nem tudjuk, hogy hol találta a –match. Ez főleg akkor érdekes, ha több találatunk is lehet.

Az alapműködést már megbeszéltük, a regex balról jobbra elemez:

Erről meg is győződhetünk, hiszen a fenti találat nagy „M”-mel kezdődik, az pedig a szövegünk legeleje.

A regex lehetőséget biztosít, hogy a szövegünk végén keressük a mintát:

Itt a találat kis „m” betűs lett, így ez tényleg a szövegem vége. Tehát a szöveg végét egy „$” jel szimbolizálja a mintában. Ez azonban nem jelent fordított működést, azaz itt is balról jobbra történik a kiértékelés. A „$” jelet úgy lehet felfogni, mintha az az eredeti szövegemben is ott lenne rejtett módon, és így a minta tényleg csak a sor végén illeszkedik a szövegre. Például a szöveg utolsó szava:

A szöveg elejére is lehet hivatkozni a „kalap” (^) jellel. Tehát az a „kalap” jel más funkciójú a szögletes [] zárójelek között (negálás), mint a „sima” regex mintában, ahol szöveg elejét jelenti:

Az előző példában csak a szöveg elején található számot tekintjük a mintával egyezőnek.

Most már tudjuk, hogy az elején vagy a végén találtuk-e a mintának megfelelő szöveget, de vajon egy köztes szöveget, például szóközök közti szöveget hogyan tudunk úgy megtalálni, hogy magát a szóközöket ne tartalmazza a találat? Erre - egyik megoldásként - alkalmazhatjuk a csoportosítást a mintában:

Itt a mintában található „(\.+?)” rész a gömbölyű zárójelek között egy „lusta” többszörözött (a ? lustítja el a + hatását) szókarakter al-minta a teljes minta részeként, más szóval csoport. A $matches[0] továbbra is a teljes találatot tartalmazza, de most már van egy $matches[1] is, ami az első találati csoport eredményét tartalmazza. Természetesen több csoportot is elkülöníthetünk, például számjegyek csoportjait:

A fenti példában egy telefonszámból választom ki külön az országkódot, a körzetszámot és a helyi számot. Természetesen egy ilyen mintát összerakni nem egyszerű segédeszköz nélkül. Erre használhatunk olyan eszközöket, mint például a 2.3.3 RegexBuddy fejezetben említésre kerülő eszköz:

45 . ábra Barátunk megint segít: értelmez és tesztel

Ez a segédprogram a mintánk különböző részeit színkódokkal jelzi, és a „Create” fülön részletes magyarázatot is kapunk az általunk beírt mintáról, észre tudjuk venni, hogy esetleg kifelejtettünk egy „escape” karaktert. A „Test” fülön meg ellenőrizni tudjuk, hogy megkapjuk-e találatként a helyes szöveget, illetve azt is, hogy a nem jó szöveg tényleg nem találat-e.

Ezeket a csoportokat nevesíthetjük is a jobb azonosíthatóság érdekében:

Tehát a csoportot jelző nyitó zárójel mögé tett „?” és „<>” kacsacsőrök közötti címkével tudjuk nevesíteni a csoportot. Itt nyer értelmet, hogy a $matches miért hashtábla, és miért nem egyszerű tömb.

Mi van akkor, ha egy csoportra nincs szükségünk? Erre használhatjuk a „(?:)”, un. „nem rögzülő” csoportot:

A fenti példában a kötőjelet nem rögzülő csoportba helyeztem, így az nem is szerepel külön találatként, de természetesen a teljes találatban ($matches[0]) benne van.

Természetesen a csoportokra is alkalmazhatjuk a „?” többszörözés-jelölőt, ami jelenti ugye a 0 vagy 1 darabot, azaz kezelhetjük azokat a telefonszámokat is, ahol nincs országkód és körzetszám:

Ilyenkor – a [42]-es példában látható módon – az egymásba ágyazott csoportok külön találatot adnak a listában, jelen esetben 1-es számmal. Nézzük, mi van akkor, ha nincs országkód és körzetszám:

Most térjünk át a –match egy nagy korlátjához: csak az első találatig keres. Bár az előző példában használtuk a „?”-et, más többszörözések nem úgy működnek, ahogy szeretnénk. Vegyünk egy olyan mintát, amellyel el szeretnénk különíteni a szavakat, kezdjünk egyszerűség kedvéért három szóval:

Meg is kaptuk a várt csoportokat. Vajon egyszerűsíthetjük-e ezt a kifejezést, egyszersmind felkészíthetjük-e a mintánkat változó számú szóra?

Már a fix számú vizsgálatot se tudtam elérni, a $matches nem jegyzi meg egy adott pozíciójú csoport korábbi értékeit. Itt csak a legutolsó szó, a „három” került bele a hashtáblába. Azaz hiába igaz az, hogy csak három szó egyidejű jelenléte teljesíti a feltételt, a végeredménybe csak az utolsó szó kerül bele. Ezt a problémát kicsit később oldom meg.

Tekintsünk előre és hátra a mintában

Egyelőre kanyarodjunk oda vissza, hogy a minta helyét valamilyen elválasztó karakter szabja meg. Ha magát a mintát nem akarjuk a találatban viszontlátni, akkor egyik megoldásként alkalmazhatjuk a csoportokat. Egy másik lehetőség a mintában az előretekintés és visszatekintés lehetősége. Például nézzük csak azokat a számokat, amelyek zárójelek között vannak:

Na, ez megint kezd kicsit hasonlítani az egyiptomi hieroglifákhoz. Nézzük meg, hogy hogyan vizualizálja ezt a RegexBuddy:

46 . ábra RegexBuddy értelmezi a mintát

A „(?<=xxx)” szerkezet „visszatekint”, azaz megvizsgálja, hogy az aktuális vizsgálati pozíció előtt az „xxx” minta megtalálható-e. Ha nem, akkor már meg is bukott a vizsgálat. A minta végén található „(?=xxx)” előretekint, azaz megvizsgálja, hogy az aktuális vizsgálati pozíció után az „xxx” minta megtalálható-e. Bár mindkét kitekintő minta zárójeles, de ahogy [87]-ben láthatjuk, nem adnak vissza találatot.

Ezen kitekintő mintáknak is van negatív változatuk, azaz pont azt keressük, hogy a mintánk előtt vagy után ne legyen valamilyen minta:

Hoppá! Ez nem is jó. Mit is szerettem volna? A „nem banán” gyümölcs árát szerettem volna kiszedni. Azonban a mintám teljesül már a banán áránál is a 2-es után, hiszen a „2” az nem „Banán:”. Azaz ebből az a tanulság, hogy igen gyakran, a negatív kitekintés mellé pozitívot is kell rakni, mert a nem egyezés az nagyon sokféleképpen teljesülhet. A mi esetünkben tehát a jó megoldás:

Azaz itt most a „pozitív” rész a „:” kettőspont megléte. Ez a két feltétel együttesen már kielégíti a keresési feladatot.

Nézzünk egy kicsit gyakorlatiasabb példát! Keresem egy ilyen (legacy exchange DN formátumú) szöveg utolsó ’cn=’ utáni részét:

„/o=Exchange Org/ou=First Administrative Group/cn=Recipients/cn=Valaki Vendel”

Megoldás:

A regex kifejezés úgy épül itt fel, hogy keresem az a bármilyen szöveget (legvégén levő .*), ami előtt úgy van cn= (?<=cn=), hogy mögötte már nincs bármennyi karakter után sem cn=, azaz (?!.*?cn=). Itt a negatív előretekintésnél lusta a bármennyi karakter, hogy hatékonyabb legyen a futás.

A mintám visszaköszön

Térjünk vissza a csoportokhoz! Hogyan lehetne felismerni azokat a szavakat, amelyek ugyanolyan elválasztó karakterek között vannak:

Azaz egy csoport eredményét már magában a mintában is felhasználhatom. A csoportra történő hivatkozás formátuma „\1”, „\2”, stb.

Természetesen nevesített csoportokra is lehet hivatkozni, ennek formája: „\k<név>”:

Változatok a keresésre

Az eddigi példákban azt láthattuk, hogy a –match operátor, hasonlóan a többi szöveges operátorhoz – nem kis-nagybetű érzékeny. De – mint ahogy a többinél is – ennek is van kis-nagybetű érzékeny változata is, a -cmatch :

Ha pont a nem egyezőséget akarjuk vizsgálni, arra a –notmatch  vagy a kis-nagybetű érzéketlen –cnotmatch  használható:

Természetesen a $true válasz ellenére itt a $matches nem ad találatot.

A –match még ezt is lehetővé teszi, hogy egy keresési mintán belül váltogassuk a különböző opciókat. Erre a speciális üzemmód jelölő ad lehetőséget:

A fenti táblázat fejlécében található jelzés egy kis magyarázatra szorul. A (?imnsx-imnsx) jelzés, a végén kettőspont nélkül jelzi, hogy ez az egész mintára vonatkozik. Természetesen nem használjuk egyszerre az össze opciót bekapcsolt és kikapcsolt módon. Például:

Ebben a példában az „i” és „m” opció be van kapcsolva, az „s” és az „x” meg ki van kapcsolva.

Ha egy mintán belül többfajta üzemmódot szeretnénk, akkor jön a kettőpontos változata ezen kapcsolók használatának:

A fenti példában csak az „M” betűre, mint részmintára vonatkozik a kis-nagybetű érzéketlenség kikapcsolása.

Nézzünk ezek használatára gyakorlati példákat!

Kikapcsoltam az érzéketlenséget, azaz kis-nagybetű érzékennyé tettem a vizsgálatot, és csak a nagybetűs minta esetében kaptam találatot.

Nézzük a többsoros szöveg vizsgálatának opcióit:

Létrehoztam egy kétsoros szöveget, keresem a sorvégi „sor” szót és egy számjegyet. A két sorvégnél a számmal teszek különbséget, hogy a találatból kiderüljön, hogy melyiket is találtuk meg. A [6]-os sorban nem szóltam a -match-nek, hogy lelkileg készüljön fel a többsoros szövegek vizsgálatára, így a sztringvég karakter csak a szöveg végére illeszkedik, így a találatunk a sor2 lett. Ha szólok neki, hogy a szövegem több soros, akkor az első sor vége is találatot ad. A „szólás” a (?m) többsoros üzemmód-kapcsolóval történt.

Nézzünk egy példát a nem nevesített csoportok eldobására:

A fenti példában látható, hogy amikor a [10]-es sorban bekapcsoltam az „n” kapcsolót, akkor külön csoportként nem szerepel az első, név nélküli csoport (de természetesen a teljes találat részét képezi), míg a kikapcsolt, alaphelyzet szerinti működés mellett (12]-es sor) az első, nevesítetlen csoport is létrejött.

Nézzük az egysoros kapcsolót. Kicsit zavaró a „többsoros”, „egysoros” elnevezés, hiszen ezek egymás mellett is megférnek, mert más metakarakter működését szabályozzák. Szóval nézzünk egy példát az egysoros üzemmódra:

A [14]-es sorban vizsgálom, hogy illeszkedik-e a kétsoros szövegem olyan mintára, amely egy „eleje” karaktersorozattal kezdődik, és egy „vége” karaktersorozattal végződik. Alapesetben nem kaptam találatot, hiszen a „.+” felakad a sor végén. Míg ha „kierőltetem” az egysoros értelmezést, ahogy az a [16]-os sorban tettem, akkor a „.+” keresztülgázol a sorvégkarakteren is és megkapom a találatomat.

Szóköz mintaként való alkalmazása:

Ebben a példában azt láthatjuk, hogy ha lusták vagyunk a szóköz \s-ként való mintában való hivatkozásához, akkor használhatjuk az igazi szóköz karaktert is, ha ezt az üzemmódot bekapcsoljuk. Lehetőség szerint ennek használatát azért kerüljük, mert sok regex változat nem ismeri ezt a lehetőséget, meg a minták olvashatósága sem biztos, hogy a legjobb lesz.

Tudjuk, hogy mi, de hányszor?

Az eddigi példákban azt tapasztaltuk, hogy a mintánkat az első találatig keresi a ‑match és változatai. Még a csoportok használatával is csak akkor tudjuk megkeresni a többszörös találatot, ha mi azt a mintát erre eleve felkészítjük, méghozzá meghatározott darabszámmal.

A PowerShell saját –match operátorával nem is tudunk többszörös találatot előcsiholni, de szerencsére van erre a cmdlet (lásd következő fejezetet), és – mint ahogy már többször láttuk – a .NET Framework ebben is segítségünkre van:

Itt most a [regex]  típusjelölővel hozok létre mintát. Nézzük meg ennek tagjellemzőit:

A metódusokat nézve mindent tud, amit eddig láttunk, de van egy sokat ígérő Matches() metódusunk is, ami többes számot sejtet (reméljük nem egyes szám harmadik személyt! J):

Egészen érdekes és sokat sejtető eredményt kaptunk. Nézzük meg a get-member cmdlettel, hogy ez mi:

Ez pont az, amit szerettünk volna: egy tömb, ami tartalmazza az összes találatot! Hogyan lehet ezt az eredményt kezelni? Például egy ciklussal kiírathatom az egyes találati elemeket:

Ahogy a [43]-as sor kimenetében láttuk, a [regex] objektumok rendelkeznek replace() metódussal is, de van split() is, amellyel a minta találati helyeinél lehet feltördelni a szöveget, amelyre alkalmazzuk. Nézzünk erre egy gondolatébresztő példát:

Ebben a példában feldaraboltam a szövegemet mindenféle szóelválasztó karakternél. Ugye ugyanezt az eredményt nem tudtam volna elérni a sztringek split() metódusával:

Regex opciók

Az előbb látott [regex] típusnak még egyéb képességei is vannak a –match operátorhoz képest. A legfontosabb az opciók használatának lehetősége, amelyeket az alábbi RegexOptions felsorolásban láthatunk:

Az ismerős ExplicitCapture, IgnoreCase, stb. mellett a RightToLeft lehet számunkra az igazi hasznos újdonság. Ennek alkalmazásához már a típus objektumának előállításánál van lehetőségünk az alábbiak szerint:

És innen már a szokásos módon használhatjuk a regex objektumot, az eredményben a találatok jobbról balra jönnek elő:

A ^ és a $ jelek jelentése nem változik, azaz:

A felnyíl továbbra is a minta bal oldali elejét, a dollár jobb oldali végét jelenti.

AND a regexben

Előfordulhat olyan eset is, amikor a mintámnak egyszerre két vagy több feltételnek is eleget kell tennie. Ilyen lehet például az, hogy a mintámban legyen számjegyet ÉS hogy az a számjegy nem kettő. Persze ez úgy is megfogalmazható lenne, hogy felsorolom az összes kettőn kívüli számjegyet, de ez egyrészt bonyolultabb, másrészt bizonyos esetekben nem is olyan egyszerű a felsorolás.

Hogyan lehet tehát ÉS feltételt készíteni? Az eddigi építőkövekből ezt meg lehet oldani egy sima minta és egy másik minta visszatekintésével:

Vagy ha az ÉS feltétel második tagja tagadó, akkor így:

Vegyük akkor a felvezetőben említett példát, keresem a számjegyet, ami nem 2:

Természetesen nem csak kéttagú lehet egy ilyen ÉS feltétel, hanem akármennyi, a visszatekintések számának növelésével.

IF-THEN-ELSE vizsgálat regexben

Nézzünk végül egy olyan szerkezetet, amellyel IF-THEN-ELSE jellegű vizsgálatokat tudunk végezni. Legyen a példánk az, hogy keresem a szavakat és a telefonszámokat. A telefonszám onnan ismerszik meg az egyszerűség kedvéért, hogy számjegyekből, kötőjelekből és szóközökből állhat, valamint előtte ott egy címke, hogy ’Telefon:’. Előfordulhat a szövegben más címke is, azok nem kellenek nekünk.

Azaz itt egy olyan regex kifejezés kell, ami így szól: ha a telefonszám előtt az áll, hogy ’Telefon:’, akkor jó az nekünk, egyébként a kettőspont nélküli szavakat keressük.

Szerencsére a regex tud ilyen IF-THEN-ELSE szerkezeteket is ilyen formában: (?(?=feltétel)akkor|egyébként). Azaz, ha teljesül a feltétel rész, akkor keresse az akkor részt, egyébként keresse az egyébként részt.

Nézzük mindezt a konkrét esetünkre:

Látható a fenti példákból, hogy tényleg működik ez a szerkezet.

Úgyhogy ezt mindig alaposan ellenőrizzük le.

Regex cmdlettel (Select-String)

A PowerShell 2.0-ban a több találatot is megjelenítő regex kifejezéseket már a Select-String  cmdlet is tudja! Nézzük, hogy hogyan:

Első ránézésre úgy néz ki, mintha egyszerűen csak kiválogatta volna azokat a sztringeket, amelyekben szerepel az „a” minta. De nézzük kicsit részletesebben az eredményt:

Látható, hogy a Matches tulajdonságban megtalálható egyelőre az első találat. Ha az összesre kíváncsiak vagyunk, akkor használjuk az –AllMatches kapcsolót:

Látható, hogy így már az első illeszkedést kielégítő sztringnél a Matches tulajdonságban minden egyező találat megtalálható. A Select-String közvetlenül tud szövegfájlokban is keresni, ezt a képességét majd a gyakorlati rész 2.6.7 Szövegfájlok beolvasása (Get-Content) fejezetben lesz szó.

Csere (-replace)

Sok esetben azért keresünk egy mintát, hogy az illeszkedő részeket kicseréljük valami másra. Ez a valami más akár lehet egy találati csoport is. Például cseréljük ellenkező sorrendűre egy IP címben szereplő számokat:

Látjuk, hogy itt a mintacsoportok résztalálataira $1, $2,... formában tudunk hivatkozni, az indexek nem nullától indulnak, hanem 1-től. A –replace-en kívül nem lehet hozzáférni a $1 és a többi változóhoz, és a –replace által végrehajtott illeszkedésvizsgálat eredménye sem olvasható ki, nem keletkezik $matches változó sem.

Nevesített csoportokat is használhatunk a cserében:

Azaz a ${csoportnév} szerkezettel lehet a nevesített csoportokra hivatkozni, itt is vigyázzunk az idézőjelezéssel!

A –replace szerencsére már alaphelyzetben a mintának megfelelő összes szövegrészt kicseréli:

Azonban ez nem rekurzív, azaz ha a csere után is marad cserélni való, akkor arra nekünk kell újra meghívni a –replace-t:

A fenti példában látszik, hogy a sok egymás melletti szóközt szeretném egyre cserélni azáltal, hogy kettőből csinálok egyet. A fenti módszerrel ez nem működik, hiszen csak egyszer szalad végig, a megoldásban még bőven marad több egymás melletti szóköz. Erre egy jobb minta alkalmazása a megoldás:

Mint ahogy a –match-nek is, a –replace-nek is van kis-nagybetű érzékeny változata, a –creplace :

A –replace még tud néhány érdekességet:

A $` szimbólum jelképezi a találatig terjedő szövegrészt.

A $' szimbólum jelképezi a találat utáni szövegrészt. Vigyázni kell, hogy itt a PowerShell idézőjel-kezelési szabályai miatt vagy macskakörmöt (”) használunk a jel körül, vagy duplázzuk az aposztrófot: '$'''.

 A $_ szimbólum a teljes mintát szimbolizálja. Itt megint ügyelni kell arra, hogy a PowerShellben a $_ változót szimbolizál, így a regex számára szó szerint ezt úgy tudjuk átadni, ha aposztrófot használunk.

A $+ szimbólummal a találatot szimbolizálhatjuk, így a fenti példában duplikálni tudtam a „kettő”-t.

Még egy dolog megjegyzendő a csere operátorával kapcsolatban, az, hogy ez már alaphelyzetben az összes keresett kifejezést megtalálja és cseréli:

Sőt! Nem csak hogy egy szövegen belül mindent megtalál, hanem rögtön gyűjtemény is átadható neki:

Csere .NET osztállyal

Ha még bonyolultabb cserére van szükségünk, akkor ki kell nyúljunk a [regex] .NET osztályhoz. Ennek a replace statikus metódusa kínál számunkra további lehetőségeket:

A fenti listából látható, hogy a 3-6 szintaxisokban a harmadik paraméter lehet egy „System.Text.RegularExpressions.MatchEvaluator evaluator” érték, ami PowerShellre lefordítva egy szkriptblokk. Ez a szkriptblokk írja le azt a szabályt, hogy mire is szeretnénk cserélni a talált mintáinkat. Ráadásul itt az $args[0].value segítségével hivatkozhatunk arra, amit éppen talált a keresés és ezzel egyéb műveleteket is végezhetünk.

Nézzük azt a példát, hogy a 0-tól különböző számokat szeretnénk eggyel növelni:

Mivel a mintának megfelelő szövegrészek mindig string adattípusok, így ezt egésszé kell alakítani mielőtt növelni tudom eggyel.

Word To HTML Converter