Reguliere expressies

De functies IsMatch, Match en MatchAll worden gebruikt om patronen in tekst te extraheren en valideren. Het patroon dat ze gebruiken wordt een reguliere expressie genoemd.

Reguliere expressies zijn krachtig en veelzijdig. Soms kunnen ze echter ook verschijnen als een willekeurige reeks leestekens. In dit artikel kunnen niet alle aspecten van reguliere expressies worden beschreven, maar er is online een schat aan informatie en zelfstudies en hulpmiddelen beschikbaar.

Reguliere expressies hebben een lange geschiedenis en zijn beschikbaar in veel programmeertalen. Elke programmeertaal heeft zijn eigen dialect van reguliere expressies en er zijn weinig standaarden. We streven ernaar om ervoor te zorgen dat dezelfde reguliere expressie in alle Power Fx-implementaties hetzelfde resultaat oplevert. Compatibiliteit is niet eenvoudig te realiseren omdat Power Fx op JavaScript en .NET wordt uitgevoerd, die beide aanzienlijke verschillen hebben. Om op verschillende platforms te kunnen werken, gebruiken reguliere Power Fx-expressies een subset van functies die breed worden ondersteund in de sector.

Hierdoor kunnen sommige reguliere expressies die in andere omgevingen wel werken, worden geblokkeerd of aanpassingen nodig hebben in Power Fx. Tijdens het schrijven worden fouten gerapporteerd wanneer er niet-ondersteunde functies worden aangetroffen. Daarom moeten de reguliere expressie en de opties een constante zijn tijdens het schrijven en niet dynamisch, maar worden ze niet in een variabele opgegeven.

Ondersteunde functies

Power Fx ondersteunt de volgende reguliere expressiefuncties, met opmerkingen over hoe Power Fx-gedrag kan afwijken van dat van andere systemen.

De reguliere expressie moet constant zijn en mag niet worden berekend of opgeslagen in een variabele. De operator &, tekenreeksinterpolatie $"{...}" en de functies Concatenate, Char en UniChar met constante argumenten worden ondersteund.

Letterlijke tekens

Gebruik in plaats daarvan \x of \u. Octale codes voor tekens, zoals \044 of \o{044} , zijn niet toegestaan, omdat ze dubbelzinnig kunnen zijn bij genummerde terugverwijzingen.

\v wordt niet ondersteund omdat het dubbelzinnig is in verschillende reguliere expressietalen. Gebruik \x0b voor een verticaal tabblad of [\x0b\f\r\n\x85\u2028\u2029] voor verticale witruimte.

Asserties

Asserties komen overeen met een bepaalde positie in de tekst, maar verbruiken geen tekens.

$ komt overeen met het einde van een regel, inclusief eventuele afsluitende \r\n\r of \n.

Vooruitblik- en terugblikasserties kunnen geen submatches of onbeperkte kwantificatoren bevatten en kunnen niet worden gebruikt met een kwantificator erbuiten.

Tekenklassen

Om de duidelijkheid te vergroten en dubbelzinnigheid te voorkomen, zijn tekenklassen met vierkante haken restrictiever dan in andere reguliere expressietalen:

