Vanlige uttrykk

Funksjonene IsMatch , Match og MatchAll brukes til å trekke ut og validere mønstre i tekst. Mønsteret de bruker kalles et regulært uttrykk.

Regulære uttrykk er kraftige og allsidige. Imidlertid kan de noen ganger vises som en tilfeldig sekvens av skilletegn. Denne artikkelen beskriver ikke alle aspekter ved regulære uttrykk, men et vell av informasjon, opplæringer og verktøy er tilgjengelig på nettet.

Regulære uttrykk har en lang historie og er tilgjengelige på mange programmeringsspråk. Hvert programmeringsspråk har sin egen dialekt av regulære uttrykk, og det er få standarder. Så mye som mulig streber vi etter at det samme regulære uttrykket skal gi samme resultat på tvers av alle Power Fx implementeringer. Kompatibilitet er ikke lett å oppnå da Power Fx kjører på toppen av JavaScript og .NET som har betydelige forskjeller. For å kjøre på forskjellige plattformer Power Fx bruker regulære uttrykk et delsett av funksjoner som støttes bredt i hele bransjen.

Som et resultat kan noen regulære uttrykk som fungerer i andre miljøer, være blokkert eller trenge justeringer i Power Fx. Redigeringstidsfeil rapporteres etter hvert som det oppstår funksjoner som ikke støttes. Dette er grunnen til at det regulære uttrykket og alternativene må være en redigeringstidskonstant og ikke dynamisk, for eksempel angitt i en variabel.

Notat

Power Apps Bruker en tidligere versjon av Power Fx regulære uttrykk, som har færre begrensninger, men også færre funksjoner. MatchOptions.DotAll og MatchOptions.FreeSpacing er ikke tilgjengelige, og definisjonene av Match.Email og Match.Hyphen er forskjellige. Unicode-surrogatpar behandles ikke som ett enkelt tegn. MatchOptions.NumberedSubMatches er standard. Versjonen av regulære uttrykk som er beskrevet her, er snart tilgjengelig Power Apps under en "Power Fx V1.0-kompatibilitet"-bryter.

Støttede funksjoner

Power Fx Støtter følgende funksjoner for regulære uttrykk, med merknader om hvordan Power Fx virkemåten kan avvike fra andre systemer.

Det regulære uttrykket må være konstant og ikke beregnet eller lagret i en variabel. Operatoren & , strenginterpolasjonen $"{...}" og funksjonene, ConcatenateChar, og UniChar med konstante argumenter støttes.

Litterale tegn

Funksjon	Description
Litterale tegn	Alle Unicode-tegn kan settes inn direkte, bortsett fra \, [, ], ^, $.|?*+(){ og. } Når du bruker MatchOptions.FreeSpacing, #, , og andre \s mellomromstegn må escapes fordi de har en annen betydning.
Ekskluderte litterale tegn	\ (omvendt skråstrek) etterfulgt av et av de direkte litterale tegnene, for eksempel \? å sette inn et spørsmålstegn. \# og \ kan også brukes selv når MatchOptions.FreeSpacing er deaktivert for konsistens.
Heksadesimale og Unicode-tegnkoder	\x20 med nøyaktig to heksadesimale sifre, \u2028 med nøyaktig fire heksadesimale sifre og kan brukes til høye og lave surrogater.
Unicode-kodepunkt	\u{01F47B} med opptil åtte heksadesimale sifre. Må være i området 0 til U+10FFFF og kan ikke brukes for verken et høyt eller lavt surrogat. Kan resultere i et surrogatpar (to tegn) hvis det er større enn U+FFFF.
Linjeskift	\r, det samme som Char(13).
Ny linje-karakter	\n, det samme som Char(10).
Skjema feed	\f, det samme som Char(12).
Horisontal fane	\t, det samme som Char(9).

Bruk \x eller \u i stedet. Oktale koder for tegn, for eksempel \044 eller \o{044} er ikke tillatt, fordi de kan være tvetydige med nummererte tilbakereferanser.

