Detta är en referenssida – känn inte att du måste läsa den eftersom den är ganska kortfattad. Andra avsnitt länkar till den när det behövs.
Regexmodifierare dyker upp i varje hörn på den här webbplatsen. I stället för att upprepade gånger förklara vad de gör och de många olika sätten att aktivera dem i varje regex-smak bestämde jag mig för att samla de fyra vanligaste (i, s, m och x) på ett ställe. I det sista avsnittet kartläggs kortfattat andra modifieringar, som vanligtvis är språkspecifika.
Språngpunkter
För att underlätta navigering finns här några språngpunkter till olika avsnitt på sidan:
✽ Case Insensitivity: i
✽ DOTALL (Dot Matches Line Breaks): s (utom Ruby och JavaScript)
✽ Multiline (^ och $ Match on Every Line): m (utom Ruby)
✽ Free-Spacing: x (utom JavaScript)
✽ Other Modifiers
✽ PCRE’s Special Start-of-Pattern Modifiers
(direktlänk)
Case Insensitivity: i
Som standard matchar alla större regex-motorer i skiftläget. Om du vill att mönster som Name:
Ja, men…
Vad betyder egentligen ”case-insensitive”?
Så länge du håller dig till de 26 bokstäverna i det engelska alfabetet är definitionen av versaler och gemener okomplicerad. När man förgrenar sig till typografiska finesser eller andra språk och skrifter är saker och ting inte alltid så enkla. Här är några frågor som du kan stöta på.
✽ Kommer fl (ett tecken, dvs. ligaturen fl) att matcha FL?
✽ Kommer à (ett tecken) att matcha À?
✽ Kommer à (två tecken, dvs. bokstaven a och accentgraven) att matcha À? Alla motorer verkar hantera detta korrekt.
✽ Matchar ß ss? Ingen motor verkar göra det.
✽ Kommer i att matcha İ (turkisk versal i) lika bra som I?
Dessa frågor är bara toppen av isberget. Även om jag visste alla svaren skulle det vara omöjligt att ta med dem alla i det här avsnittet: om du använder ett visst skript måste du undersöka hur din specifika motor hanterar skiftlägesöversyn i det skriptet.
Mer än ett sätt
För flera motorer kan du notera att det finns två sätt att aktivera skiftlägesöversyn: som en inline-modifier (?i) eller som ett alternativ i regex-metoden eller -funktionen.
Inline-modifier (?i)
I .NET, PCRE (C, PHP, R…), Perl, Python, Java och Ruby (men inte JavaScript) kan du använda inline-modifiern (?i), till exempel i (?i)cat. Se avsnittet om inline-modifierare för saftiga detaljer om tre ytterligare funktioner (som inte är tillgängliga i Python): aktivera den mitt i strängen, stänga av den med (?-i) eller tillämpa den endast på innehållet i en grupp som inte är en fångstgrupp med (?i:foo)
.NET
Avsevärt från inline-modifieraren (?i) har .NET-språken alternativet IgnoreCase. I C# kan du till exempel använda:
var catRegex = new Regex("cat", RegexOptions.IgnoreCase);
Perl
Perl
Förutom (?i) inline-modifieraren kan du i Perl lägga till i-flaggan efter mönsterets avslutande avgränsare. Du kan till exempel använda:if ($the_subject =~ m/cat/i) { … }
PCRE (C, PHP, R…)
Bemärk att i PCRE måste du aktivera Unicode-läget om du vill använda stor- och småskalig matchning med icke-engelska bokstäver som inte ingår i ditt språksystem, t.ex. med (*UTF8), den speciella start-av-mönster-modifieraren.
Förutom (?i) inline-modifieraren låter PCRE dig ställa in PCRE_CASELESS-läget när du anropar funktionen pcre_compile() (eller liknande):
cat_regex = pcre_compile( "cat", PCRE_CASELESS, &error, &erroroffset, NULL );
I PHP överförs PCRE_CASELESS-alternativet via i-flaggan, som du kan lägga till i din regex-sträng efter den avslutande avgränsaren. Du kan till exempel använda:$cat_regex = '~cat~i';
I R överförs alternativet PCRE_CASELESS via alternativet ignore.case=TRUE. Du kan till exempel använda:grep("cat", subject, perl=TRUE, value=TRUE, ignore.case=TRUE);
Python
Python har förutom inline-modifiern (?i) alternativet IGNORECASE. Du kan t.ex. använda:cat_regex = re.compile("cat", re.IGNORECASE)
Java
Som en del av (?i) inline-modifiern har Java alternativet CASE_INSENSITIVE. Du kan till exempel använda:
Pattern catRegex = Pattern.compile( "cat", Pattern.CASE_INSENSITIVE | Pattern.UNICODE_CASE );
Det UNICODE_CASE-alternativ som läggs till här säkerställer att funktionen för att undvika stor- och småbokstäver är Unicode-anpassad. Om du bara arbetar med ASCII behöver du inte använda det.
JavaScript
I JavaScript är ditt enda alternativ att lägga till i-flaggan efter ditt mönsters avslutande avgränsare. Du kan till exempel använda:var catRegex = /cat/i;
Ruby
Med Ruby kan du förutom inline-modifiern (?i) lägga till i-flaggan efter mönsterets avslutande avgränsare. Du kan till exempel använda:cat_regex = /cat/i
(direktlänk)
DOTALL (Dot Matches Line Breaks): s (with exceptions)
Det är standard att punkt . inte matchar tecken för radbrytning, t.ex. radmatning och vagnåterföring. Om du vill att mönster som BEGIN .*? END ska matcha över flera rader måste vi aktivera den funktionen.
Det här läget kallas ibland för single-line (därav s) eftersom punktstrecket förvandlar hela strängen till en enda stor rad – .* matchar från det första tecknet till det sista, oavsett hur många radbrytningar som finns emellan.
Läget kallas också DOTALL i PCRE, Python och Java (för att vara mer exakt använder PCRE-dokumentationen PCRE_DOTALL). För mig är namnet DOTALL ett förnuftigt sätt att kalla detta läge. Det tredje alternativet dot-matches-line-breaks är beskrivande men lite väl munter.
För flera motorer bör man notera att det finns två sätt att aktivera det: som en inline-modifierare eller som ett alternativ i regex-metoden eller -funktionen.
JavaScript
JavaScript har inte stöd för läget för enstaka rader. För att matcha alla tecken i JavaScript, inklusive radbrytningar, använder du en konstruktion som . Den här teckenklassen matchar ett tecken som antingen är en icke-siffra \D eller en siffra \d. Därför matchar den alla tecken.
En annan JavaScript-lösning är att använda XRegExp-regexbiblioteket. Om du har oändligt med tid kan du också försöka anpassa PCRE till JavaScript med hjälp av Emscripten, vilket Firas verkar ha gjort på regex 101.
Inline Modifier (?s)
I .NET, PCRE (C, PHP, R…), Perl, Python och Java (men inte Ruby) kan du använda inline-modifiern (?s), t.ex. i (?s)BEGIN .*? END. Se avsnittet om inline-modifierare för saftiga detaljer om tre ytterligare funktioner (som inte är tillgängliga i Python): aktivera den mitt i strängen, stänga av den med (?-s) eller tillämpa den endast på innehållet i en grupp som inte är en fångstgrupp med (?s:foo)
.NET
Avsevärt från (?s) inline-modifieraren har .NET-språken alternativet Singleline. I C# kan du till exempel använda:
var blockRegex = new Regex( "BEGIN .*? END", RegexOptions.IgnoreCase | RegexOptions.Singleline );
Perl
Perl
Frånsett (?s) inline-modifiern kan du i Perl lägga till s-flaggan efter ditt mönsters avslutande avgränsare. Du kan till exempel använda:if ($the_subject =~ m/BEGIN .*? END/s) { … }
PCRE (C, PHP, R…)
Pre låter dig förutom (?s) inline-modifiern ställa in PCRE_DOTALL-läget när du anropar funktionen pcre_compile() (eller liknande):
block_regex = pcre_compile( "BEGIN .*? END", PCRE_DOTALL, &error, &erroroffset, NULL );
I PHP överförs PCRE_DOTALL-alternativet via s-flaggan, som du kan lägga till i din regexsträng efter den avslutande avgränsaren. Du kan till exempel använda:$block_regex = '~BEGIN .*? END~s';
Python
Python har förutom (?s) inline-modifiern även alternativet DOTALL. Du kan till exempel använda:block_regex = re.compile("BEGIN .*? END", re.IGNORECASE | re.DOTALL)
Java
Som undantag till (?s) inline-modifiern har Java DOTALL-alternativet. Du kan till exempel använda:
Pattern blockRegex = Pattern.compile( "BEGIN .*? END", Pattern.CASE_INSENSITIVE | Pattern.DOTALL );
Ruby: (I Ruby kan du använda inline-modifiern (?m), till exempel i (?m)BEGIN .*? END. Detta är ett märkligt Ruby-urval eftersom andra motorer använder (?m) för läget ”^ och $ matchar på varje rad”.
Se avsnittet om inline-modifierare för saftiga detaljer om tre ytterligare funktioner: att aktivera den mitt i strängen, att stänga av den med (?-m) eller att tillämpa den endast på innehållet i en grupp som inte är en fångavsnittsgrupp med (?m:foo)
Ruby låter dig också lägga till m-flaggan i slutet av din regex-sträng. Du kan till exempel använda:block_regex = /BEGIN .*? END/m
(direktlänk)
Orsprung av DOTALL
Läget med en enda rad kallas också ofta DOTALL (som står för ”dot matches all”) på grund av PCRE_DOTALL-alternativet i PCRE, re.DOTALL-alternativet i Python och Pattern.DOTALL-alternativet i Java.
Jag har hört det hävdas flera gånger att ”DOTALL är en Python-grej” men detta verkade komma från personer som inte hade hört talas om motsvarande alternativ i PCRE och Java. Detta fick mig ändå att undra: var dök DOTALL upp först? Om man tittar på PCRE Change Log och gammal Python-dokumentation verkar det som om det dök upp i PCRE med version 0.96 (oktober 1997), i Python med version 1.5 (februari 1998) och sedan i Java 1.4 (februari 2002). Gapet mellan PCRE:s och Pythons introduktioner var inte avgörande – ordet kan ha cirkulerat i tidigare betaversioner, eller till och med i andra verktyg – så jag frågade Philip Hazel (PCRE:s fader) om det. Han svarade:
Jag tror att jag uppfann det – jag hade i alla fall inte sett det någon annanstans när jag försökte komma på ett namn för PCRE-alternativet som motsvarar Perls /s-alternativ. (”S” där står för ”single-line” (…) så jag ville ha ett bättre namn.)
Så där. De som gillar lite historia kanske gillar den här läckra klumpen.
(direktlänk)
Multilinje (^ och $ matchar på varje rad): m (utom Ruby)
Som standard, i alla större motorer utom Ruby, matchar ankarna ^ och $ bara (respektive) i början respektive slutet av strängen.
I Ruby matchar de i början och slutet av varje rad och det finns inget sätt att stänga av den funktionen. Detta är faktiskt ett rimligt sätt att göra saker och ting, med vilket Ruby delvis gottgör sig för att använda m för DOTALL-läge när andra motorer använder s.
I andra motorer, om du vill att mönster som ^Define och >>>>$ ska matcha (respektive) i början respektive slutet av varje rad, måste vi aktivera den funktionen.
Denna funktion brukar kallas multi-line (därav m) eftersom ankarna ^ och $ fungerar på flera rader.
För flera motorer kan man notera att det finns två sätt att aktivera den: som en inline-modifier (?m) eller som ett alternativ i regex-metoden eller -funktionen.
Ruby
I Ruby matchar ankarna ^ och $ alltid på alla rader. Det finns inget sätt att stänga av det här alternativet. Detta är faktiskt ett ganska bra sätt att göra saker och ting, eftersom det, som i de flesta varianter, finns separata ankare för början och slutet av strängar: \A, \Z och \z.
Å andra sidan kan man beklaga Rubys val att använda m-flaggan och modifieringen på ett icke-standardiserat sätt (se DOTALL).
Inline Modifier (?m)
I .NET, PCRE (C, PHP, R…), Perl, Python, Java och Ruby (men inte JavaScript) kan man använda inline-modifieringen (?m), till exempel i (?m)^cat. Se avsnittet om inline-modifierare för saftiga detaljer om tre ytterligare funktioner (som inte är tillgängliga i Python): aktivera den mitt i strängen, stänga av den med (?-m) eller tillämpa den endast på innehållet i en icke-fångstgrupp med (?m:foo)
.NET
Avsevärt från (?m) inline-modifieraren har .NET-språken alternativet Multiline. I C# kan du till exempel använda:
var catRegex = new Regex("^cat", RegexOptions.IgnoreCase | RegexOptions.Multiline);
Perl
Perl
Förutom (?m) inline-modifiern kan du i Perl lägga till m-flaggan efter ditt mönsters avslutande avgränsare. Du kan till exempel använda:if ($the_subject =~ m/^cat/m) { … }
PCRE (C, PHP, R…)
Pre låter dig, förutom (?m) inline-modifiern, ställa in PCRE-läget PCRE_MULTILINE när du anropar funktionen pcre_compile() (eller liknande):
cat_regex = pcre_compile( "^cat", PCRE_CASELESS | PCRE_MULTILINE, &error, &erroroffset, NULL );
I PHP överförs PCRE_MULTILINE-alternativet via m-flaggan, som du kan lägga till i din regexsträng efter den avslutande avgränsaren. Du kan till exempel använda:$cat_regex = '~^cat~m';
Python
Python har förutom inline-modifiern (?m) alternativet MULTILINE. Du kan till exempel använda:cat_regex = re.compile("^cat", re.IGNORECASE | re.MULTILINE)
Java
Som en del av (?m) inline-modifiern har Java MULTILINE-alternativet. Du kan till exempel använda:
Pattern catRegex = Pattern.compile( "^cat", Pattern.CASE_INSENSITIVE | Pattern.MULTILINE );
JavaScript
I JavaScript är ditt enda alternativ att lägga till m-flaggan efter mönsterets avslutande avgränsare. Du kan till exempel använda:var catRegex = /^cat/m;
(direktlänk)
Free-Spacing: x (utom JavaScript)
Som standard anger varje mellanslag i en regexsträng ett tecken som ska matchas. I språk där du kan skriva regexsträngar på flera rader anger radbrytningarna även bokstavliga tecken som ska matchas. Eftersom du inte kan sätta in mellanslag för att separera grupper som har olika betydelser (som du gör mellan fraser och pragrafer när du skriver på engelska) kan en regex bli svårläst, som till exempel Meaning of Life-regex från regex-humor-sidan:^(?=(?!(.))()(?-1)(?<!\d(?<=(?!)\d))).$
Glans nog har många motorer stöd för ett läge med fritt mellanslag som gör det möjligt för dig att lufta din regex. Du kan till exempel lägga till mellanslag mellan symbolerna. I PHP kan du skriva så här – notera x-flaggan efter den sista avgränsaren ~:
$word_with_digit_and_cap_regex = '~ ^ (?=\D*\d) \w*\w* $ ~x';
Men varför stanna på en rad? Du kan sprida din regex över så många rader som du vill – med indentering och kommentarer – som inleds med ett #. I C# kan du till exempel göra något liknande:
var wordWithDigitAndCapRegex = new Regex(@"(?x) # Free-spacing mode ^ # Assert that position = beginning of string ######### Lookahead ########## (?= # Start lookahead \D* # Match any non-digits \d # Match one digit ) # End lookahead ######## Matching Section ######## \w* # Match any word chars # Match one upper-case letter \w* # Match any word chars $ # Assert that position = end of string");
Detta läge kallas free-spacing-läge. Du kan också se det kallas whitespace mode, comment mode eller verbose mode.
Det kan vara överdrivet i en enkel regex som den ovan (även om alla som måste underhålla din kod kommer att tacka dig för det). Men om du bygger ett seriöst regexmönster som det i tricket för att matcha siffror i klartext… Om du inte är masochist har du inget val.
Bemärk att inom en teckenklass är mellanslagstecknet och # (som annars introducerar kommentarer) fortfarande hedrade – utom i Java, där båda måste undvikas om du vill matcha dessa tecken.
För flera motorer finns det två sätt att aktivera läget för fritt avstånd: som en inline-modifierare eller som ett alternativ i regex-metoden eller -funktionen.
Läget för fritt avstånd är underbart, men det finns ett par mindre faror som du bör vara medveten om, eftersom de kan få dig att klia dig i huvudet och undra varför ett mönster inte fungerar som du förväntar dig.
Trip Hazard #1: The Meaning of Space
För det första kan du inte längre använda Number: \d+ för att matcha en sträng som Nummer: 24. Anledningen är att mellanslag i : \d inte längre matchar ett mellanslag. Vi är i läget för fritt mellanslag, kommer du ihåg? Det är hela poängen.
För att matcha ett mellanslagstecken måste du ange det. De två huvudsakliga sätten att göra det är att placera det inom en teckenklass eller att undkomma det med ett backslash. Båda dessa skulle fungera: Nummer:\d+ eller Nummer:\ \ \d+
Nummer:\s\d+ skulle naturligtvis också matcha, men kom ihåg att \s matchar mycket mer än ett mellanslagstecken. Det kan till exempel matcha en tabb eller ett radbrytningstecken. Detta kanske inte är vad du vill ha.
Trip Hazard #2: Late Start
För det andra kan du bli övermodig i kraften hos friutrymning och försöka något som detta för att låta regexet stå på egna ben:
var wordWithDigitAndCapRegex = new Regex(@" (?x) # Free-spacing mode ^ # Beginning of string etc # Match the literal chars e,t,c");
Problemet med detta är att även om det kan se ut som om modifieringsfaktorn för friutrymning (?x) är det första i din regex, men det är det inte.
Efter det inledande dubbla citattecknet ” har vi ett radbyte och ett antal mellanslag. Motorn försöker matcha dessa, eftersom vi i det skedet ännu inte befinner oss i ett läge med fritt utrymme. Det läget aktiveras först när vi stöter på (?x). Detta regex kommer aldrig att matcha strängen etc and more, för när vi stöter på början av strängens ankare ^ ska vi redan ha matchat ett radbrytningstecken och mellanslagstecken!
Detta är anledningen till att om du tittar på det första exemplet kommer du att se att modifieringsmodifieringen för fritt mellanslag (?x) är det allra första som kommer efter det inledande citationstecknet.
Vitrymmen trimmas inte bara bort från mönstret
Även om vitrymmen ignoreras skiljer positionen för en vitrymmen fortfarande föregående token från nästa. Till exempel
✽ (A)\1 2 är inte samma sak som (A)\12. Den förstnämnda matchar AA2, den sistnämnda matchar A\n i .NET, PCRE, Perl och Ruby (12 är oktalkoden för linjetecknet)
✽ \p{Nd} är giltigt, men \p{N d} är inte giltigt – utom i Perl och Ruby
JavaScript
JavaScript har inte stöd för läget med fritt mellanrum. I JavaScript kan du använda en konstruktion som . Denna teckenklass matchar ett tecken som antingen är en icke-siffra \D eller en siffra \d. Därför matchar den alla tecken.
En annan JavaScript-lösning är att använda XRegExp-regexbiblioteket. Om du har oändligt med tid kan du också försöka anpassa PCRE till JavaScript med hjälp av Emscripten, vilket Firas verkar ha gjort på regex 101.
Inline Modifier (?s)
I .NET, PCRE (C, PHP, R…), Perl, Python, Java och Ruby (men inte JavaScript) kan du använda inline-modifiern (?x), till exempel är detta ett luftigt regex för att matcha upprepade ord:(?x) (\w+) + \bSe även avsnittet om inline-modifierare.
.NET
Avstånd från (?x) inline-modifieraren har .NET-språken alternativet IgnorePatternWhitespace. I C# kan du till exempel använda:
var repeatedWordRegex = new Regex(@" (\w+) + \b", RegexOptions.IgnorePatternWhitespace );
Perl
Perl
Förutom (?x) inline-modifieraren kan du i Perl lägga till x-flaggan efter mönsterets avslutande avgränsare. Du kan till exempel använda:if ($the_subject =~ m/(\w+) + \b/x) { … }
PCRE (C, PHP, R…)
Pre låter dig, förutom (?x) inline-modifiern, ställa in PCRE-läget PCRE_EXTENDED när du anropar funktionen pcre_compile() (eller liknande):
repeated_word_regex = pcre_compile( "(\w+) + \b", PCRE_EXTENDED, &error, &erroroffset, NULL );
I PHP överförs PCRE_EXTENDED-alternativet via x-flaggan, som du kan lägga till i din regexsträng efter den avslutande avgränsaren. Du kan till exempel använda:$repeated_word_regex = '~(\w+) + \b~x';
Python
Python har förutom inline-modifiern (?x) alternativet VERBOSE. Till exempel kan du använda:repeated_word_regex = re.compile(r"(\w+) + \b", re.VERBOSE)
Java
I motsats till andra motorer ignoreras hash-tecken i en Java-teckenklass som introducerar kommentarer och mellanslag, så du måste undkomma dem om du vill använda dessa tecken i en klass, t.ex. +
Som undantag för (?x) inline-modifiern har Java alternativet COMMENTS. Du kan till exempel använda:
Pattern repeatedWordRegex = Pattern.compile( "(\w+) + \1\b", Pattern.COMMENTS );
Ruby
Med Ruby kan du förutom (?x) inline-modifiern lägga till x-flaggan i slutet av din regex-sträng. Du kan till exempel använda:repeated_word_regex = /(\w+) + \b/x
(direktlänk)
Andra modifieringar
Vissa motorer har stöd för modifieringar och flaggor utöver i, s, m och x. Jag planerar att ta upp dessa på de sidor som ägnas åt dessa varianter.
Till exempel har
✽ .NET modifieringen (?n) (som också är tillgänglig via alternativet ExplicitCapture). Detta förvandlar alla (parenteser) till icke-fångstbara grupper. För att fånga måste du använda namngivna grupper.
✽ Java har modifikationen (?d) (även tillgänglig via alternativet UNIX_LINES). När den är aktiverad är det endast radmatningstecknet \n som påverkar pricken . (som inte matchar radbrytningar om inte DOTALL är på) och ankarna ^ och $ (som matchar radbörjar och -slut i flerradigt läge.)
✽ Perl har flera andra flaggor. Se avsnittet modifier i dokumentationen.
✽ PCRE har modifieringen (?J) (även tillgänglig i kod via alternativet PCRE_DUPNAMES). När den är inställd får olika fångstgrupper använda samma namn – även om de tilldelas olika nummer.
(direktlänk)
✽ PCRE har modifikatorn (?U) (även tillgänglig i koden via alternativet PCRE_UNGREEDY). När den är inställd är kvantifierare som standard obearbetade. Om man lägger till ett ? blir de giriga.
(direktlänk)
✽ PCRE har modifikationen (?X) (även tillgänglig i koden via alternativet PCRE_EXTRA). Historiskt sett har detta läge använts för att aktivera nya funktioner under utveckling. För närvarande utlöser det fel om tokens som \B används i en teckenklass (där det normalt matchar storbokstaven B, till skillnad från utanför en teckenklass, där det är en not-a-word-boundary assertion).
✽ PCRE har ett antal speciella modifierare som kan ställas in i början av mönstret (dessa visas nedan). Dessutom kan många alternativ skickas till funktionsfamiljen pcre_compile(), om du har tillgång till dem. För detaljer om dessa, hämta pcre_compile.html från doc-mappen genom att ladda ner PCRE.
(direktlänk)
PCRE’s Special Start-of-Pattern Modifiers
PCRE har ett antal ”specialmodifierare” som du kan ställa in i början av ett mönster. Istället för standardsyntaxen (?z) för inline-modifier ser syntaxen för specialmodifier ut som (*MYMODIFIER). Dessa modifierare är särskilt användbara i sammanhang där PCRE är integrerad i ett verktyg eller ett språk – eftersom de ersätter ett antal alternativ som du skulle skicka till pcre_compile().
UTF-strängar
Antagen att PCRE kompileras med relevanta alternativ kan du instruera motorn att behandla ämnessträngen som olika typer av UTF-strängar.
✽ (*UTF) är ett generiskt sätt att behandla ämnessträngen som en UTF-sträng – det känner av om den ska behandlas som UTF-8, UTF-16 eller UTF-32.
✽ (*UTF8), (*UTF16) och (*UTF32) behandlar strängen som en av tre specifika UTF-kodningar.
Unicode-egenskaper för \d och \w
Som standard matchar \d endast ASCII-siffror, medan \w endast matchar ASCII-siffror, bokstäver och understrykningar.
Med modifikatorn (*UCP) (som står för Unicode Character Properties) kan dessa tokens matcha Unicode-siffror och ordtecken.
Till exempel: (*UCP)\d+ :: \w+ matchar 1۳۲١८৮੪ :: Aれま래도ᚠᚱᚩ
(Se demo).
I kombination med (*UCP) kan du också behöva använda en av (*UTF) modifieringarna. För att se hur detta fungerar, titta på resultatet av detta program med en standard Xampp PHP:
$string = '1۳۲١८৮੪ :: Aれま래도ᚠᚱᚩ';$utfregex = "~\d+ :: \w+~";$utfregex = "~(*UCP)\d+ :: \w+~";$utfregex = "~(*UTF)(*UCP)\d+ :: \w+~";$utfregex = "~(*UTF)\d+ :: \w+~";$utfregex = "~\d+ :: \w+~u";foreach (range(0, 4) as $i) { echo "$i: ".preg_match($utfregex,$string)."<br />"; }// Output:// 0: 0// 1: 0// 2: 1 => (*UTF)(*UCP)// 3: 0// 4: 1 => The u flag produces the same result as (*UTF)(*UCP)
Linjebrytningsmodifierare
Som standard, när PCRE kompileras, talar du om för PCRE vad den ska betrakta som ett linjeskifte när den stöter på en . (eftersom pricken den inte matchar linjeskiften såvida den inte är i läget dotall), liksom ^- och $-förankringarnas beteende i flerspråkigt läge. Du kan åsidosätta denna standardinställning med följande modifieringar:
✽ (*CR) Endast en vagnretur anses vara ett radbryt
✽ (*LF) Endast en radmatning anses vara ett radbryt (som i Unix)
✽ (*CRLF) Endast en vagnretur följt av en radmatning anses vara ett radbryt
✽ (*CRLF) Endast en radmatning anses vara ett radbryt. anses vara ett radbryt (som i Windows)
✽ (*ANYCRLF) Alla ovanstående tre anses vara ett radbryt
✽ (*ANY) Alla Unicode-nyrader anses vara ett radbryt
Till exempel, (*CR)\w+.\w+ matchar Line1\nLine2 eftersom pricken kan matcha \n, vilket inte anses vara ett radbryt. Se demo.
Kontroll av \R
Som standard matchar metatecknet \R varje Unicode-nyradsekvens. När UTF-8-läget är avstängt är dessa nyradsekvenser paret \r\n samt tecken för vagnretur, radmatning, vertikal tabulering, formmatning eller nästa rad. I UTF-8-läge matchar tokenet även linjeseparatorn och paragrafseparatortecknet.
Med två start-of-pattern-modifierare kan du ändra beteendet hos \R:
✽ Med (*BSR_ANYCRLF) matchar \R endast \r\n-sekvensen, \r eller \n. Detta kan också ställas in när PCRE kompileras eller begärs via alternativet PCRE_BSR_ANYCRLF
✽ Med (*BSR_UNICODE) matchar \R alla Unicode newline-sekvenser (och åsidosätter alternativet PCRE_BSR_ANYCRLF om det är inställt). Detta kan också ställas in när PCRE kompileras eller begäras via alternativet PCRE_BSR_UNICODE
Kontroll av löpande mönster
För att begränsa antalet gånger som PCRE anropar funktionen match() använder du modifiern (*LIMIT_MATCH=x) och ställer in x till det önskade antalet.
För att begränsa rekursion använder du (*LIMIT_RECURSION=d) och sätter d till den djupaste tillåtna rekursionsnivån.
Avstängning av optimeringar
(direktlänk)
Som standard studerar PCRE mönstret och gör automatiskt ett kvantifierat token atomärt när det följande tokenet är inkompatibelt – till exempel förvandlas A+X till A++X. Modifiern (*NO_AUTO_POSSESS) inaktiverar denna optimering. Använd detta när du vill använda pcretest för att jämföra två mönster och få dig själv att känna dig nöjd med alla cykler som auto-possessifieringen sparar dig.
Som standard utför PCRE flera optimeringar för att snabbare ta reda på om en matchning kommer att misslyckas. Modifiern (*NO_START_OPT) inaktiverar dessa optimeringar.
Inaktivera tomma träffar
I PCRE2 talar (*NOTEMPTY) om för motorn att inte returnera tomma träffar. På samma sätt talar (*NOTEMPTY_ATSTART) om för motorn att inte returnera tomma träffar som hittas i början av ämnet.
Disaktivera automatisk förankringsoptimering
I PCRE2 talar PCRE2_NO_DOTSTAR_ANCHOR om för motorn att inte automatiskt förankra mönster som börjar med .*
Du kan läsa mer om denna flagga på PCRE2 API-sidan (sök efter PCRE2_NO_DOTSTAR_ANCHOR).
och The Best Regex Trick Ever!!!
De 1001 sätten att använda Regex