• Letterlijke koppeltekens moeten van een escape-teken worden voorzien. Gebruik [\-a] in plaats van [-a] om overeen te komen met - of a.
• Vierkante beginhaken moeten van een escape-teken worden voorzien. Gebruik [\[a] in plaats van [[] om overeen te komen met [ of a.
• Tenzij het het eerste teken is en ontkenning aangeeft, moet een escape-teken worden toegevoegd. Gebruik [a\^] in plaats van [a^] om overeen te komen met ^ of a.
• Accolades moeten van een escape-teken worden voorzien. Gebruik [\{\}] om overeen te komen met { of }.
• Lege tekenklasse [] wordt niet ondersteund. Als u een afsluitende vierkante haak in een tekenklasse wilt opnemen, moet u een escape-teken toevoegen.

Unicode-tekencategorieën ondersteund door \p{} en \P{}:

• Letters: L, Lu, Ll, Lt, Lm, Lo
• Markeringen: M, Mn, Mc, Me
• Getallen: N, Nd, Nl, No
• Leestekens: P, Pc, Pd, Ps, Pe, Pi, Pf, Po
• Symbolen: S, Sm, Sc, Sk, So
• Scheidingstekens: Z, Zs, Zl, Zp
• Besturing en opmaak: Cc, Cf, terwijl andere C voorvoegselcategorieën niet worden ondersteund.

\W, \D, \S en \P{} kunnen niet worden gebruikt binnen een negatief gemaakte tekenklasse [^...]. Om ze op bepaalde platforms te kunnen implementeren, worden deze negatieve tekenklassen vertaald naar hun Unicode-equivalenten. Dit kan lastig zijn als ze ook worden genegeerd.

Unicode-tekens tussen U+10000 en U+10FFFF, waarvoor surrogaatparen nodig zijn, worden niet ondersteund in tekenklassen.

Kwantificatoren

Bezittelijke kwantificatoren worden niet ondersteund.

Het mengen van submatches en kwantificatoren kent beperkingen. Zie Mogelijk lege submatches voor meer informatie.

Groups

Benoemde en genummerde submatches kunnen niet samen worden gebruikt. Standaard zijn benoemde submatches ingeschakeld en krijgen ze de voorkeur vanwege de duidelijkheid en onderhoudbaarheid, terwijl standaard vastleggingsgroepen groepen zonder vastlegging worden met betere prestaties. Dit gedrag kan worden gewijzigd met MatchOptions.NumberedSubMatches, dat traditionele vastleggingsgroepen biedt, maar benoemde vastleggingsgroepen uitschakelt. Sommige implementaties behandelen een combinatie van genummerde en benoemde vastleggingsgroepen anders en daarom is dit niet toegestaan in Power Fx.

Zelfverwijzende vastleggingsgroepen worden niet ondersteund, bijvoorbeeld de reguliere expressie (a\1).

Twee vastleggingsgroepen kunnen niet dezelfde naam hebben. De reguliere expressie (?<id>\w+)|(?<id>\d+) wordt bijvoorbeeld niet ondersteund.

De naam van een benoemde submatch moet beginnen met een \p{L}-teken of _ en kan doorgaan met die tekens plus \p{Nd}. Namen zijn beperkt in lengte tot 62 UTF-16-code-eenheden.

Terugverwijzingen naar mogelijk lege submatches en naar submatches binnen een terugblik of vooruitblik worden ook niet ondersteund.

Sommige implementaties bieden een optie voor "expliciete vastlegging" om de prestaties te verbeteren, maar dit is niet nodig in Power Fx omdat dit de standaardinstelling is. MatchOptions.NumberedSubMatches schakelt het uit en schakelt impliciet genummerde vastleggingen in.

Het mengen van submatches en kwantificatoren kent beperkingen. Zie Mogelijk lege submatches voor meer informatie.

Opmerkingen

Zie MatchOptions.FreeSpacing voor een alternatief voor het opmaken en van commentaar voorzien van reguliere expressies.

Inline-opties

Ondersteunde inline-modi zijn [imsx]. Deze komen overeen met respectievelijk MatchOptions.IgnoreCase, MatchOptions.Multiline, MatchOptions.DotAll en MatchOptions.FreeSpacing. n wordt ook geaccepteerd vanwege compatibiliteit, maar heeft geen effect omdat het de standaard is en niet compatibel is met MatchOptions.NumberedSubMatches.

Inline-opties kunnen niet worden gebruikt om een optie uit te schakelen of een optie in te stellen voor een subexpressie.

Opties

Overeenkomstopties wijzigen het gedrag van het vergelijken van reguliere expressies. Er zijn twee manieren om opties in te schakelen. Deze kunt u combineren, zolang er maar geen conflict ontstaat:

• MatchOptions-enumwaarde doorgegeven als derde argument aan Match, MatchAll en IsMatch. Opties kunnen worden gecombineerd met de operator & of functie Concatenate, bijvoorbeeld MatchOptions.DotAll & MatchOptions.FreeSpacing. Voor alle reguliere expressiefuncties geldt als vereiste dat MatchOptions een constante waarde is. Deze kan niet worden berekend of opgeslagen in een variabele.
• (?...) prefix aan het begin van de reguliere expressie. Opties kunnen worden gecombineerd met meerdere letters in de constructie (?...), bijvoorbeeld (?sx). Voor sommige opties is er geen (?...)-equivalent, maar zijn er andere manieren om hetzelfde effect te bereiken. Zo is MatchOptions.BeginsWith het equivalent van ^ aan het begin van de reguliere expressie.

Bevat

Ingeschakeld met MatchOptions.Contains zonder reguliere expressie als tekstequivalent. MatchOptions.Contains is de standaard voor alle functies buiten Power Apps. Binnen Power Apps is MatchOptions.Complete de standaard voor IsMatch.

Voltooien

Ingeschakeld met MatchOptions.Complete of gebruik respectievelijk ^ en $ aan het begin van de reguliere expressie.

BeginsWith

Ingeschakeld met MatchOptions.BeginsWith of gebruik ^ aan het begin van de reguliere expressie.

EndsWith

Ingeschakeld met MatchOptions.EndsWith of gebruik $ aan het einde van de reguliere expressie.

DotAll

Ingeschakeld met MatchOptions.DotAll of (?s) aan het begin van de reguliere expressie.

Normaal gesproken komt de puntoperator . overeen met alle tekens behalve tekens voor nieuwe regel [\n\x0b\f\r\x85\u2028\u2029]. Met de modificator DotAll worden alle tekens gematcht, inclusief tekens voor nieuwe regel.

In dit voorbeeld komt alleen "Hallo" overeen, omdat de . standaard niet overeenkomt met de nieuwe regel:

Trim( Match( "Hello
              World", ".*" ).FullMatch )
// returns 
// "Hello"

Maar als we de modificator DotAll toevoegen, worden de nieuwe regel en alle daaropvolgende tekens gematcht:

Trim( Match( "Hello
              World", ".*", MatchOptions.DotAll ).FullMatch )
// returns 
// "Hello
// World"

FreeSpacing

Ingeschakeld met MatchOptions.FreeSpacing of (?x) aan het begin van een reguliere expressie.

Dankzij de vrije ruimte kunt u een complexe reguliere expressie gemakkelijker lezen en onderhouden. De regels zijn eenvoudig:

• Spaties worden in de reguliere expressie genegeerd, inclusief alle tekens die overeenkomen met \s. Als u een spatie wilt matchen, gebruikt u \s, \ , \t, \r of \n.
• # begint een commentaar dat doorloopt tot het einde van de regel. Dit en alle tekens die volgen op het volgende teken voor nieuwe regel (tekens die niet overeenkomen met . zonder MatchOptions.DotAll) worden genegeerd.
• Tekenklassen vallen niet onder deze wijzigingen. Spaties en # vertonen het gebruikelijke gedrag. Zo retourneert IsMatch( "a#b c", "(?x)a[ #]b[ #]c" ) bijvoorbeeld de waarde true. Sommige reguliere expressietalen nemen tekenklassen op in vrije ruimte of bieden een optie om ze op te nemen, maar Power Fx doet dat niet.

Hier is bijvoorbeeld een complexe reguliere expressie voor het matchen van een ISO 8601 datum/tijd:

IsMatch( 
    "2025-01-17T19:38:49+0000",
    "^\d{4}-(0\d|1[012])-([012]\d|3[01])(T([01]\d|2[0123]):[0-5]\d(:[0-5]\d(\.\d{3})?)?(Z|[\-+]\d{4}))?$"
)
// returns true

En hier is de identieke reguliere expressie met vrije ruimte en gebruik van meerdere regels, inspringing voor groepen en opmerkingen bij de reguliere expressie. Hierdoor is deze versie gemakkelijker te begrijpen, valideren en onderhouden.

IsMatch( "2025-01-17T19:38:49+0000", 
    "(?x)                 # enables free spacing, must be very first
    ^                     # matches from beginning of text
    \d{4}                 # year (0000-9999)
    -(0\d|1[012])         # month (00-12)
    -([012]\d|3[01])      # day (00-31, range not checked against month)
    (T([01]\d|2[0123])    # optional time, starting with hours (00-23)
      :[0-5]\d            # minutes (00-59)
      (:[0-5]\d           # optional seconds (00-59)
        (\.\d{3})?        # optional milliseconds (000-999)
      )?
      (Z|[\-+]\d{4})      # time zone
    )?
    $                     # matches to end of text
    "
)
// returns true

IgnoreCase

Ingeschakeld met MatchOptions.IgnoreCase of (?i) aan het begin van een reguliere expressie.

Komt overeen met tekst in een letter die niet hoofdlettergevoelig is: hoofdletters komen overeen met kleine letters en kleine letters komen overeen met hoofdletters.

Bijvoorbeeld:

IsMatch( "HELLO!", "hello", MatchOptions.IgnoreCase )
// returns true

IsMatch( "file://c:/temp/info.txt", "^FILE://", MatchOptions.IgnoreCase )
// returns true

De meeste delen van Power Fx zijn cultuurbewust, maar hier niet. Het gebruik van cultuuronafhankelijke matching is de industriestandaard voor reguliere expressies, ook in JavaScript en Perl. Het is handig in het tweede voorbeeld, waarbij een systeembron moet worden gekoppeld, bijvoorbeeld in de tr-TR-cultuur waar I niet het hoofdletterequivalent is van i.

Als er een cultuurbewuste, hoofdletterongevoelige match nodig is, gebruikt u in plaats daarvan de tekenklasse met overeenkomende tekens, zoals [Hh][Ee][Ll][Ll][Oo] voor het eerste voorbeeld.

Meerdere regels

Ingeschakeld met MatchOptions.Multiline of (?m) aan het begin van een reguliere expressie.

Normaal gesproken komen ankers ^ en $ overeen met het begin en einde van de invoertekst. Met de modificator Multiline komen deze ankers overeen met het begin en einde van regels in de invoertekst, waarbij elke regel eindigt met \r, \n, \r\n of het einde van de invoer. Bijvoorbeeld:

MatchAll( "Hello" & Char(13) & Char(10) & "World", "^.+$" )
// returns 
// "Hello"

Vooraf gedefinieerde patronen

Met vooraf gedefinieerde patronen kunt u een reeks tekens of een opeenvolging van meerdere tekens matchen. Gebruik de operator voor het samenvoegen van tekenreeksen & om uw eigen teksttekenreeksen te combineren met leden van de vaste-tekstwaarden voor Match:

Het patroon "A" & Match.MultipleDigits zal bijvoorbeeld overeenkomen met de letter "A", gevolgd door een of meer cijfers.

Het patroon Match.Email is complexer dan de rest. Het detecteert en extraheert veelvoorkomende e-mailadressen in de vorm local@hostname.tld, mogelijk uit lange tekstfragmenten, en ondersteunt internationale tekens en emoji's. U kunt het gebruiken om een formulier te valideren dat een e-mailadres als invoer gebruikt, als een snelle test om te controleren of de invoer zich in een e-mailformulier bevindt. Als u niet extraheert, gebruikt u MatchOptions.Complete om een e-mailadres te detecteren, bijvoorbeeld in een besturingselement voor tekstinvoer.

Match.Email valideert echter niet dat het e-mailadres voldoet aan de vele veranderende standaarden voor e-mailadressen, domeinnamen en domeinen op het hoogste niveau. Hiervoor is een ingewikkelde reguliere expressie nodig die van tijd tot tijd moet worden bijgewerkt. Hoewel de meeste e-mailadressen worden behandeld zoals verwacht, komt Match.Email overeen met enkele ongeldige gevallen, zoals een onderstrepingsteken in de hostnaam, en komt het niet overeen met enkele geldige gevallen, zoals e-mailadressen of IP-adressen tussen aanhalingstekens. Er zijn, indien nodig, veel reguliere expressies op het web te vinden waarmee u een echt legaal e-mailadres kunt detecteren. Test uw reguliere expressie altijd op uw specifieke behoeften voordat u deze in productie gebruikt.

Als u wilt zien welke reguliere expressie wordt gebruikt, evalueert u de formule Text( Match.Email ). Het eerste deel komt overeen met de tekens vóór de @ en sluit de algemene ASCII-interpunctie uit volgens RFC 822 en revisies en Unicode-begin- en eindinterpunctie voor eenvoudigere extractie, zoals (, [, “, « en 「. Het biedt geen ondersteuning voor het ongebruikelijke en afgeraden gebruik van aanhalingstekens of opmerkingen. Na @ zijn het tweede en derde deel van de reguliere expressie hetzelfde en worden ze gescheiden door een .. Hierdoor staat er altijd minstens één . in het adres. Deze onderdelen sluiten alle Unicode-interpunctie uit, behalve ., - en _. IP-adressen worden niet ondersteund. In het gehele e-mailadres worden internationale tekens en emoji's ondersteund.

Als in Power Apps geen gebruik wordt gemaakt van Power Fx 1.0, hebben Match.Email en Match.Hyphen enigszins verschillende definities. Match.Email is eenvoudiger, maar is niet geschikt voor het extraheren van een e-mailadres omdat hiermee spaties worden vastgelegd. Voorheen kon buiten een tekenklasse een escape-teken worden gebruikt voor Match.Hyphen, wat nu illegaal is.

NumberedSubMatches

Ingeschakeld met MatchOptions.NumberedSubMatches zonder inline-optie. (?n) wordt ondersteund als tegenhanger van deze optie voor compatibiliteit en is de standaard.

Standaard legt (...) geen gegevens vast, het equivalent van wat de meeste systemen "expliciete vastlegging" noemen. Om vast te leggen, gebruikt u een benoemde vastlegging met (?<name>...) met terugverwijzing \k<name>. Het gebruik van benoemde vastleggingen verbetert de prestaties doordat groepen die niet nodig zijn niet worden vastgelegd, de duidelijkheid wordt verbeterd door het gebruik van namen en er minder kans is op fouten als de positie van vastleggingen verandert.

Als u over een bestaande reguliere expressie beschikt, is het mogelijk dat groepen automatisch moeten worden vastgelegd en genummerd, inclusief genummerde terugverwijzingen. Dit gedrag is beschikbaar via de optie MatchOptions.NumberedSubMatches.

Benoemde en genummerde submatches kunnen niet samen worden gebruikt. Aangezien sommige implementaties een combinatie van genummerde en benoemde vastleggingsgroepen anders behandelen, is dit niet toegestaan in Power Fx.

Mogelijk lege submatches

Zoals in de inleiding vermeld, zijn de reguliere expressies van Power Fx opzettelijk beperkt tot functies die consistent kunnen worden geïmplementeerd in .NET, JavaScript en andere engines voor reguliere expressies van programmeertalen. Fouten tijdens het ontwerpen verhinderen het gebruik van functies die geen deel uitmaken van deze set.

Eén gebied dat kan verschillen tussen implementaties is de manier waarop lege submatches worden verwerkt. Denk bijvoorbeeld aan de reguliere expressie (?<submatch>a*)+ die moet matchen met de tekst a. In .NET resulteert de submatch in een lege tekstreeks, terwijl deze in JavaScript resulteert in a. Beide kunnen als correcte implementaties worden beschouwd, aangezien de kwantificator + mogelijk tevreden is met een lege tekenreeks aangezien de inhoud van de groep een kwantificator * heeft.

Om te voorkomen dat er verschillende resultaten ontstaan in verschillende Power Fx-implementaties, kunnen submatches die mogelijk leeg zijn, niet worden gebruikt met een kwantificator. Hier volgen enkele voorbeelden van hoe een submatch leeg kan zijn:

De submatch in (?<submatch>a+)+ kan niet leeg zijn omdat minimaal één a in de submatch moet zijn opgenomen. Dit wordt ondersteund.

Unicode

Reguliere Power Fx-expressies gebruiken Unicode-categorieën om \w, \d en \s te definiëren, waarbij specifieke categorieën beschikbaar zijn via \p{..}.

Deze definities kunnen per platform verschillen. De Unicode-standaard wordt bijvoorbeeld van tijd tot tijd bijgewerkt met nieuwe tekens, die later op elk platform in hun eigen tempo worden geïmplementeerd. Houd er rekening mee dat de resultaten per platform kunnen variëren totdat alle platforms zijn bijgewerkt.

Reguliere Power Fx-expressies zorgen ervoor dat categorie-informatie altijd beschikbaar is voor het Basic Multilingual Plane (tekens U+0 tot en met U+ffff). Sommige platforms implementeren geen categorieën voor tekens in het Supplementary Multilingual Plane en hoger (U+10000 tot en met U+10ffff). Deze beperking is doorgaans geen probleem, aangezien tekens in het Basic Multilingual Plane het meest worden gebruikt. Gebruik rechtstreeks tekenwaarden in plaats van categorieën als uw scenario tekens van U+10000 of hoger bevat. Test uw reguliere expressies op de platforms die u wilt gebruiken.

Er kunnen kleine verschillen in randgevallen bestaan tussen platforms. Sommige platforms zien bijvoorbeeld ſ niet als overeenkomend met s wanneer MatchOptions.IgnoreCase wordt aangeroepen. Als deze tekens belangrijk zijn voor uw scenario, gebruikt u een tekenklasse zoals [ſsS] om hoofdlettergevoelig te matchen en de gewenste tekens expliciet op te nemen.