\v støttes ikke fordi det er tvetydig på tvers av regulære uttrykksspråk. Bruk \x0b for en loddrett fane eller [\x0b\f\r\n\x85\u2028\u2029] for loddrette mellomrom.

Påstander

Deklarasjoner samsvarer med en bestemt posisjon i teksten, men bruker ingen tegn.

Funksjon	Description
Start av kø	^, samsvarer med begynnelsen av teksten, eller av en linje hvis MatchOptions.Multiline brukes.
Slutten av linjen	$, samsvarer med slutten av teksten, eller på en linje hvis MatchOptions.Multiline brukes.
Se fremover	(?=a) og (?!a) matcher fremover for et mønster.
Se bak	(?<=b) og (?<!b) fyrstikker bak for et mønster.
Ordskift	\b og \B ved å bruke Unicode-definisjonen av bokstaver [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}\p{Lm}].

$ samsvarer med slutten av en linje, inkludert eventuelle etterfølgende \r\n, \r, eller \n.

Lookahead- og lookbehind-deklarasjoner kan ikke inneholde undertreff eller ubegrensede kvantifieringer innenfor, og kan ikke brukes med en kvantifier utenfor.

Karakterklasser

Funksjon	Description
Punkt	., samsvarer med alt unntatt \r og \n med mindre MatchOptions.DotAll brukes.
Karakter klasse	[abc] Liste over tegn, [a-fA-f0-9] utvalg av tegn, [^a-z] alt unntatt disse tegnene. Tegnklasser kan ikke nestes, trekkes fra eller krysses, og mange skilletegn vises kanskje ikke to ganger på rad (@@, %%, !!, osv.).
Word-tegn	\w og \W ved å bruke Unicode-definisjonen av bokstaver [\p{Ll}\p{Lu}\p{Lt}\p{Lo}\p{Nd}\p{Pc}\p{Lm}]. \W Kan ikke brukes i en negativ tegnklasse.
Siffertegn	\d inkluderer sifrene 0 til9 og \p{Nd}, \D samsvarer med alt unntatt tegn som samsvarer med \d. \D Kan ikke brukes i en negativ tegnklasse.
Mellomrom tegn	\s inkluderer avstandstegn [ \t\n\x0b\f\r\x85\u2028\u2029\p{Z}], \S som samsvarer med alt unntatt tegn som samsvarer med \s. \S Kan ikke brukes i en negativ tegnklasse.
Unicode-tegnkategori	\p{Ll} samsvarer med alle små Unicode-bokstaver, mens \P{Ll} de matcher alt som ikke er en liten Unicode-bokstav. \P{} Kan ikke brukes i en negativ tegnklasse.

For å øke klarheten og unngå tvetydighet er tegnklasser med hakeparenteser mer restriktive enn i andre språk med regulære uttrykk:

