I databehandling er et vanlig uttrykk eller vanlig uttrykk eller normalt uttrykk eller mønster en tegnstreng som beskriver, i henhold til en presis syntaks, et sett med mulige tegnstrenger. Regulære uttrykk kalles også regex (et portmanteau- ord dannet av engelsk regulært uttrykk ). Regelmessige uttrykk kommer fra matematiske teorier om formelle språk på 1940-tallet. Deres evne til å kortfattet beskrive regelmessige sett forklarer hvorfor de ble funnet i flere vitenskapelige felt i etterkrigsårene, og rettferdiggjør adopsjonen innen informatikk . Vanlige uttrykk brukes i dag til å programmere programvare med funksjoner for å lese, kontrollere, modifisere og analysere tekster så vel som i manipulering av formelle språk som dataspråk .
Disse regulære uttrykkene har kvaliteten i å kunne beskrives av formler eller mønstre, (på engelske mønstre ) mye enklere enn de andre måtene.
På 1940-tallet , Warren McCulloch og Walter Pitts beskrevet i nervesystemet ved å modellere neuroner ved enkel automata. I 1956 beskrev logikeren Stephen Cole Kleene disse modellene i form av vanlige sett og automater . Han anses å være oppfinneren av vanlige uttrykk. I 1959 tilbød Michael O. Rabin og Dana Scott den første matematiske og grundige behandlingen av disse konseptene, som ga dem Turingprisen i 1976.
I denne sammenheng tilsvarer regulære uttrykk type 3-grammatikk (se Formell grammatikk ) i Chomsky-hierarkiet ; de kan derfor brukes til å beskrive morfologien til et språk .
Ken Thompson implementert Kleene sin notasjon i QED redaktør , så ed redaktør i Unix, og til slutt i grep . Siden da har vanlige uttrykk blitt mye brukt i verktøy som lex samt programmeringsspråk født under Unix som expr , awk , Perl , Tcl , Python , etc.
Når man forlater det teoretiske rammeverket, har vanlige uttrykk fått funksjonalitet som muliggjør beskrivelse av ikke-rasjonelle språk. Et semantisk skifte har således skjedd: begrepet regulært uttrykk har ikke den samme betydningen i sammenheng med anvendt databehandling og i teorien om formelle språk.
Vanlig uttrykk | Beskrevne ord | Ord ikke beskrevet |
---|---|---|
oppdaget | "Oppdaget" | "Oppdaget", "oppdaget", "oppdaget", "" |
ex- (a? e | æ | é) quo | "Ex-equo", "ex-equo", "ex-aequo" og "ex-æquo" |
"Ex-quo", "ex-aiquo", "ex-aeko", "ex-æéquo" |
^ Seksjon. + | “Seksjon 1”, “Seksjon 22”, “Seksjon A”, ... |
"Se seksjon 1", " seksjon " |
$ 6,66 * | "6.6", "6.666", "6.6666", ... |
"6,66667", |
[1234567890] + (, [1234567890] +)? | "2", "42", "0.618", "49.3", ... |
"3,", ", 75", "" |
Opprinnelig opprettet for å beskrive formelle språk, brukes vanlige uttrykk i analyse og manipulering av dataspråk ; kompilatorer og tolker er altså basert på disse.
Brukt som tekstsøkverktøyene i et dokument, beskriver et regulært uttrykk strenger av tegn som har vanlige egenskaper, for å finne dem i en tekstblokk for å bruke en automatisert behandling, for eksempel et tillegg, erstatning, modifisering eller sletting.
Mange tekstredigerere og de fleste innebygde utviklingsmiljøer støtter vanlige uttrykk. Et stort antall Unix- verktøy vet hvordan de skal brukes naturlig. De mest kjente er GNU grep eller GNU sed som, i likhet med tekstredigerere, bruker disse uttrykkene for automatisk å bla gjennom et dokument på jakt etter tekstbiter som er kompatible med søkemønsteret, og muligens for å legge til, erstatte eller slette.
De kommandolinje-grensesnitt (eller skall ) bruker et beslektet, men separat system og mindre uttrykks kalt glob (en) eller globbing.
Vanlige uttrykk brukes ofte i systemadministrasjon , programvareutvikling og naturlige språkbehandlingsaktiviteter . De så et nytt bruksområde med utvikling av Internett , og spredning av ondsinnet kode eller spam- meldinger . Av filtre og roboter som bruker disse uttrykkene, brukes til å oppdage potensielt skadelige gjenstander.
I formell språkteori er et vanlig uttrykk et uttrykk som representerer et rasjonelt språk . I denne sammenheng har regulære uttrykk en mer begrenset uttrykkskraft: denne forestillingen har en bredere betydning i anvendt databehandling enn i formell språkteori.
Et vanlig uttrykk er en serie typografiske tegn (som mer enkelt kalles "mønster" - " mønster " på engelsk) som beskriver et sett med tegnstrenger . For eksempel kan ordsettet "bundet, bundet, bundet og bundet" kondenseres til et enkelt mønster "ex- (a? E | æ | é) quo". De grunnleggende mekanismene for å danne slike uttrykk er basert på spesialtegn av substitusjon, gruppering og kvantisering.
En loddrett linje skiller vanligvis to alternative uttrykk: "equo | aequo" betegner enten equo eller aequo. Det er også mulig å bruke parenteser til å definere feltet og prioriteten til deteksjonen, "(ae | e) quo" som betegner det samme settet som "aequo | equo" og å kvantifisere gruppene som er tilstede i mønsteret ved å legge til kvantiseringstegn til retten til disse grupperingene.
De vanligste kvantifiseringsmengdene er:
Symboler med spesiell semantikk kan kalles "operatorer", "metategn" eller "spesialtegn". Tegn som bare representerer seg selv kalles "bokstavelige".
Regulære uttrykk kan kombineres, for eksempel ved sammenføyning , for å produsere mer komplekse regulære uttrykk.
Når en streng med tegn samsvarer med beskrivelsen gitt av det regulære uttrykket, sier vi at det er en "samsvar" mellom strengen og mønsteret, eller at mønsteret "samsvarer" med strengen. Denne korrespondansen kan gjelde hele eller deler av tegnstrengen. For eksempel i setningen “De to lagene var uavgjort og hilste på hverandre. ", Understrengen" ex-æquo "matches av mønsteret" ex- (a? E | æ | é) quo ".
Som standard regulære uttrykk er case sensitive . Når det er mulig, prøver de å matche det største underlaget som tilsvarer mønsteret: de sies å være "grådige". Aa+Gjenkjenner for eksempel hele strengen "Aaaaaaa" i stedet for en del "Aaa" (gluttony), men den gjenkjenner ikke strengen "aaaA" (store og små bokstaver).
Operatører | Beskrivelse | Eksempler | ||
---|---|---|---|---|
Vanlig uttrykk | Beskrevne kjeder | Kanaler ikke beskrevet | ||
ekspr 1 ekspr 2 | Sammenkoblingsoperatør av to uttrykk (implisitt). | ab | "Ab" | "A", "b", tom streng |
. | En karakter og en | . | "A", "b" osv. | tom streng, "ab" |
uttrykk ? | Denne kvantifisereren tilsvarer det som går foran, presentere null eller en gang . Hvis det finnes flere treff i en tekst, finner den først de som er plassert øverst i teksten, og returnerer så størst mulig lengde fra den opprinnelige posisjonen. | på? | tom streng, "a" | "Aa", "b" |
uttrykk + | Denne kvantifisereren tilsvarer det som går foran den, gjentatt en eller flere ganger . Hvis det finnes flere treff i en tekst, finner den først de som er plassert øverst i teksten, og returnerer så størst mulig lengde fra den opprinnelige posisjonen. | a + | "A", "aa", "aaaaa" osv. | tom streng, "b", "aaab" |
uttrykk * | Denne kvantifisereren tilsvarer det som går foran den, gjentatt null eller flere ganger . Hvis det finnes flere treff i en tekst, finner den først de som er plassert øverst i teksten, og returnerer så størst mulig lengde fra den opprinnelige posisjonen. | på* | tom streng, "a", "aaa", og så videre. | "B", "aaab" |
eks. 1 | uttrykk 2 | Det er operatøren å velge mellom flere alternativer, det vil si settforeningen. Det kan kombineres så mange ganger som nødvendig for hvert av de mulige alternativene. Det samsvarer med et av uttrykkene som er plassert før eller etter operatøren . Disse uttrykkene kan valgfritt være tomme, og så (x |) tilsvarer x? | a | b | "A", "b" | tom streng, "ab", "c" |
[ liste ] | En av tegnene i parentes ("karakterklasse") | [a e i o u] | "A", "e", "i" osv. | tom streng, "b", "ae" |
[^ liste ] | Et tegn som ikke er i hakeparentes ("karakterklasse") | [^ aeiou] | "B" osv. | tom streng, "a", "bc" |
( uttrykk ) | Gruppere uttrykket i parentes | (oppdaget) | "Oppdaget" | "Oppdaget", "oppdaget", "oppdaget" |
uttrykk { n } | Nøyaktig n forekomster av uttrykket som går foran tannregulering | en {3} | "Aaa" | "Aa", "aaaa" |
uttrykk { n , m } | Mellom n og m forekomster av uttrykket foran tannregulering | a {2.4} | "Aaa", "aaa", "aaaa" | "A", "aaaaa" |
uttrykk { n ,} | I det minste n forekomster av uttrykket som går foran tannregulering | en {3,} | "Aaa", "aaaa", "aaaaa" osv. | "Aa" |
^ | Dette predikatet tilsvarer ikke noe tegn, men løser en nødvendig tilstand som gjør det mulig å finne enighet om hva som følger det ved å indikere at det må være i begynnelsen av en linje (altså være i begynnelsen av inngangsteksten eller etter en linjeskift) . Det kan ikke betraktes slik på begynnelsen av det vanlige uttrykket, andre steder blir det betraktet som bokstavelig. Det gjelder som en betingelse for resten av det regulære uttrykket (og gjelder derfor alle alternativene som er representert). | ^ a finner "a" i begynnelsen av linjen, men ikke i "ba". | ||
$ | Dette predikatet samsvarer ikke med noe tegn, men løser en nødvendig betingelse som gjør det mulig å finne en avtale om hva som går foran det ved å indikere at det må være på slutten av en linje (altså være på slutten av inngangsteksten eller rett før et linjeskift) . Det kan ikke betraktes slik på slutten av det vanlige uttrykket, andre steder blir det betraktet som bokstavelig. Det gjelder som en betingelse for resten av det regulære uttrykket (og gjelder derfor alle alternativene som er representert). | a $ finner "a" på slutten av linjen, men ikke i "ab". |
I informatikk kalles et verktøy for å manipulere regulære uttrykk en motor for regulært uttrykk eller motor for vanlig uttrykk . Det er standarder for å sikre konsistens i bruken av disse verktøyene.
POSIX- standarden tilbyr tre sett med standarder:
Vanlige uttrykk i perl er også en de facto standard på grunn av deres uttrykksfulle rikdom og kraft. Mens de følger sin egen utvikling, er de for eksempel opprinnelsen til PCRE- biblioteket . ECMAScript foreslår også i dokumentet Standard ECMA-262 en standard som brukes for eksempel av JavaScript .
Notasjoner eller deres semantikk kan variere litt fra en motor med vanlig uttrykk til en annen. De kan bare delvis eller delvis overholde disse standardene, eller tilby sine egne funksjoner, for eksempel GNU eller .NET Framework . Spesifikasjonene for hver diskuteres senere i denne artikkelen.
En karakterklasse er et sett med tegn. Det kan defineres på forskjellige måter:
Forbund av karakterklasser kan lages: [0-9ab]betegner settet som består av tegnene "0" til "9" og bokstavene "a" og "b". Noen biblioteker lar deg også krysse karakterklasser.
Mellom firkantede parenteser tolkes metategnene bokstavelig: [.?*]betegner settet som består av tegnene. ","? "Og" * ".
De mest brukte karakterklassene leveres vanligvis med motoren med vanlig uttrykk. En oversikt over disse klassene er laget i tabellen nedenfor.
POSIX-biblioteket definerer klasser innledningsvis for ASCII og deretter, for utvidelse, for andre former for tegnkoding, avhengig av lokalitet .
I Unicode og språk som perl defineres sett med tegn gjennom forestillingen om karakteregenskaper. Dette gjør det mulig å angi et sett med tegn i henhold til deres kategori (eksempler: bokstav, åpningstegn, lukket tegnsetting, skilletegn, kontrolltegn), i henhold til skriveretningen (for eksempel fra venstre til høyre eller fra høyre til venstre), avhengig av alfabetet (eksempler: latin, kyrillisk, gresk, Hiragana); i henhold til blokkallokering, eller til og med i henhold til de samme prinsippene som POSIX-tegnklassene (om dette emnet, les seksjonen Regular expressions and Unicode ).
POSIX | Ikke standard | perl, Python | Vim | Java | Unicode | ASCII | Beskrivelse |
---|---|---|---|---|---|---|---|
\p{ASCII} | [\x00-\x7F] | ASCII- tegn | |||||
[:alnum:] | \p{Alnum} | A-Za-z0-9 | Alfanumeriske tegn | ||||
[:word:] | \w | \w | \w | A-Za-z0-9_ | Alfanumeriske tegn og "_" | ||
\W | \W | \W | ^A-Za-z0-9_ | Tegn som ikke utgjør ord | |||
[:alpha:] | \a | \p{Alpha} | \p{L} eller \p{Letter} | A-Za-z | Alfabetiske tegn | ||
[:blank:] | \s | \p{Blank} | \t | Mellomrom og fane | |||
\b | \< \> | \b | (?<=\W)(?=\w)|(?<=\w)(?=\W) | Begynnelses- og sluttposisjoner av ord | |||
\B | \B | (?<=\W)(?=\W)|(?<=\w)(?=\w) | Posisjoner som ikke tilsvarer begynnelsen eller slutten av et ord | ||||
[:cntrl:] | \p{Cntrl} | \p{Cc} eller \p{Control} | \x00-\x1F\x7F | Kontroll tegn | |||
[:digit:] | \d | \d | \p{Digit} eller \d | \p{Nd} eller \p{Decimal_Digit_Number} | 0-9 | Desimaltegn | |
\D | \D | \D | \P{Nd} eller \P{Decimal_Digit_Number} | ^0-9 | Noe annet enn et desimal | ||
[:graph:] | \p{Graph} | \x21-\x7E | Synlige tegn | ||||
[:lower:] | \l | \p{Lower} | \p{Ll} eller \p{Lowercase_Letter} | a-z | Små bokstaver | ||
[:print:] | \p | \p{Print} | \x20-\x7E | Utskrivbare tegn | |||
[:punct:] | \p{Punct} | \p{P} eller \p{Punctuation} | ][!"#$%&'()*+,./:;<=>?@\^_`{|}~- | Tegnsettingstegn | |||
[:space:] | \s | \_s | \p{Space} eller \s | \p{Z} eller \p{Separator} | \t\r\n\v\f | Romkarakterer | |
\S | \S | \S | \P{Z} eller \P{Separator} | ^ \t\r\n\v\f | Noe annet enn et romkarakter | ||
[:upper:] | \u | \p{Upper} | \p{Lu} eller \p{Uppercase_Letter} | A-Z | Store bokstaver | ||
[:xdigit:] | \x | \p{XDigit} | A-Fa-f0-9 | Heksadesimale sifre | |||
\A | Start av karakterstreng | ||||||
\Z | Slutten på karakterstrengen |
I POSIX-standarden [[:upper:]ab]samsvarer for eksempel et tegn blant settet dannet av store og små bokstaver "a" og "b". I ASCII-standarden ville dette regulære uttrykket bli skrevet [A-Zab].
Begrepet ekvivalensklasse skal ikke forveksles med forestillingen om karakterklasse.
For eksempel, i FR-området, grupperer klassen [= e =] alle bokstavene {e, é, è, ë, ê}.
Dette betyr at når de er sortert, vises bokstavene {e, é, è, ë, ê} i samme tegnsett, etter d og før f .
De fleste standarder og regulære uttrykksmotorer tilbyr avanserte funksjoner. Spesielt :
Notasjonene som brukes er veldig varierende. Dette kapitlet samler på den ene siden notasjonene som er spesifikke for forskjellige implementeringer, og på den andre siden standardiseringsselskapet.
POSIX- standarden har søkt å avhjelpe spredningen av syntaks og funksjonalitet ved å tilby en standard med konfigurerbare regulære uttrykk. Du kan få en oversikt ved å lese manualen for regexmange Unix- dialekter, inkludert GNU / Linux . Selv denne standarden inkluderer imidlertid ikke all funksjonaliteten som legges til Perl-regulære uttrykk.
Til slutt legger POSIX til støtte for plattformer som bruker et ikke-ASCII-basert tegnsett, spesielt EBCDIC , og delvis lokal støtte for noen metategn.
Grunnleggende regulære uttrykkVerktøy i Unix- verdenen som sed , GNU grep , ed eller vi bruker BRE (“ Basic Regular Expression ”) -standarden til POSIX som standard . I den, seler, parenteser, symbolet "? "Og" + "-symbolet er ikke metategn: de representerer bare seg selv. For å ta semantikken fra metategn, må de unnslippes med "\" -symbolet.
Eksempel: det regulære uttrykket samsvarer med (ab.)+"(abc) +", men ikke "abcabd", som er \(ab.\)\+egnet for.
Utvidede regulære uttrykkPOSIX Extended Regular Expression (ERE ) støttes ofte i verktøy for Unix- og GNU / Linux-distribusjoner ved å inkludere -E- flagget i kommandolinjeanropet til disse verktøyene. I motsetning til grunnleggende regulære uttrykk, kjenner de igjen tegn som tidligere ble sett på som metategn. De må derfor rømmes for å tolkes bokstavelig.
De fleste eksemplene som er gitt her er POSIX utvidede regulære uttrykk.
Escape sekvenserSom figurene (, ), [, ], ., *, ?, +, ^, |, $, -og \blir brukt som spesielle symboler, bør de som inngår i en avbruddssekvens hvis de blir bokstavelig talt betegne de tilsvarende karakter. Dette gjøres ved å gi dem en tilbakeslag \.
Lignende utvidelser brukes i emacs- editoren , som bruker et annet sett med kommandoer fra POSIX-standarden; men bruker de samme regulære uttrykkene med en utvidet notasjon. De utvidede regulære uttrykkene støttes nå også i vim , den forbedrede versjonen av vi .
Utvidet operatør (ikke POSIX) | Beskrivelse | Eksempel |
---|---|---|
\{m,n\} | I utvidet notasjon skaper dette en egendefinert begrenset kvantifiser, slik at m kan matche nøyaktig n forekomster av ovennevnte, der m og n er to heltall slik at m < n . En av de to parametrene kan utelates: hvis den første parameteren m er utelatt, er den som standard 0; hvis den andre parameteren n er utelatt, men kommaet er til stede, anses det å være uendelig; hvis den andre parameteren n er utelatt i tillegg til skillet mellom komma, tar den standardverdien lik den første parameteren m . | Se eksempler nedenfor. |
\( \) | I utvidet notasjon brukes grupperingsparenteser (i en rømningssekvens) for å avgrense et sett med alternativer, eller et hvilket som helst vanlig underuttrykk (unntatt start- og sluttlinjevilkår) for å bruke en kvantifier. I tillegg avgrenser disse parentesene en nummerert fangstgruppe som kan brukes til erstatninger (vi refererer deretter til de fangede gruppene i erstatningskjeden med hvor n er fangstgruppenummeret mellom 1 og 9, og hele kjeden er representert av ). $n$& | Se eksempler nedenfor. |
I tillegg blir mange andre rømningssekvenser lagt til for å betegne forhåndsdefinerte karakterklasser. De er spesifikke for hvert verktøy eller noen ganger varierer i henhold til versjonen eller plattformen (men de har vært stabile i lang tid i emacs som var en forløper for disse utvidelsene, som andre forfattere delvis har implementert på en begrenset måte eller annerledes).
Python bruker regulære uttrykk basert på POSIX regulære uttrykk, med noen utvidelser eller forskjeller.
De POSIX-kompatible artiklene er som følger:
Sekvensen \bangir tilbaketastetegnet ( 0x08med ASCII-kompatibel koding) når det brukes i en tegnklasse, og ellers grensen til et ord.
Den BSD operativsystem bruker regex bibliotek er skrevet av Henry Spencer . Dette biblioteket er kompatibelt med POSIX 1003.2-standarden og brukes også av MySQL (med REGEXP- og NOT REGEXP-operatører) og PostgreSQL (med “~” -operatøren og dens varianter).
Den vanlige uttrykksmotoren til Tcl- språket kommer fra utviklingen av Henry Spencer etter BSD-biblioteket. Regulære uttrykk kalles Advanced Regular Expressions (eller ARE) og er litt forskjellige fra de utvidede regulære uttrykkene i POSIX. Grunnleggende og utvidede regulære uttrykk støttes også.
I motsetning til andre motorer fungerer denne på PLC-basis, noe som gjør det mindre effektivt når det er nødvendig å fange eller spore , men ellers mer effektivt.
Perl tilbyr et spesielt rikt sett med utvidelser. Dette programmeringsspråket er veldig vellykket på grunn av tilstedeværelsen av operatører med vanlige uttrykk som er inkludert i selve språket. Utvidelsene den tilbyr er også tilgjengelig for andre programmer under navnet lib PCRE ( Perl-Compatible Regular Expressions , bokstavelig talt bibliotek med regulære uttrykk som er kompatible med Perl ). Dette biblioteket ble opprinnelig skrevet for Exim- postserveren , men blir nå overtatt av andre prosjekter som Python , Apache , Postfix , KDE , Analog , PHP og Ferite .
Perl 6- spesifikasjonene regulerer og utvider mekanismen til systemet for regulært uttrykk. Dessuten er det bedre integrert i språket enn i Perl 5. Kontrollen av avkastningen på spor er veldig fin der. Perl 6s regex-system er kraftig nok til å skrive parsere uten å bruke parser- plugins. Regulære uttrykk er en form for underrutiner og grammatikk er en form for klasse . Mekanismen er implementert i Parrot assembler av PGE- modulen i Parrot implementeringen av Perl 6 og i Haskell i Pugs implementeringen . Disse implementeringene er et viktig skritt i å bygge en komplett Perl 6- kompilator . Noen av funksjonene i Perl 6 regexp, som navngitte opptak, er innebygd siden Perl 5.10.
PHP støtter to former for notasjoner: POSIX- syntaksen (POSIX 1003.2) og den, mye rikere og mer effektiv, av PCRE- biblioteket (Perl Compatible Regular Expression).
En av feilene som ble kritisert i PHP, er relatert til den begrensede støtten for tegnstrenger, selv om den hovedsakelig brukes til å behandle tekst, siden tekst bare kan vises i et sett med tegn kodet på 8 bits, uten å kunne spesifisere tydelig hvilken koding brukes. I praksis er det derfor nødvendig å legge til PHP-støttebiblioteker for koding og dekoding av tekster, om bare for å representere dem i UTF-8. Imidlertid, selv i UTF-8, oppstår problemet umiddelbart med semantikken til regulære uttrykk, siden tegnene da har en koding med variabel lengde, noe som krever å gjøre regulære uttrykk mer komplekse. Valgfrie PHP-utvidelser er derfor utviklet for å opprette en ny datatype for tekst, for å gjøre det lettere å behandle den (og til slutt være kompatibel med Perl6 som, i likhet med Haskell , vil ha full Unicode-støtte).
ICU definerer et bærbart bibliotek for internasjonal tekstbehandling. Dette er først utviklet på C-språk (versjon kalt ICU4C) eller for Java-plattformen (versjon kalt ICU4J). Porter (eller tilpasninger) er også tilgjengelige på mange andre språk, ved hjelp av biblioteket som er utviklet for C (eller C ++ ) språk .
Regulære uttrykk som kan brukes på ICU har karakteristikkene til regulære uttrykk i Perl, men supplerer dem for å gi dem full støtte for Unicode-tegnsettet (se neste avsnitt for spørsmål om standardiseringen som fortsatt er i gang). De avklarer også betydningen ved å lage regelmessige uttrykk uavhengig av det kodede tegnsettet som brukes i dokumenter, siden Unicode-tegnsettet brukes som den interne pivotkodingen.
Dette er fordi Perl (eller PCRE) regulære uttrykk ikke er bærbare for behandling av dokumenter ved bruk av forskjellige kodede tegnsett, og de støtter heller ikke riktig tegnsett med multibyte (variabel lengde) som ISO 2022 , Shift-JIS eller UTF-8 ) , eller kodet på en eller flere binære enheter på mer enn 8 bits (for eksempel UTF-16 ) siden den faktiske kodingen av disse settene som sekvenser av byte avhenger av plattformen. -form brukt for behandling (rekkefølge for lagring av byte i en ord på mer enn 8 biter).
ICU løser dette ved å vedta prosessering som internt bruker et enkelt 32-bits sett og støtter det fulle universelle tegnsettet (UCS), som definert i ISO / IEC 10646 og semantisk spesifisert i Unicode- standarden. (Som legger til standarden støtten til informative eller normative egenskaper på tegn, og anbefalinger for automatisk tekstbehandling, noen av disse anbefalingene er valgfrie eller informative, andre har blitt standard og integrert i selve Unicode-standarden, andre har endelig fått status som internasjonal standard på ISO eller nasjonal standard i visse land).
ICU støtter følgende utvidelser, direkte i regulære uttrykk, eller i regulært uttrykk for en karakterklasse (mellom […]):
ICU-regulære uttrykk er for tiden blant de mest kraftfulle og uttrykksfulle innen flerspråklig dokumentbehandling. De er i stor grad grunnlaget for (fremdeles pågående) standardisering av Unicode-regulære uttrykk (se nedenfor), og et delsett støttes naturlig i standard Java- språkbibliotek (som internt bruker et bærbart tegnsett til variabel koding, basert på UTF-16 med utvidelser, og hvis kodingsenheter er 16 bits).
ICU er et bibliotek i stadig utvikling. I prinsippet bør den vedta alle utvidelsene som er kunngjort i Perl (inkludert navngitte opptak), for å sikre interoperabilitet med Perl 5, Perl 6 og PCRE, og det økende antall andre språk som bruker denne. Utvidet syntaks, og forfatterne av ICU og Perl jobber sammen for å definere en felles notasjon. Imidlertid vedtar ICU primært utvidelsene som er tatt i bruk i regulære uttrykk beskrevet i Unicode Standard, siden ICU fungerer som hovedreferanse i dette Unicode Standardvedlegget.
Imidlertid er det foreløpig ingen standard eller teknisk standard for å ta opp noen viktige aspekter av regulære uttrykk i en flerspråklig sammenheng, inkludert:
For å avklare disse sistnevnte manglende aspektene, bør flere metategn kunne brukes til å kontrollere eller filtrere forekomstene som er funnet, ellers en standardisert ordre pålagt listen over hendelser som returneres. Søknadsforfattere må derfor være årvåken på disse punktene og sørge for å lese alle forekomstene og ikke bare de første, for å kunne bestemme hvilken av hendelsene som er mest hensiktsmessig for en gitt operasjon.
Vanlige uttrykk ble opprinnelig brukt med ASCII- tegn . Mange regulære uttrykksmotorer kan nå håndtere Unicode . På mange måter utgjør det kodede tegnsettet ingen forskjell, men det oppstår noen problemer med å utvide vanlige uttrykk for Unicode.
Et spørsmål er hvilket internt Unicode-representasjonsformat som støttes. Alle kommandolinjemotorer med regulært uttrykk forventer UTF-8 , men for biblioteker forventer noen også UTF-8, men andre forventer bare et UCS-2-kodet spill (eller til og med UTF-16- utvidelsen som også begrenser gyldige sekvenser), eller på UCS- Bare 4 (se den standardiserte UTF-32- begrensningen ).
Et andre spørsmål er om hele verdiområdet for en versjon av Unicode støttes. Mange motorer støtter bare Basic Multilingual Plane , det vil si 16-biters kodbare tegn. Bare noen få motorer kan (fra 2006) håndtere 21-biters Unicode-verdiområder.
Et tredje spørsmål er hvordan ASCII-konstruksjoner utvides til Unicode.
I praksis er dette imidlertid ofte ikke tilfelle:
Et annet område der det finnes variasjoner er tolkningen av saksfølsomhetsindikatorer.
Et annet svar på Unicode var introduksjonen av tegnklasser for Unicode-blokker og generelle egenskaper til Unicode-tegn:
Merknader:
Det er minst tre familier av algoritmer som avgjør om en streng samsvarer med et vanlig uttrykk.
Den eldste tilnærmingen, kalt eksplisitt, er avhengig av oversettelsen av det regulære uttrykket til en deterministisk endelig automat (DFA). Konstruksjonen av en slik automat for et regelmessig uttrykk for størrelse m har en kompleksitet i størrelse og i minne i O (2 m ), men kan utføres på en streng av størrelse n på en tid O (n) .
En alternativ tilnærming, kalt implisitt, består i å simulere en ikke-deterministisk endelig automat ved å bygge hver AFD på farten og kvitte seg med den i neste trinn. Denne tilnærmingen unngår den eksponentielle kompleksiteten til den forrige tilnærmingen, men utførelsestiden øker i O (mn) . Disse algoritmene er raske, men visse funksjonaliteter som gjenfangst av underlag og ikke-grådig kvantisering er vanskelig å implementere.
Den tredje tilnærmingen består i å sammenligne mønsteret med karakterstrengen ved separasjon og evaluering (" backtracking "). Dens algoritmiske kompleksitet er i verste fall eksponentiell, for eksempel med mønstre som (a|aa)*b, men gir gode resultater i praksis. Den er mer fleksibel og gir større uttrykksevne, for eksempel ved å forenkle gjenfangingen av underlag.
Noen implementeringer prøver å kombinere kvalitetene til forskjellige tilnærminger, starte søket med en AFD, og deretter bruke separasjon og evaluering når det er nødvendig.