Reguläre Ausdrücke

The IsMatch, Match, and MatchAll Funktionen werden verwendet, um Muster im Text zu extrahieren und zu überprüfen. Das Muster, das sie verwenden, ist ein regulärer Ausdruck.

Reguläre Ausdrücke sind leistungsstark und vielseitig. Sie können jedoch manchmal als zufällige Folge von Satzzeichen angezeigt werden. In diesem Artikel werden nicht alle Aspekte der regulären Ausdrücken beschrieben; allerdings können Sie im Internet viele weitere Informationen und Tutorials und Tools finden.

Reguläre Ausdrücke haben eine lange Geschichte und sind in vielen Programmiersprachen verfügbar. Jede Programmiersprache hat ihren eigenen Dialekt von regulären Ausdrücken, und es gibt nur wenige Standards. Wir bemühen uns, so weit wie möglich denselben regulären Ausdruck in allen Power Fx Implementierungen dasselbe Ergebnis liefern zu lassen. Die Kompatibilität ist nicht einfach zu bewerkstelligen, da Power Fx auf JavaScript und .NET ausgeführt wird, die erhebliche Unterschiede aufweisen. Um auf verschiedenen Plattformen ausgeführt zu werden, verwendet Power Fx reguläre Funktionen, die in der gesamten Branche unterstützt werden.

Dies kann dazu führen, dass einige reguläre Ausdrücke, die in anderen Umgebungen funktionieren, blockiert werden oder Anpassungen in Power Fx erfordern. Erstellungszeitfehler werden gemeldet, wenn nicht unterstützte Funktionen erkannt werden. Aus diesem Grund müssen der reguläre Ausdruck und die Optionen eine Erstellungszeitkonstante sein und dürfen nicht dynamisch sein, z. B. in einer Variablen angegeben werden.

Unterstützte Funktionen

Power Fx unterstützt die folgenden Funktionen für reguläre Ausdrücke, mit Hinweisen darauf, wie Power Fx sich das Verhalten von anderen Systemen unterscheiden kann.

Der reguläre Ausdruck muss konstant sein und darf nicht in einer Variablen berechnet oder gespeichert werden. Der & Operator, die Zeichenfolgeninterpolation $"{...}" und die Funktionen Concatenate, Char und UniChar mit konstanten Argumenten werden unterstützt.

Literalzeichen

Stattdessen \x oder \u verwenden. Oktale Codes für Zeichen, wie \044 oder \o{044} sind nicht zulässig, da sie mit nummerierten Rückverweisen mehrdeutig sein können.

\v wird nicht unterstützt, da es in verschiedenen Sprachen mit regulären Ausdrücken mehrdeutig ist. Verwenden Sie \x0b für einen vertikalen Tabulator oder [\x0b\f\r\n\x85\u2028\u2029] für vertikales Leerzeichen.

Assertionen

Assertionen entsprechen einer bestimmten Position im Text, verbrauchen jedoch keine Zeichen.

$ entspricht dem Ende einer Zeile, einschließlich aller nachfolgenden \r\n, \r oder \n.

Lookahead- und Lookbehind-Assertionen können keine Unterübereinstimmungen oder unbegrenzte Quantifizierer enthalten und können nicht mit einem Quantifizierer außerhalb verwendet werden.

Zeichenklassen

Um die Übersichtlichkeit zu erhöhen und Mehrdeutigkeiten zu vermeiden, sind Zeichenklassen in eckigen Klammern restriktiver als in anderen Sprachen für reguläre Ausdrücke:

• Literale Bindestriche müssen mit Escapezeichen versehen werden. Verwenden Sie [\-a] anstelle von [-a] um - oder a zu vergleichen.
• Eckige Klammern am Anfang müssen mit Escapezeichen versehen werden. Verwenden Sie [\[a] anstelle von [[] um [ oder a zu vergleichen.
• Sofern es sich nicht um das erste Zeichen handelt, das eine Negation angibt, muss das Zeichen mit Escapezeichen versehen werden. Verwenden Sie [a\^] anstelle von [a^] um ^ oder a zu vergleichen.
• Geschweifte Klammern müssen mit Escapezeichen versehen werden. Verwenden Sie [\{\}], um { oder } abzugleichen.
• Leere Zeichenklasse [] wird nicht unterstützt. Wenn Sie eine schließende eckige Klammer in eine Zeichenklasse einfügen möchten, maskieren Sie sie.

Unicode-Zeichenkategorien, die von \p{} und \P{} unterstützt werden:

• Buchstaben; L, Lu, Ll, Lt, Lm, Lo
• Markierungen: M, Mn, Mc, Me
• Nummern: N, Nd, Nl, No
• Interpunktion: P, Pc, Pd, Ps, Pe, Pi, PfPo
• Symbole: S, Sm, Sc, Sk, So
• Trennzeichen: Z, Zs, Zl, Zp
• Steuerzeichen und Format: Cc, Cf, während andere C Präfixkategorien nicht unterstützt werden.

\W, \D, \S, und \P{} kann nicht in einer negativen Zeichenklasse verwendet werden [^...]. Um auf einigen Plattformen implementiert zu werden, werden diese negativen Zeichenklassen in ihre Unicode-Entsprechungen übersetzt, was schwierig sein könnte, wenn sie auch negiert werden.

Unicode-Zeichen zwischen U+10000 und U+10FFFF, die Ersatzzeichenpaare erfordern, werden in Zeichenklassen nicht unterstützt.

Quantoren

Possessive Quantifizierer werden nicht unterstützt.

Das Mischen von Unterübereinstimmungen und Quantifizierern hat Einschränkungen. Weitere Informationen finden Sie unter Möglicherweise leere Unterübereinstimmungen.

Groups

Benannte und nummerierte Unterübereinstimmungen können nicht zusammen verwendet werden. Standardmäßig sind benannte Unterübereinstimmungen aktiviert und werden aus Gründen der Übersichtlichkeit und Verwaltbarkeit bevorzugt, während Standarderfassungsgruppen zu Nichterfassungsgruppen mit verbesserter Leistung werden. Dieses Verhalten kann mit MatchOptions.NumberedSubMatches geändert werden, das herkömmliche Erfassungsgruppen bereitstellt, aber benannte Erfassungsgruppen deaktiviert. Einige Implementierungen behandeln eine Mischung aus nummerierten und benannten Erfassungsgruppen unterschiedlich, weshalb Power Fx sie nicht zulässt.

Selbstreferenzierende Erfassungsgruppen werden nicht unterstützt, z. B. der reguläre Ausdruck (a\1).

Zwei Erfassungsgruppen können nicht denselben Namen haben, z. B. wird der reguläre Ausdruck (?<id>\w+)|(?<id>\d+) nicht unterstützt.

Der Name einer benannten Unterübereinstimmung muss mit einem \p{L} Zeichen oder _ beginnen und kann mit diesen Zeichen plus \p{Nd} fortgesetzt werden. Die Länge der Namen ist auf 62 UTF-16-Codeeinheiten begrenzt.

Rückverweise auf möglicherweise leere Unterübereinstimmungen und auf Unterübereinstimmungen innerhalb eines Blicks nach hinten oder nach vorne werden ebenfalls nicht unterstützt.

Einige Implementierungen bieten eine Option zur expliziten Erfassung, um die Leistung zu verbessern, was in Power Fx unnötig ist, da es sich um die Standardeinstellung handelt. MatchOptions.NumberedSubMatches deaktiviert sie und ermöglicht implizit nummerierte Erfassungen.

Das Mischen von Unterübereinstimmungen und Quantifizierern hat Einschränkungen. Weitere Informationen finden Sie unter Möglicherweise leere Unterübereinstimmungen.

Anmerkungen

Eine Alternative zum Formatieren und Kommentieren von regulären Ausdrücken finden Sie unter MatchOptions.FreeSpacing.

Inline-Optionen

Unterstützte Inline-Modi sind [imsx]. Diese entsprechen MatchOptions.IgnoreCase, MatchOptions.Multiline, MatchOptions.DotAll und MatchOptions.FreeSpacing. n wird auch aus Kompatibilitätsgründen akzeptiert, hat jedoch keine Auswirkungen, da es sich um die Standardeinstellung handelt und nicht mit MatchOptions.NumberedSubMatches kompatibel ist.

Inline-Optionen können nicht verwendet werden, um eine Option zu deaktivieren oder eine Option für einen Unterausdruck festzulegen.

Optionen

MatchOptions ändern das Verhalten des Abgleichs regulärer Ausdrücke. Es gibt zwei Möglichkeiten, Optionen zu aktivieren, die gemischt werden können, solange es keinen Konflikt gibt:

• MatchOptions Enumerationswert, der als drittes Argument an Match, MatchAll und IsMatch übergeben wird. Optionen können mit dem & Operator oder der Concatenate Funktion kombiniert werden, z.B. MatchOptions.DotAll & MatchOptions.FreeSpacing. Für alle Funktionen mit regulärem Ausdruck ist es erforderlich, dass MatchOptions ein konstanter Wert ist. Er kann nicht berechnet oder in einer Variablen gespeichert werden.
• (?...) Präfix ganz am Anfang des regulären Ausdrucks. Optionen können mit mehreren Buchstaben im (?...)-Konstrukt kombiniert werden, z. B. (?sx). Für einige Optionen gibt es (?...) keine Entsprechung, aber es können andere Möglichkeiten vorhanden sein, um den gleichen Effekt zu erzielen. beispielsweise ist MatchOptions.BeginsWith das Äquivalent zu ^ am Anfang des regulären Ausdrucks.

Contains

Aktiviert mit MatchOptions.Contains ohne einen Text äquivalentn regulären Ausdruck. MatchOptions.Contains ist der Standardwert für alle Funktionen außerhalb von Power Apps; innerhalb von Power Apps ist MatchOptions.Complete der Standardwert für IsMatch.

Abgeschlossen

Aktiviert mit MatchOptions.Complete oder verwenden Sie ^ und $ jeweils am Anfang und Ende des regulären Ausdrucks.

BeginsWith

Aktiviert mit MatchOptions.BeginsWith oder verwenden Sie ^ am Anfang und Ende des regulären Ausdrucks.

EndsWith

Aktiviert mit MatchOptions.EndsWith oder verwenden Sie $ am Ende des regulären Ausdrucks.

DotAll

Aktiviert mit MatchOptions.Dot All oder verwenden Sie (?s) am Beginn des regulären Ausdrucks.

Normalerweise stimmt der . Punktoperator mit allen Zeichen außer Zeilenumbruchzeichen [\n\x0b\f\r\x85\u2028\u2029] überein. Mit dem Modifikator DotAll werden alle Zeichen abgeglichen, einschließlich Zeilenumbrüche.

In diesem Beispiel wird nur Hello abgeglichen, da das . standardmäßig nicht mit dem Zeilenumbruch übereinstimmt:

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

Wenn wir jedoch den DotAll-Modifizierer hinzufügen, werden der Zeilenumbruch und alle nachfolgenden Zeichen abgeglichen:

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

FreeSpacing

Aktiviert mit MatchOptions.FreeSpacing oder verwenden Sie (?x) am Beginn eines regulären Ausdrucks.

Freie Abstände erleichtern das Lesen und Pflegen komplexer regulärer Ausdrücke. Die Regeln sind einfach:

• Leerzeichen werden im regulären Ausdruck ignoriert, einschließlich aller Zeichen, die einem \s entsprechen würden. Wenn die Übereinstimmung mit einem Leerzeichen gewünscht ist, verwenden Sie \s, \ , \t, \r, oder \n.
• # beginnt einen Kommentar, der bis zum Ende der Zeile läuft. Es und alle Zeichen, die auf das nächste Zeilenumbruchzeichen folgen (Zeichen, die . ohne MatchOptions.DotAll nicht übereinstimmen), werden ignoriert.
• Zeichenklassen sind in diesen Änderungen nicht enthalten. Leerzeichen und # verhalten sich wie gewohnt. Zum Beispiel gibt IsMatch( "a#b c", "(?x)a[ #]b[ #]c" )Tue zurück. Einige Sprachen für reguläre Ausdrücke enthalten Zeichenklassen mit freiem Abstand oder bieten eine Option zum Einschließen, dies ist jedoch bei Power Fx nicht der Fall.

Hier ist z. B. ein komplexer regulärer Ausdruck für den Abgleich einer ISO 8601-Datums-/Uhrzeit:

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

Und hier ist der identische reguläre Ausdruck mit freiem Abstand unter Verwendung mehrerer Zeilen, Einrückung für Gruppen und Kommentaren mit regulären Ausdrücken, wodurch diese Version leichter zu verstehen, zu validieren und zu pflegen ist.

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

Aktiviert mit MatchOptions.IgnoreCAse oder verwenden Sie (?i) am Beginn eines regulären Ausdrucks.

Ordnet Text bei einem Buchstaben ohne Berücksichtigung der Groß-/Kleinschreibung zu: Großbuchstaben entsprechen Kleinbuchstaben und Kleinbuchstaben Großbuchstaben.

Zum Beispiel:

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

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

Die meisten Teile sind Power Fx kulturbewusst, aber nicht hier. Die Verwendung von kulturinvariantem Abgleich ist der Industriestandard für reguläre Ausdrücke, auch in JavaScript und Perl. Dies ist nützlich im zweiten Beispiel, in dem eine Systemressource abgeglichen wird, z. B. in der Kultur tr-TR, in der I nicht das Großbuchstabenäquivalent von i ist.

Wenn eine kulturbewusste Übereinstimmung erforderlich ist, bei der die Groß-/Kleinschreibung nicht beachtet wird, verwenden Sie stattdessen die Zeichenklasse mit den übereinstimmenden Zeichen, z. B. [Hh][Ee][Ll][Ll][Oo] für das erste Beispiel.

Multiline

Aktiviert mit MatchOptions.Multiline oder verwenden Sie (?m) am Beginn eines regulären Ausdrucks.

Normalerweise stimmen ^ und $ Anker mit dem Anfang und dem Ende des Eingabetextes überein. Mit dem Modifikator Mehrzeilig stimmen diese Anker mit dem Anfang und Ende der Zeilen im Eingabetext überein, wobei jede Zeile mit \r, \n, \r\n oder dem Ende der Eingabe endet. Zum Beispiel:

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

Vordefinierte Muster

Mit vordefinierten Mustern können Sie ganz leicht ein Zeichen aus einem Zeichensatz oder eine Sequenz aus mehreren Zeichen übereinstimmen. Verwenden Sie den Operator für Zeichenfolgenverkettungen&, um Ihre eigenen Textzeichenfolgen mit Mitglieder der Match-Enumeration zu kombinieren:

Das Muster „A“ & Match.MultipleDigits entspricht dem Buchstaben „A“ gefolgt von einer oder mehreren Ziffern

Das Match.Email Muster ist komplexer als der Rest. Es erkennt und extrahiert gängige E-Mail-Adressen im Formular local@hostname.tld, möglicherweise aus langen Textpassagen, und unterstützt internationale Zeichen und Emojis. Verwenden Sie es, um ein Formular zu überprüfen, das eine E-Mail-Adresse als Eingabe verwendet, um schnell zu testen, ob die Eingabe die Form einer E-Mail-Adresse hat. Wenn Sie nicht extrahieren, verwenden Sie MatchOptions.Complete, um eine E-Mail-Adresse zu erkennen, z. B. in einem Texteingabesteuerelement.

Aber Match.Email überprüft nicht, ob die E-Mail-Adresse allen sich entwickelnden Standards für E-Mail-Adressen, Domainnamen und Top-Level-Domains entspricht, die einen komplizierten regulären Ausdruck erfordern würden, der von Zeit zu Zeit aktualisiert werden müsste. Obwohl die meisten E-Mail-Adressen wie erwartet behandelt werden, stimmt Match.Email mit einigen ungültigen Fällen überein, z. B. einem Unterstrich im Hostnamen, und stimmt mit einigen gültigen Fällen nicht überein, z. B. E-Mail-Adressen in Anführungszeichen oder IP-Adressen. Bei Bedarf gibt es viele reguläre Ausdrücke im Web, um eine wirklich legale E-Mail-Adresse zu erkennen. Testen Sie Ihren regulären Ausdruck immer für Ihre spezifischen Anforderungen, bevor Sie ihn in der Produktion verwenden.

Wenn Sie den regulären Ausdruck sehen möchten, werten Sie die Formel Text( Match.Email ) aus. Der erste Teil stimmt mit den Zeichen vor dem @ überein und schließt gängige ASCII-Interpunktion gemäß RFC 822 und Revisionen sowie Unicode-Anfangs- und Endinterpunktion für eine einfachere Extraktion aus, z. B. (, [, “, « und 「. Die unübliche und nicht empfohlene Verwendung von Zeichenfolgen oder Kommentaren in Anführungszeichen wird nicht unterstützt. Nach dem @ sind der zweite und dritte Teil des regulären Ausdrucks identisch und durch ein . getrennt, um sicherzustellen, dass immer mindestens ein . in der Adresse vorhanden ist. Diese Teile schließen alle Unicode-Interpunktionszeichen mit Ausnahme von ., - und _ aus. IP-Adressen werden nicht unterstützt. In der gesamten E-Mail-Adresse werden internationale Zeichen und Emojis unterstützt.

In Power Apps, wenn Power Fx 1.0 nicht verwendet wird, haben Match.Email und Match.Hyphen leicht unterschiedliche Definitionen. Match.Email ist einfacher, eignet sich aber nicht zum Extrahieren einer E-Mail-Adresse, da sie Leerzeichen erfasst. Zuvor wurde Match.Hyphen außerhalb einer Zeichenklasse escaped, was jetzt nicht mehr erlaubt ist.

NumberedSubMatches

Aktiviert mit MatchOptions.NumberedSubMatches ohne Inline-Option. (?n) wird aus Kompatibilitätsgründen als Gegenteil dieser Option unterstützt und ist die Standardeinstellung.

Standardmäßig wird (...) nicht erfasst, was den meisten Systemen als explizite Erfassung entspricht. Verwenden Sie zum Erfassen eine benannte Erfassung mit (?<name>...) mit Rückverweis \k<name>. Die Verwendung benannter Erfassungen verbessert die Leistung, da nicht benötigte Gruppen nicht erfasst werden, die Übersichtlichkeit durch die Verwendung von Namen verbessert wird und die Fehleranfälligkeit bei Änderungen der Position von Erfassungen nicht erhöht wird.

Wenn Sie über einen vorhandenen regulären Ausdruck verfügen, kann dies davon abhängen, dass Gruppen automatisch erfasst und nummeriert werden, einschließlich nummerierter Rückverweise. Dieses Verhalten ist mithilfe der Option MatchOptions.NumberedSubMatches verfügbar.

Benannte und nummerierte Unterübereinstimmungen können nicht zusammen verwendet werden. Da Implementierungen eine Mischung aus nummerierten und benannten Erfassungsgruppen unterschiedlich behanden, lässt Power Fx dies nicht zu.

Möglicherweise leere Unterübereinstimmungen

Wie in der Einleitung erwähnt, sind die regulären Power Fx Ausdrücke absichtlich auf Features beschränkt, die in .NET, JavaScript und anderen Engines für reguläre Ausdrücke in Programmiersprachen konsistent implementiert werden können. Erstellungszeitfehler verhindern die Verwendung von Funktionen, die nicht Teil dieses Satzes sind.

Ein Bereich, der sich zwischen den Implementierungen unterscheiden kann, ist der Umgang mit leeren Unterübereinstimmungen. Betrachten Sie z. B. den regulären Ausdruck (?<submatch>a*)+, der auffordert, den Text a abzugleichen. In .NET führt die Unterübereinstimmung zu einer leeren Textzeichenfolge, während sie bei JavaScript zu a führt. Beide können als korrekte Implementierungen argumentiert werden, da der + Quantifizierer mit einer leeren Zeichenfolge zufrieden sein kann, da der Inhalt der Gruppe einen * Quantifizierer hat.

Um unterschiedliche Ergebnisse zwischen Power Fx Implementierungen zu vermeiden, können Unterübereinstimmungen, die möglicherweise leer sind, nicht mit einem Quantifizierer verwendet werden. Nachfolgend finden Sie einige Beispiele dafür, wie eine Unterübereinstimmung leer sein kann:

Die Unterübereinstimmung in (?<submatch>a+)+ kann nicht leer sein, da mindestens eine a in der Unterübereinstimmung vorhanden sein muss, und dies wird unterstützt.

Unicode

Power Fx Reguläre Ausdrücke verwenden Unicode-Kategorien, um \w, \d und \s zu definieren, mit bestimmten Kategorien, die über \p{..} verfügbar sind.

Diese Definitionen können je nach Plattform variieren. Zum Beispiel wird der Unicode-Standard von Zeit zu Zeit mit neuen Zeichen aktualisiert, die später von den Plattformen in ihrem eigenen Tempo implementiert werden. Rechnen Sie mit unterschiedlichen Ergebnissen zwischen den Plattformen, bis alle Plattformen aktualisiert wurden.

Power Fx reguläre Ausdrücke stellen sicher, dass Kategorieinformationen für die mehrsprachige Basisebene (Zeichen U+0 bis U+ffff) immer verfügbar sind. Einige Plattformen implementieren keine Kategorien für Zeichen in der Supplementary Multilingual Plane und darüber hinaus (U+10000 bis U+10ffff). Diese Einschränkung ist in der Regel kein Problem, da Zeichen in der mehrsprachigen Basisebene am häufigsten verwendet werden. Verwenden Sie Zeichenwerte direkt anstelle von Kategorien, wenn Ihr Szenario Zeichen bei oder über U+10000 enthält. Testen Sie Ihre regulären Ausdrücke auf den Plattformen, die Sie verwenden möchten.

Zwischen den Plattformen können kleine Unterschiede bei Randfällen bestehen. Beispielsweise werden einige Plattformen möglicherweise nicht als ſ übereinstimmend angesehen s, wenn MatchOptions.IgnoreCase aufgerufen wird. Wenn diese Zeichen für Ihr Szenario wichtig sind, verwenden Sie eine Zeichenklasse [ſsS], bei der die Groß-/Kleinschreibung nicht beachtet wird, und schließen Sie die gewünschten Zeichen explizit ein.