• Bokstavelige bindestrektegn må escapes. Bruk [\-a] i stedet [-a] for å matche - eller a.
• Begynnende hakeparenteser må escapes. Bruk [\[a] i stedet [[] for å matche [ eller a.
• Med mindre det er det første tegnet og indikerer negasjon, må tegnet escapes. Bruk [a\^] i stedet [a^] for å matche ^ eller a.
• Krøllete tannregulering må unnslippes. Brukes [\{\}] til å matche { eller }.
• Tom tegnklasse [] støttes ikke. Hvis du vil inkludere en avsluttende hakeparentes i en tegnklasse, slipper du den.

Unicode-tegnkategorier som støttes av \p{} og \P{}:

• Bokstaver: L, Lu,, Ll, Lt, LmLo
• Merker: M, Mn,, McMe
• Tall: N, Nd,, NlNo
• Tegnsetting: P, Pc,, Pd, Ps, Pe, Pi,, PfPo
• Symboler: S, Sm,, Sc, SkSo
• Skilletegn: Z, Zs,, ZlZp
• Kontroll og Format: Cc,, Cf mens andre C prefikskategorier ikke støttes.

\W, \D,, og \Skan ikke brukes i en negert tegnklasse \P{}[^...]. For å bli implementert på noen plattformer, blir disse negative tegnklassene oversatt til deres Unicode-ekvivalenter, noe som kan være vanskelig å gjøre hvis de også.

Unicode-tegn mellom U+10000 og U+10FFFF, som krever surrogatpar, støttes ikke i tegnklasser.

Kvantifiseringer

Funksjon	Description
Grådige null eller en	? matcher null eller én gang, med så stor kamp som mulig.
Grådige null eller mer	* Matcher null eller flere ganger, med så stort treff som mulig.
Grådige en eller flere	+ kamper en eller flere ganger, med så stor kamp som mulig.
Grådige i det minste n	{n,} kamper minst n ganger, med så stor kamp som mulig. For eksempel,samsvarer a{3,} med alle tegnene i aaaaa.
Grådighet mellom n og m	{n,m} Kamper mellom n og m ganger, med så stort treff som mulig. Samsvarer for eksempel a{1,3} med de tre første tegnene i aaaaa.
Lazy zero eller en	?? matcher null eller én gang, med så lite treff som mulig.
Lazy zero eller mer	*? matcher null eller flere ganger, med så lite treff som mulig.
Lat en eller flere	+? kamper én eller flere ganger, med så lite treff som mulig.
Lat i det minste n	{n,}? kamper minst n ganger, med så lite treff som mulig. Samsvarer for eksempel a{3,}? bare med de tre første tegnene i aaaaa.
Lat mellom n og m	{n,m}? Matcher mellom n og m ganger, med så lite treff som mulig. Samsvarer for eksempel a{1,3}? bare med det første tegnet i aaaaa.
Eksakt n	{n} matcher n ganger, nøyaktig. For eksempel,samsvarer a{3} nøyaktig tre tegn av aaaaa.

Possessive kvantifierere støttes ikke.

Å blande underkamper og kvantifikatorer har begrensninger. Hvis du vil ha mer informasjon, kan du se Muligens tomme deltreff.

Grupper

Funksjon	Description
Grupper	( og ) brukes til å gruppere elementer for kvantifikatorer som skal brukes. For eksempel,treff (abc)+abcabc.
Veksling	a|b Samsvarer med "A" eller "B", ofte brukt i en gruppe.
Navngitt delsamsvar og tilbakereferanse	(?<name>chars) fanger opp et undersamsvar med navnet name, referert til \k<name>. Kan ikke brukes hvis MatchOptions.NumberedSubMatches er aktivert.
Nummerert delsamsvar og baksidereferanse	Når MatchOptions.NumberedSubMatches er aktivert, (a) fanger opp et undersamsvar det refereres til \1.
Ikke-fangst-gruppe	(?:a), oppretter gruppe uten å registrere resultatet som et navngitt eller nummerert undersamsvar. Alle grupper fanges ikke opp med mindre MatchOptions.NumberedSubMatches er aktivert.

Navngitte og nummererte deltreff kan ikke brukes sammen. Som standard er navngitte undertreff aktivert og foretrekkes for klarhet og vedlikehold, mens standard opptaksgrupper blir ikke-fangstgrupper med forbedret ytelse. Denne virkemåten kan endres med MatchOptions.NumberedSubMatches , som gir tradisjonelle fangstgrupper, men deaktiverer navngitte fangstgrupper. Noen implementeringer behandler en blanding av nummererte og navngitte fangstgrupper forskjellig, og det er grunnen til Power Fx at det ikke tillater det.

Selvrefererende fangstgrupper støttes ikke, for eksempel det regulære uttrykket (a\1).

To fangstgrupper kan ikke dele samme navn, for eksempel støttes ikke det regulære uttrykket (?<id>\w+)|(?<id>\d+) .

Navnet på et navngitt undertreff må begynne med et \p{L} tegn eller _, og kan fortsette med disse tegnene pluss \p{Nd}. Navn er begrenset i lengde til 62 UTF-16 kodeenheter.

Tilbakereferanser til muligens tomme undertreff og til undertreff i et blikk bak eller se fremover støttes heller ikke.

Noen implementeringer tilbyr et "eksplisitt opptak"-alternativ for å forbedre ytelsen, noe som er unødvendig siden Power Fx det er standard. MatchOptions.NumberedSubMatches deaktiverer den og muliggjør implisitt nummererte opptak.

Å blande underkamper og kvantifiseringer har begrensninger. Se Muligens tomme undertreff for mer informasjon.

Kommentarer

Funksjon	Description
Innebygde kommentarer	(?# comment here), som ignoreres som en kommentar. Kommentar slutter med neste lukkede parentes, selv om en åpningsparentes er i kommentaren.

Se MatchOptions.FreeSpacing for et alternativ for formatering og kommentering av regulære uttrykk.

Innebygde alternativer

Funksjon	Description
Innebygde alternativer	(?im) er det samme som å bruke MatchOptions.IgnoreCase og MatchOptions.Multiline. Må angis i begynnelsen av det regulære uttrykket.

Innebygde moduser som støttes er [imsx]. Disse tilsvarer henholdsvis MatchOptions.IgnoreCase,MatchOptions.Multiline,MatchOptions.DotAll og MatchOptions.FreeSpacing. n er også akseptert for kompatibilitet, men har ingen effekt da det er standard og er inkompatibelt med MatchOptions.NumberedSubMatches.

Innebygde alternativer kan ikke brukes til å deaktivere et alternativ eller angi et alternativ for et deluttrykk.

Alternativer

Samsvarsalternativer endrer virkemåten til samsvar med regulære uttrykk. Det er to måter å aktivere alternativer på, som kan blandes så lenge det ikke er noen konflikt:

• MatchOptions-opplistingsverdi sendes som det tredje argumentet til Match,MatchAll og IsMatch. Alternativene kan for eksempel & kombineres med Concatenate operatøren eller MatchOptions.DotAll & MatchOptions.FreeSpacingfunksjonen. Alle funksjonene for regulære uttrykk krever at MatchOptions er en konstant verdi, den kan ikke beregnes eller lagres i en variabel.
• (?...) prefikset helt i begynnelsen av det regulære uttrykket. Alternativer kan for eksempel (?...) kombineres med flere bokstaver i konstruksjonen (?sx). Noen alternativer har ikke en (?...) ekvivalent, men kan ha andre måter å få samme effekt på, for eksempel MatchOptions.BeginsWith tilsvarer ^ i begynnelsen av det regulære uttrykket.

Contains

Aktivert med MatchOptions.Inneholder uten en regulært uttrykksekvivalent. MatchOptions.Contains er standard for alle funksjoner utenfor Power Apps; i Power Apps MatchOptions.Complete er standard for IsMatch.

Fullført

Aktivert med MatchOptions.Complete eller bruk ^ og $ i begynnelsen og av det regulære uttrykket, henholdsvis.

BeginsWith

Aktivert med MatchOptions.BeginsWith eller bruk ^ i begynnelsen og av det regulære uttrykket.

EndsWith

Aktivert med MatchOptions.EndsWith eller bruk $ på slutten av det regulære uttrykket.

DotAll

Aktivert med MatchOptions.DotAll eller (?s) i begynnelsen av det regulære uttrykket.

Normalt samsvarer punktoperatoren . med alle tegn unntatt linjeskifttegn [\n\x0b\f\r\x85\u2028\u2029]. Med DotAll-modifikatoren samsvarer alle tegn, inkludert nye linjer.

I dette eksemplet samsvarer bare «Hei» som standard . ikke samsvarer med den nye linjen:

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

Men hvis vi legger til DotAll-modifikatoren , samsvarer den nye linjen og alle påfølgende tegn:

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

Fri avstand

Aktivert med MatchOptions.FreeSpacing eller (?x) i begynnelsen av et regulært uttrykk.

Fri avstand gjør det enklere å lese og vedlikeholde et komplekst regulært uttrykk. Reglene er enkle:

• Mellomromstegn ignoreres i det regulære uttrykket, inkludert alle tegn som samsvarer \s. Hvis du ønsker å matche et mellomrom, bruk \s, \ , \t, \r, eller \n.
• # begynner en kommentar som går til slutten av linjen. Den og alle tegn som følger opp til neste linjeskifttegn (tegn som ikke samsvarer med . uten MatchOptions.DotAll) ignoreres.
• Karakterklasser er ikke inkludert i disse endringene. Plasser karakterer og # oppfør deg som de vanligvis gjør. Returnerer IsMatch( "a#b c", "(?x)a[ #]b[ #]c" ) for eksempel sann. Noen språk for regulære uttrykk inkluderer tegnklasser i fri avstand, eller gir et alternativ for å inkludere dem, men Power Fx gjør det ikke.

Her er for eksempel et komplekst regulært uttrykk for å matche et ISO 8601-datoklokkeslett:

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

Og her er det identiske regulære uttrykket med fri avstand ved å bruke flere linjer, innrykk for grupper og regulære uttrykkskommentarer, noe som gjør denne versjonen enklere å forstå, validere og vedlikeholde.

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

Ignorer saken

Aktivert med MatchOptions.IgnoreCase eller (?i) i begynnelsen av et regulært uttrykk.

Samsvarer med tekst i en bokstav som skiller mellom store og små bokstaver: store bokstaver samsvarer med små bokstaver og små bokstaver samsvarer med store bokstaver.

Eksempel:

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

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

De fleste deler eller Power Fx er kulturbevisste, men ikke her. Bruk av invariant av kultur er bransjestandarden for regulære uttrykk, inkludert i JavaScript og Perl. Det er nyttig i det andre eksemplet der en systemressurs blir matchet, for eksempel i kulturen tr-TR der I ikke er den store bokstaven ekvivalent til i.

Hvis det er nødvendig med et kulturbevisst samsvar som ikke skiller mellom store og små bokstaver, bruker du tegnklassen med de samsvarende tegnene i stedet, for eksempel [Hh][Ee][Ll][Ll][Oo] for det første eksemplet.

Flere linjer

Aktivert med MatchOptions.Multiline eller (?m) i begynnelsen av et regulært uttrykk.

Normalt, ^ og $ ankere samsvarer med begynnelsen og av inndatateksten. Med flerlinjemodifikatoren samsvarer disse ankrene med begynnelsen og slutten av linjene i inndatateksten, der hver linje slutter med \r, \n, \r\n, eller slutten av inndataene. Eksempel:

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

Forhåndsdefinerte mønstre

Forhåndsdefinerte mønstre lar deg matche enten ett av et sett med tegn eller en sekvens med flere tegn. Bruk operatoren for sammenkobling av strenger& for å kombinere tekststrengene dine med medlemmer av Match-opplistingen:

Match-enumerator	Description	Vanlig uttrykk
Enhver	Samsvarer med et hvilket som helst tegn.	.
Komma	Samsvarer med et komma ,.	,
Siffer	Samsvarer med ett enkelt siffer (0 gjennom 9 og andre medlemmer av \p{Nd}).	\d
E-postadresse	Samsvarer med en e-postadresse som inneholder et «at»-symbol (@) og et domenenavn som inneholder minst én punktum (.), atskilt med mellomrom og skilletegn.	Se merknad
Bindestrek	Samsvarer med en bindestrek.	- Se merknad
LeftParen	Samsvarer med en venstre parentes (.	\(
Brev	Samsvarer med en bokstav.	\p{L}
Flere sifre	Samsvarer med ett eller flere siffer.	\d+
Flere bokstaver	Samsvarer med én eller flere bokstaver.	\p{L}+
Flere ikke-mellomrom	Samsvarer med ett eller flere tegn som ikke legger til mellomrom (ikke mellomrom, tabulator eller linjeskift).	\S+
Flere mellomrom	Samsvarer med ett eller flere tegn som legger til mellomrom (mellomrom, tabulator eller linjeskift).	\s+
Ikke-mellomrom	Samsvarer med ett enkelt tegn som ikke legger til mellomrom.	\S
Valgfrie sifre	Samsvarer med ingen, ett eller flere siffer.	\d*
Valgfrie bokstaver	Samsvarer med ingen, én eller flere bokstaver.	\p{L}*
OptionalNonSpaces	Samsvarer med ingen, ett eller flere tegn som ikke legger til mellomrom.	\S*
Valgfrie mellomrom	Samsvarer med ingen, ett eller flere tegn som legger til mellomrom.	\s*
Period	Samsvarer med et punktum eller punktum ..").	\.
HøyreParen	Samsvarer med høyre parentes ).	\)
Rom	Samsvarer med et tegn som legger til mellomrom.	\s
Tab	Samsvarer med et tabulatortegn.	\t

For eksempel mønsteret "A" & Match.MultipleDigits samsvarer med bokstaven "A" etterfulgt av ett eller flere sifre.

Det Match.Email mønsteret er mer komplekst enn resten. Den oppdager og trekker ut vanlige e-postadresser i skjemaet local@hostname.tld, muligens fra lange tekstpassasjer, og støtter internasjonale tegn og emojier. Bruk den til å validere et skjema som tar en e-postadresse som inndata, som en rask test på at inndataene er i et e-postskjema. Hvis du ikke trekker ut, kan du bruke MatchOptions.Complete til å oppdage en e-postadresse, for eksempel i en tekstinndatakontroll.

Match.Email validerer imidlertid ikke at e-postadressen samsvarer med alle de mange utviklende standardene for e-postadresser, domenenavn og toppnivådomener som vil kreve et komplisert regulært uttrykk som må oppdateres fra tid til annen. Selv om de fleste e-postadresser behandles som forventet, samsvarer Match.Email med noen ugyldige tilfeller , for eksempel et understrekingstegn i vertsnavnet, og samsvarer ikke med noen gyldige tilfeller, for eksempel angitte e-postadresser eller IP-adresser. Om nødvendig er det mange regulære uttrykk på nettet for å oppdage en virkelig juridisk e-postadresse. Test alltid det regulære uttrykket ditt for dine spesifikke behov før du bruker det i produksjon.

Hvis du vil se det regulære uttrykket som er brukt, evaluerer du formelen Text( Match.Email ). Den første delen samsvarer med tegnene før @ og ekskluderer vanlig ASCII-tegnsetting i henhold til RFC 822 og revisjoner og Unicode begynnelse og slutt tegnsetting for enklere uttrekking, for eksempel (, [, “, « og 「. Den støtter ikke den uvanlige og frarådede bruken av strenger eller kommentarer i anførselstegn. Etter den @ andre og tredje delen av det regulære uttrykket er de samme og atskilt med a ., noe som sikrer at det alltid er minst én . i adressen. Disse delene ekskluderer all Unicode-tegnsetting bortsett fra ., -, og _. IP-adresser støttes ikke. Gjennom hele e-postadressen støttes internasjonale tegn og emojier.

I Power Apps, når du ikke bruker Power Fx 1.0,Match.Email og Match.Hyphen har litt forskjellige definisjoner. Match.Email er enklere, men er ikke egnet for å trekke ut en e-postadresse da den fanger opp mellomrom. Tidligere ble Match.Hyphen rømt utenfor en karakterklasse som nå er ulovlig.

NummererteSub-treff

Aktivert med MatchOptions.NumberedSubMatches uten innebygd alternativ. (?n) støttes som det motsatte av dette alternativet for kompatibilitet og er standard.

Som standard,fanger (...) ikke, tilsvarende det de fleste systemer kaller "eksplisitt fangst." Hvis du vil skanne, bruker du et navngitt opptak med (?<name>...) med tilbakereferanse \k<name>. Bruk av navngitte opptak forbedrer ytelsen ved å ikke registrere grupper som ikke er nødvendige, forbedre klarheten ved å bruke navn og ikke utsatt for feil hvis plasseringen av opptak endres.

Hvis du har et eksisterende regulært uttrykk, kan det avhenge av at grupper registreres automatisk og nummereres, inkludert nummererte tilbakereferanser. Denne virkemåten er tilgjengelig ved hjelp av alternativet MatchOptions.NumberedSubMatches .

Navngitte og nummererte deltreff kan ikke brukes sammen. Fordi noen implementeringer behandler en blanding av nummererte og navngitte fangstgrupper forskjellig, Power Fx tillater det ikke.

Muligens tomme undertreff

Som nevnt i innledningen, Power Fx er regulære uttrykk med vilje begrenset til funksjoner som konsekvent kan implementeres på .NET, JavaScript og andre programmeringsspråkmotorer for regulære uttrykk. Feil på redigeringstidspunktet hindrer bruk av funksjoner som ikke er en del av dette settet.

Et område som kan være forskjellig mellom implementeringer, er hvordan tomme undermatcher håndteres. Tenk for eksempel på det regulære uttrykket (?<submatch>a*)+ som blir bedt om å samsvare med teksten a. På .NET resulterer undersamsvaret i en tom tekststreng, mens det på JavaScript resulterer i a. Begge kan argumenteres som korrekte implementeringer, da + kvantifikatoren kan være fornøyd med en tom streng siden innholdet i gruppen har en * kvantifikator.

Hvis du vil unngå ulike resultater på tvers av Power Fx implementeringer, kan ikke deltreff som kan være tomme, brukes med en kvantifierer. Her er noen eksempler på hvordan et undersamsvar kan være tomt:

Eksempler	Description
(?<submatch>a{0,}b*)+	Alt innholdet i delsamsvaret er valgfritt, så hele deltreffet kan være tomt.
((<submatch>a)?b)+	På grunn av ? utsiden av delsamsvaret er delsamsvaret som helhet valgfritt.
(?<submatch>a|b*)+	Veksling i underkampen med noe som kan være tomt kan føre til at hele underkampen blir tom.
((?<submatch>a)|b)+	Veksling utenfor underkampen kan samsvare b , og i så fall vil underkampen være tom.

Delsamsvaret i (?<submatch>a+)+ kan ikke være tomt fordi det må være minst én a i delsamsvaret, og det støttes.

Unicode

Power Fx regulære uttrykk bruker Unicode-kategorier til å definere \w, \d, og \s med bestemte kategorier tilgjengelig gjennom \p{..}.

Disse definisjonene kan variere fra plattform til plattform. For eksempel oppdateres Unicode-standarden fra tid til annen med nye tegn som senere vil bli implementert av plattformer i sitt eget tempo. Forvent variasjoner i resultater mellom plattformer til alle plattformer er oppdatert.

Power Fx Regulære uttrykk sikrer at kategoriinformasjon alltid er tilgjengelig for det grunnleggende flerspråklige planet (tegn U+0 til U+ffff). Noen plattformer implementerer ikke kategorier for tegn i det supplerende flerspråklige planet og utover (U+10000 til U+10ffff). Denne begrensningen er vanligvis ikke et problem, da tegn i det grunnleggende flerspråklige planet er de mest brukte. Bruk tegnverdier direkte i stedet for kategorier hvis scenarioet ditt involverer tegn på eller over U+10000. Test dine regulære uttrykk på plattformene du har tenkt å bruke.

Små forskjeller i kanttilfeller kan eksistere mellom plattformer. Noen plattformer kan for eksempel ikke se ſ som samsvarende s når MatchOptions.IgnoreCase startes. Hvis disse tegnene er viktige for scenarioet ditt, kan du bruke en tegnklasse som [ſsS] for å matche mellom store og små bokstaver og eksplisitt inkludere de ønskede tegnene.