Регулярлы өрнектер: іздеу үлгілерінің тарихы мен қолданысы

Кіріспе

Іздеу үлгісін құрайтын таңбалар тізбегі. Регулярлы өрнек (regex немесе regexp деп қысқартылады), кейде рационалды өрнек деп те аталады, – мәтінде сәйкес келетін үлгіні анықтайтын таңбалар тізбегі. Мұндай үлгілер көбінесе жол іздеу алгоритмдерімен "іздеу" немесе "іздеу және алмастыру" операциялары үшін, немесе деректерді тексеру үшін қолданылады. Регулярлы өрнектер әдістемелері теориялық информатика және формальді тілдер теориясында жасалған. Регулярлы өрнектер тұжырымы 1950 жылдары американдық математик Стивен Коул Клин регулярлы тіл тұжырымын ресми түрде қалыптаған кезде пайда болды. Олар Unix мәтіндік өңдеу құралдарымен кеңінен қолданысқа енді. Регулярлы өрнектерді жазу үшін әртүрлі синтаксистер 1980 жылдан бері бар, олардың бірі – POSIX стандарты, ал екіншісі, кеңінен қолданылатыны – Perl синтаксисі. Регулярлы өрнектер іздеу жүйелерінде, сөз өңдегіштер мен мәтін редакторларында іздеу және алмастыру диалогтарында, sed және AWK сияқты мәтіндік өңдеу құралдарында және лексикалық талдауда қолданылады. Көптеген бағдарламалау тілдері регулярлы өрнектерді қолдайды. Кітапханалық іске асырулар көбінесе "қозғалтқыш" деп аталады, және олардың көптеген түрлерін қайта пайдалануға болады.

Тарих

Регламентті өрнектер 1951 жылы пайда болды, математик Стивен Коул Клин өзінің математикалық белгісін пайдалану арқылы тұрақты тілдерді сипаттады. Бұл теориялық компьютерлік ғылымда, автоматтар теориясының (есептеу модельдері) және формалды тілдерді сипаттау мен жіктеудің кіші салаларында пайда болды. Үлгілерді сәйкестендірудің басқа ертедегі іске асырылуларына SNOBOL тілі кіреді, ол тұрақты өрнектерді қолданбай, өзінің үлгілерді сәйкестендіру құрылымдарын пайдаланды. Регламентті өрнектер 1968 жылдан бастап екі мақсатта кеңінен қолданыла бастады: мәтіндік редактордағы үлгілерді сәйкестендіру және компилятордағы лексикалық талдау. Бағдарлама түріндегі тұрақты өрнектердің алғашқы пайда болуы Кен Томпсон мәтіндік файлдардағы үлгілерді сәйкестендіру құралы ретінде редакторға Клейннің белгісін енгізген кезде болды. Жылдамдық үшін Томпсон IBM 7094 кодына жай уақытында компиляция (JIT) арқылы тұрақты өрнекті сәйкестендіруді үйлесімді уақыт бөлісу жүйесінде іске асырды, бұл JIT компиляциясының маңызды ерте мысалы. Кейін ол бұл мүмкіндікті Unix редакторына қосты ed, бұл ақырында танымал grep іздеу құралының тұрақты өрнектерді қолдануына әкелді ("grep" - бұл ed редакторындағы тұрақты өрнекті іздеу командасынан алынған сөз: g/re/p, "Жаһандық іздеу, Регулярлы өрнек және Сәйкес келетін жолдарды басып шығару" дегенді білдіреді). Томпсон QED-ді әзірлеген кезде, Дуглас Т. Росс және басқа зерттеушілер тобы компиляторды жобалауда лексикалық талдау үшін қолданылатын тұрақты өрнектерге негізделген құралды іске асырды. Осы тұрақты өрнектердің бастапқы түрлерінің көптеген түрлері 1970 жылдары Bell Labs-те, соның ішінде vi, lex, sed, AWK және expr, және басқа да бағдарламаларда, мысалы Emacs (өзінің жеке, үйлеспейтін синтаксисі мен мінез-құлқы бар) Unix бағдарламаларында қолданылды. Кейіннен регекстер көптеген бағдарламаларда қолданылды, ал бұл алғашқы нысандар 1992 жылы POSIX.2 стандартында стандартталды. 1980 жылдары Perl-де күрделірек regex пайда болды, ол бастапқыда Генри Спенсер (1986) жазған regex кітапханасынан алынған, кейіннен ол Tcl-ге арналған жетілдірілген тұрақты өрнектер деп аталатын іске асыруды жазды. Tcl кітапханасы - жақсартылған орындау сипаттамалары бар гибридті NFA/DFA іске асыру. Спенсердің Tcl тұрақты өрнегін енгізуді қабылдаған бағдарламалық жобаларға PostgreSQL кіреді. Кейін Perl Спенсердің бастапқы кітапханасын кеңейтіп, көптеген жаңа мүмкіндіктерді қосты. Raku (бұрын Perl 6 деп аталатын) жобалаудағы күш-жігердің бір бөлігі - Perl-дің регекс интеграциясын жақсарту және олардың ауқымы мен мүмкіндіктерін кеңейту, сөйлем грамматикасын талдауға рұқсат ету. Нәтижесінде Raku ережелері деп аталатын шағын тіл пайда болды, ол Raku грамматикасын анықтауға және бағдарламашыларға тілдің құралын беруге қолданылады. Бұл ережелер Perl 5.x regex-терінің қолданыстағы мүмкіндіктерін сақтайды, сонымен қатар суб-ережелер арқылы рекурсивті шығу талдаушының BNF стильді анықтауына мүмкіндік береді. Регекстерді құжат және деректер қорын модельдеуге арналған құрылымдалған ақпарат стандарттарында пайдалану 1960 жылдары басталды және ISO SGML (ANSI "GCA 101 1983") сияқты салалық стандарттар біріктірілгенде 1980 жылдары кеңейтілді. Құрылымдық спецификация тілдерінің өзегі регекстерден тұрады. Оның қолданылуы DTD элемент тобының синтаксисінде айқын көрінеді. Регламенттік өрнектерді пайдаланбастан бұрын көптеген іздеу тілдерінде қарапайым жолдамалар, мысалы "*" кез келген таңбалар тізбегіне сәйкес келеді, ал "?" бір таңбаға сәйкес келеді. Бұл туралы деректерді бүгінде файл атаулары үшін glob синтаксисінен және SQL LIKE операторынан табуға болады. 1997 жылдан бастап Филип Хейзел PCRE (Perl Compatible Regular Expressions) бағдарламасын әзірледі, ол Perl regex функционалдығын еліктеуге тырысады және көптеген заманауи құралдар, соның ішінде PHP және Apache HTTP Server қолданады. Бүгінде регекстер бағдарламалау тілдерінде, мәтін өңдеу бағдарламаларында (әсіресе лексикаларда), озық мәтін редакторларында және басқа да бағдарламаларда кеңінен қолданады. Regex қолдау көптеген бағдарламалау тілдерінің стандартты кітапханасының бөлігі болып табылады, соның ішінде Java және Python, және басқалардың синтаксисіне, соның ішінде Perl және ECMAScript. 2010 жылдардың аяғында бірнеше компаниялар PCRE-ге үйлесімді regex қозғалтқыштарының аппараттық, FPGA, GPU-ның CPU-мен салыстырғанда жылдамдығын ұсына бастады.

Regular expressions originated in 1951, when mathematician Stephen Cole Kleene described regular languages using his mathematical notation called regular events. These arose in theoretical computer science, in the subfields of automata theory (models of computation) and the description and classification of formal languages. Other early implementations of pattern matching include the SNOBOL language, which did not use regular expressions, but instead its own pattern matching constructs. Regular expressions entered popular use from 1968 in two uses: pattern matching in a text editor and lexical analysis in a compiler. Among the first appearances of regular expressions in program form was when Ken Thompson built Kleene's notation into the editor QED as a means to match patterns in text files. For speed, Thompson implemented regular expression matching by just in time compilation (JIT) to IBM 7094 code on the Compatible Time Sharing System, an important early example of JIT compilation. He later added this capability to the Unix editor ed, which eventually led to the popular search tool grep's use of regular expressions ("grep" is a word derived from the command for regular expression searching in the ed editor: g/re/p meaning "Global search for Regular Expression and Print matching lines"). Around the same time when Thompson developed QED, a group of researchers including Douglas T. Ross implemented a tool based on regular expressions that is used for lexical analysis in compiler design. Many variations of these original forms of regular expressions were used in Unix programs at Bell Labs in the 1970s, including vi, lex, sed, AWK, and expr, and in other programs such as Emacs (which has its own, incompatible syntax and behavior). Regexes were subsequently adopted by a wide range of programs, with these early forms standardized in the POSIX.2 standard in 1992. In the 1980s, the more complicated regexes arose in Perl, which originally derived from a regex library written by Henry Spencer (1986), who later wrote an implementation for Tcl called Advanced Regular Expressions. The Tcl library is a hybrid NFA/DFA implementation with improved performance characteristics. Software projects that have adopted Spencer's Tcl regular expression implementation include PostgreSQL. Perl later expanded on Spencer's original library to add many new features. Part of the effort in the design of Raku (formerly named Perl 6) is to improve Perl's regex integration, and to increase their scope and capabilities to allow the definition of parsing expression grammars. The result is a mini language called Raku rules, which are used to define Raku grammar as well as provide a tool to programmers in the language. These rules maintain existing features of Perl 5. x regexes, but also allow BNF style definition of a recursive descent parser via sub rules. The use of regexes in structured information standards for document and database modeling started in the 1960s and expanded in the 1980s when industry standards like ISO SGML (precursored by ANSI "GCA 101 1983") consolidated. The kernel of the structure specification language standards consists of regexes. Its use is evident in the DTD element group syntax. Prior to the use of regular expressions, many search languages allowed simple wildcards, for example "*" to match any sequence of characters, and "?" to match a single character. Relics of this can be found today in the glob syntax for filenames, and in the SQL LIKE operator. Starting in 1997, Philip Hazel developed PCRE (Perl Compatible Regular Expressions), which attempts to closely mimic Perl's regex functionality and is used by many modern tools including PHP and Apache HTTP Server. Today, regexes are widely supported in programming languages, text processing programs (particularly lexers), advanced text editors, and some other programs. Regex support is part of the standard library of many programming languages, including Java and Python, and is built into the syntax of others, including Perl and ECMAScript. In the late 2010s, several companies started to offer hardware, FPGA, GPU implementations of PCRE compatible regex engines that are faster compared to CPU implementations.

Үлгілер

Регулярлы өрнектер немесе регекстер термині көбінесе мәтін үлгілерін табуға арналған ерекше, стандартты мәтіндік синтаксисті білдіру үшін қолданылады, бұл төменде сипатталған математикалық жазбадан өзгеше. Регулярлы өрнектегі әрбір символ (яғни, оның үлгісін сипаттайтын жолдағы әрбір символ) метасимвол болып, арнайы мағынаға ие, немесе тура мағынасы бар символ болып табылады. Мысалы, `b.` регексінде, `b` символы тек `b` символына сәйкес келеді, ал `.` метасимволы жаңа жол символын қоспағанда, кез келген символға сәйкес келеді. Сондықтан, бұл регекс мысалы, `b%`, `bx` немесе `b5` тіркестеріне сәйкес келеді. Метасимволдар мен тура символдарды бірге қолдану арқылы белгілі бір үлгідегі мәтінді табуға немесе оның бірнеше даналарын өңдеуге болады. Үлгіге сәйкес келу дәл теңдіктен бастап өте жалпы ұқсастыққа дейін, метасимволдармен басқарылатын деңгейде өзгеруі мүмкін. Мысалы, `.` өте жалпы үлгі, ал `[a-z]` (әріптердің кіші әріптерінен `a` бастап `z` дейін) одан да аз жалпы, ал `b` нақты үлгі (тек `b` символына сәйкес келеді). Метасимволдық синтаксис нақты мақсаттарды ықшам және икемді түрде көрсету үшін жасалған, бұл мәтінді өңдеуді автоматтандыруға және әртүрлі деректерді стандартты ASCII пернетақтасымен оңай теріп енгізуге мүмкіндік береді. Бұл синтаксистегі регулярлы өрнектің қарапайым мысалы – мәтін редакторында екі түрлі жазылған сөзді табу, мысалы, `seriali[sz]e` регексі `serialise` және `serialize` екеуіне де сәйкес келеді. Жоққа шығару символдары да осы мақсатқа қол жеткізе алады, бірақ олардың үлгілері шектеулі, себебі оларда аз метасимволдар бар және қарапайым тілдік базасы бар. Жоққа шығару символдарының әдеттегі қолданылуы – файлдар тізіміндегі ұқсас атауларды табу, ал регекстер көбінесе мәтіндік тізбелерге үлгі сәйкес келтіретін қосымшаларда қолданылады. Мысалы, `^[ \t]+|[ \t]+$` регексі жолдың басында немесе соңында артық бос орындарға сәйкес келеді. Кез келген санды табуға арналған кеңейтілген регулярлы өрнек: `[+-]?(\d+(\.\d*)?|\.\d+)([eE][+-]?\d+)?`. Регекс процессор жоғарыда көрсетілген синтаксистегі регулярлы өрнекті ізделіп отырған мәтінді білдіретін жолмен сәйкес келуге және орындалуға болатын ішкі өрнекке аударады. Мүмкін болатын тәсілдердің бірі – Томпсонның құрылыс алгоритмін қолдану, ол нондетерминистік автоматты (NFA) құрастырады, содан кейін оны детерминистік автоматқа айналдырады және нәтижесіндегі детерминистік автоматты (DFA) регулярлы өрнекке сәйкес келетін ішкі тізбелерді табу үшін мақсатты мәтін жолында орындайды. Суретте `s*` регулярлы өрнегінен алынған NFA схемасы `N(s*)` көрсетілген, мұнда `s` өз кезегінде қарапайым регулярлы өрнекті білдіреді, ол қазірдің өзінде NFA `N(s)`-ке рекурсивті түрде аударылған.

The phrase regular expressions, or regexes, is often used to mean the specific, standard textual syntax for representing patterns for matching text, as distinct from the mathematical notation described below. Each character in a regular expression (that is, each character in the string describing its pattern) is either a metacharacter, having a special meaning, or a regular character that has a literal meaning. For example, in the regex b., 'b' is a literal character that matches just 'b', while '.' is a metacharacter that matches every character except a newline. Therefore, this regex matches, for example, 'b%', or 'bx', or 'b5'. Together, metacharacters and literal characters can be used to identify text of a given pattern or process a number of instances of it. Pattern matches may vary from a precise equality to a very general similarity, as controlled by the metacharacters. For example, is a very general pattern, [a z] (match all lower case letters from 'a' to 'z') is less general and b is a precise pattern (matches just 'b'). The metacharacter syntax is designed specifically to represent prescribed targets in a concise and flexible way to direct the automation of text processing of a variety of input data, in a form easy to type using a standard ASCII keyboard. A very simple case of a regular expression in this syntax is to locate a word spelled two different ways in a text editor, the regular expression seriali[sz]e matches both "serialise" and "serialize". Wildcard characters also achieve this, but are more limited in what they can pattern, as they have fewer metacharacters and a simple language base. The usual context of wildcard characters is in globbing similar names in a list of files, whereas regexes are usually employed in applications that pattern match text strings in general. For example, the regex ^[ \t]+|[ \t]+$ matches excess whitespace at the beginning or end of a line. An advanced regular expression that matches any numeral is [+ ]? (\d+(\.\d*)?|\.\d+)([eE][+ ]?\d+)?. A regex processor translates a regular expression in the above syntax into an internal representation that can be executed and matched against a string representing the text being searched in. One possible approach is the Thompson's construction algorithm to construct a nondeterministic finite automaton (NFA), which is then made deterministic and the resulting deterministic finite automaton (DFA) is run on the target text string to recognize substrings that match the regular expression. The picture shows the NFA scheme N(s*) obtained from the regular expression s*, where s denotes a simpler regular expression in turn, which has already been recursively translated to the NFA N(s).

Үлгі өрнектердің теңдестігін анықтау

Жоғарыдағы мысалдардың көпшілігінде көрсетілгендей, бірдей нәтижеге жету үшін тұрақты өрнекті құрудың бірнеше тәсілі бар. Екі берілген тұрақты өрнек үшін сипатталған тілдердің тең екенін анықтайтын алгоритм жасау мүмкін; бұл алгоритм әр өрнекті минималды детерминистік шекті күй машинасына дейін азайтады және олардың изоморфты (эквивалентті) екенін анықтайды. Тұрақты өрнектерге арналған алгебралық заңдарды Гишердің әдісімен алуға болады, бұл мысал арқылы жақсы түсіндіріледі: (X+Y)* және (X*Y*)* бірдей тұрақты тілді білдіретінін тексеру үшін, барлық тұрақты өрнектер X, Y үшін, (a+b)* және (a*b*)* тұрақты өрнектері Σ={a,b} алфавиті бойынша бірдей тілді білдіретінін тексеру қажет және жеткілікті. Жалпы алғанда, тұрақты өрнектердегі E=F теңдеуі, оның әртүрлі белгілік тұрақтылармен ауыстырылған әртүрлі айнымалылармен қолданылуы орындалса ғана орындалады. Кез келген тұрақты өрнекті тек Клине жұлдызы мен шекті сөздердің жиынтығы арқылы жазуға болады. Бұл күрделі мәселе. Тұрақты өрнектер қаншалықты қарапайым болса да, оларды жүйелі түрде стандартты түрге қайта жазудың әдісі жоқ. Бұрынғы аксиоманың болмауы жұлдыз биіктігі мәселесіне әкелді. 1991 жылы Декстер Козен тұрақты өрнектерді Клине алгебрасы ретінде аксиоматизациялады, теңдеулік және Хорн аксиомаларын қолданды. Ал 1964 жылы Редко таза теңдеулік аксиомалардың шекті жиынтығы тұрақты тілдердің алгебрасын сипаттай алмайтынын дәлелдеді.

Синтаксисі

Регулярлы өрнек үлгісі мақсатты тізбекке сәйкес келеді. Үлгі атомдар тізбегінен тұрады. Атом – бұл регулярлы өрнек үлгісіндегі бір нүкте, ол мақсатты тізбекке сәйкес келуге тырысады. Ең қарапайым атом – сөздік мағынадағы жазу, бірақ үлгінің атомға сәйкес келетін бөліктерін топтастыру үшін метасимволдар ретінде ( ) пайдалану қажет. Метасимволдар мыналарды құруға көмектеседі: атомдар; қанша атом бар екенін көрсететін сандық белгілер (және ол ашкөз сандық белгі ме, жоқ па); логикалық ЖӘНЕ (OR) символы, ол баламалар жиынтығын ұсынады, және логикалық ЖОҚ (NOT) символы, ол атомның болуын жоққа шығарады; сондай-ақ, аяқталған атомдар үлгісінің бұрынғы атомдарына сілтеме жасау үшін кері сілтемелер. Сәйкестік, тізбектің барлық атомдарына сәйкес келгенде емес, регулярлы өрнектегі барлық үлгі атомдарына сәйкес келгенде жасалады. Идея – барлық сөздік мағынадағы мүмкіндіктердің үлкен тізімін құрастырудың орнына, кішкентай таңбалар үлгісін көптеген ықтимал тізбектер үшін қолдану. Регулярлы өрнек процессорына байланысты шамамен он төрт метасимвол бар, бұл таңбалар контекстке байланысты немесе "эскейп" символдарының алдында, яғни осы жағдайда кері қисық сызық \ болғанда, әдеттегі мағынасын жоғалтуы мүмкін. Қазіргі заманғы және POSIX кеңейтілген регулярлы өрнектер метасимволдарды олардың тура мағынасынан жиірек қолданады, сондықтан "кері қисық сызыққа тәуелділік" немесе "тіс тіркесігі синдромын" болдырмау үшін, олар метасимволдарды тура мағынаға айналдыруға мүмкіндік береді; алайда, бастапқыда олар төрт жақшалы метасимволдар ( ) және { } негізінен тура мағыналы болады, ал олардың әдеттегі мағынасынан "эскейп" арқылы метасимволдарға айналады. Көптеген стандарттар екеуін де қолдайды. Әдеттегі метасимволдар: {}[] ^$.|*+? және \. Эскейп символдары қолданылғанда метасимволға айналатын әдеттегі таңбалар: dswDSW және N.

Шекаралық белгілер

Бағдарламалау тілінде регексті енгізген кезде, олар әдеттегі жол ретінде бейнеленуі мүмкін, сондықтан әдетте тырнақшалармен жазылады; мысалы, C, Java және Python тілдерінде осылай жиі кездеседі, онда регекс re "re" түрінде енгізіледі. Дегенмен, олар көбінесе слэштермен шектеледі, мысалы, re регексі үшін /re/. Бұл ed редакторында пайда болды, онда / іздеу командасы болып табылады, ал /re/ өрнегі үлгіге сәйкес келетін жолдардың диапазонын белгілеу үшін қолданылады, оны екі жақтағы басқа командалармен біріктіруге болады. Ең танымал мысалы – g/re/p, grep ("global regex print") командасы, ол Linux дистрибутивтері сияқты Unix негізіндегі көптеген операциялық жүйелерде кездеседі. Ұқсас тәсіл sed редакторында да қолданылады, онда іздеу және алмастыру s/re/replacement/ арқылы жүзеге асырылады, ал жолдардың диапазонын көрсету үшін үлгілерді үтірмен біріктіруге болады, мысалы, /re1/,/re2/. Бұл жазу тәсілі Perl тілінде кеңінен танымал, онда ол қалыпты жолдардан ерекшеленетін синтаксистің бөлігін құрайды. Кейбір жағдайларда, мысалы, sed және Perl тілдерінде, мазмұнмен қақтығысты болдырмау және мазмұндағы шектегіш белгіні қашудан қорғау үшін баламалы шектегіштерді қолдануға болады. Мысалы, sed командасында s,/,X, командасы / белгісін X белгісімен алмастырады, мұнда үтір шектегіш ретінде қолданылады.

IEEE POSIX стандарты

IEEE POSIX стандарты үш деңгейлі сәйкестікке ие: BRE (Негізгі тұрақты өрнектер), ERE (Кеңейтілген тұрақты өрнектер) және SRE (Жай тұрақты өрнектер). SRE қолданыстан шығарылды, оның орнына BRE пайдаланылады, себебі екеуі де кері үйлесімділікті қамтамасыз етеді. Төмендегі бөлім, символдар кластарын қамтитын, BRE және ERE екеуіне де қолданылады. BRE және ERE бірге жұмыс істейді. ERE ?, +, және | сиымдарын қосады, сондай-ақ BRE-де қажет болатын метасимволдарды ( ) және { } қашардан босату қажеттілігін жояды. Сонымен қатар, регекстер үшін POSIX стандартының синтаксисі сақталғанда, нақты (бірақ POSIX стандартына сәйкес) қолданбаларға арналған қосымша синтаксис болуы мүмкін және көбінесе болады. POSIX.2 кейбір іске асыру ерекшеліктерін нақтыламаса да, BRE және ERE «стандартты» ұсынады, ол көптеген құралдардың әдепкі синтаксисі ретінде қабылданды, онда BRE немесе ERE режимдерін таңдау мүмкіндігі көбінесе қолдау табады. Мысалы, GNU grep келесі опцияларды ұсынады: "grep -E" ERE үшін, "grep -G" BRE үшін (әдепкі), және "grep -P" Perl регекстері үшін. Perl регекстері бай және қуатты атомдық өрнектер жиынтығына ие болып, де-факто стандартқа айналды. Perl-де «негізгі» немесе «кеңейтілген» деңгейлер жоқ. POSIX ERE-дегідей, ( ) және { } қашарлары қашардан босатылмаса, метасимволдар ретінде қарастырылады; басқа метасимволдар контекстке қарай нақты немесе символдық деп анықталады. Қосымша мүмкіндіктерге жалқау сәйкестендіру, кері сілтемелер, аталған топтар және рекурсивті үлгілер кіреді.

Таңба кластары

Таңба класы – бұл тура мағыналы сәйкестендіруден кейінгі ең негізгі регекс тұжырымдамасы. Ол кішкентай таңбалар тізбегін үлкен таңбалар жиынтығына сәйкес етеді. Мысалы, [A Z] ағылшын алфавитіндегі кез келген бас әріпті білдіре алады, ал \d кез келген цифрды білдіре алады. Таңба кластары POSIX деңгейлерінің екісіне де қолданылады. [a Z] (яғни кіші әріптен үлкен әріпке дейін) сияқты таңбалар ауқымын көрсеткенде, компьютердің жергілікті параметрлері мазмұнды таңба кодтамасының сандық ретімен анықтайды. Олар цифрларды осы ретпен сақтай алады, немесе олардың ретін abc zABC Z, немесе aAbBcC zZ деп белгілеуге болады. POSIX стандарты орнатылған регекс процессормен белгілі болатын таңба класын анықтайды. Бұл анықтамалар келесі кестеде:

Сипаттама | POSIX | Perl/Tcl | Vim | Java | ASCII
------- | -------- | -------- | -------- | -------- | --------
ASCII таңбалары | \p{ASCII} | [\x00 \x7F] | | |
Алфа-цифрлық таңбалар | [:alnum:] | \p{Alnum} | [A Za z0 9] | |
Алфа-цифрлық таңбалар плюс " " | \w | \w | \w | [A Za z0 9 ] |
Сөздік емес таңбалар | \W | \W | \W | [^A Za z0 9 ] |
Әліппелік таңбалар | [:alpha:] | \a | \p{Alpha} | [A Za z] |
Бос орын және табу белгісі | [:blank:] | \s | \p{Blank} | [ \t] |
Сөз шекаралары | \b | \< \> | \b | (?<=\W)(?=\w)|(?<=\w)(?=\W) |
Сөз шекаралары емес | \B | | | (?<=\W)(?=\W)|(?<=\w)(?=\w) |
Бақылау таңбалары | [:cntrl:] | \p{Cntrl} | [\x00 \x1F\x7F] | |
Цифрлар | [:digit:] | \d | \d | \p{Digit} немесе \d | [0 9]
Цифрлар емес | \D | \D | \D | [^0 9] |
Көрінетін таңбалар | [:graph:] | \p{Graph} | [\x21 \x7E] | |
Кіші әріптер | [:lower:] | \l | \p{Lower} | [a z] |
Көрінетін таңбалар және бос орын | [:print:] | \p | \p{Print} | [\x20 \x7E] |
Пунктуация таңбалары | [:punct:] | \p{Punct} | [][! "#$%&' *+,./:;<=>? @\^ `{|}~ ] | |
Бос орын таңбалары | [:space:] | \s | \s | \p{Space} немесе \s | [ \t\r\n\v\f]
Бос орын таңбалары емес | \S | \S | \S | [^ \t\r\n\v\f] |
Үлкен әріптер | [:upper:] | \u | \p{Upper} | [A Z] |
Он алтылық цифрлар | [:xdigit:] | \x | \p{XDigit} | [A Fa f0 9] |

POSIX таңба кластарын жақшалы өрнектердің ішінде ғана қолдануға болады. Мысалы, [[:upper:]ab] үлкен әріптерді және кіші әріптер "a" мен "b" сәйкестендіреді. Кейбір құралдар түсінетін қосымша POSIX емес класс – [:word:], ол әдетте [:alnum:] плюс астын сызу белгісі ретінде анықталады. Бұл көптеген бағдарламалау тілдерінде идентификаторларда пайдаланылуы мүмкін таңбалар екендігін көрсетеді. Vim редакторы сөз және сөз басы кластарын (\w және \h белгілерін пайдалана отырып) ажыратады, өйткені көптеген бағдарламалау тілдерінде идентификаторды бастайтын таңбалар басқа орындарда кездесетін таңбалардан өзгеше болады: сандар әдетте алынып тасталады, сондықтан идентификатор POSIX белгісінде \h\w* немесе [[:alpha:] ][[:alnum:] ]* сияқты көрінеді. POSIX регекс стандарттары таңба кластарын шақыратынды басқа регекс түрлерінде POSIX таңба кластары деп атайды. Басқа регекс түрлерінің көпшілігінде POSIX-тің жақшалы өрнектер деп атағандарын сипаттау үшін таңба класы термині қолданылады.

Perl және PCRE

Экспрессивтілігі мен (салыстырмалы) оқуға қолайлылығынан кейін, көптеген басқа құралдар мен бағдарламалау тілдері Perl-дің синтаксисіне ұқсас синтаксисті қабылдады, мысалы Java, JavaScript, Julia, Python, Ruby, Qt, Microsoft-тың .NET Framework және XML Schema. Boost және PHP сияқты кейбір тілдер мен құралдар бірнеше режекс нұсқаларын қолдайды. Perl-дің режекс түзілімдері толықтай бірдей емес және әдетте 1994 жылы жарық көрген Perl 5.0 нұсқасындағы мүмкіндіктердің бір бөлігін ғана іске асырады. Perl кейде басқа тілдерде алғаш пайда болған мүмкіндіктерді де қамтиды. Мысалы, Perl 5.10 PCRE және Python тілдерінде әзірленген синтаксистік кеңейтулерді іске қосты.

Жалқау сәйкестендіру

Python және кейбір басқа да іске асырылымдарда (мысалы, Java) үш кең таралған квантификатор (*, + және ?) әдепкі бойынша ашкөз болып келеді, себебі олар мүмкіндігінше көп символға сәйкес келеді. ".+" регексі (қос тырнақшаларды қоса алғанда) "Ганимед", - деп жалғастырды ол, - Күн жүйесіндегі ең үлкен ай" деген жолға қолданғанда, бүкіл жолға сәйкес келеді (өйткені жолдың басы мен соңы қос тырнақшамен белгіленген), ал "Ганимед" деген алғашқы бөлігіне ғана сәйкес келмейді. Аталған квантификаторларды сұрақ белгісін қосу арқылы ("+?" сияқты) минималды немесе тартымсыз етуге болады, олар осылайша мүмкіндігінше аз символға сәйкес келеді. Мысалы, ".+?" тек "Ганимед" дегенге ғана сәйкес келеді. Квантификаторларды плюс белгісін қосу арқылы иеленуші етуге болады, бұл кері қайтуды (қайта іздеу механизмінде) тоқтатып, тіпті бұл жалпы сәйкестіктің табысқа жетуіне мүмкіндік берсе де, бұлай істеуге жол бермейді: ". *" регексі "Ганимед", - деп жалғастырды ол, - Күн жүйесіндегі ең үлкен ай" деген жолға қолданғанда, жолдың барлығына сәйкес келеді, ал ". *+" регексі мүлдем сәйкес келмейді, себебі . *+ кірістің барлығын, соңғы символдың өзін де жұтып алады. Осылайша, иеленуші квантификаторлар теріске шығарылған символ кластарымен қолданғанда тиімдірек болады, мысалы, "[^"]*+", ол аталған жолға қолданғанда "Ганимед" дегенге сәйкес келеді. Сол функцияны атқаратын тағы бір кең таралған кеңейтім – атомдық топтастыру, ол жақшадағы топтың кері қайтуын тоқтатып қояды. Типтік синтаксис: Мысалы, while both және сәйкес келсе, тек қана сәйкес келеді, себебі механизмге кері қайтуға рұқсат етілмейді, сондықтан "wi" сәйкес келгеннен кейін топты "w" деп өзгертуге тырыса алмайды. Иеленуші квантификаторларды ашкөз және тартымсыз квантификаторларға қарағанда іске асыру оңай, және олар әдетте орындалу кезінде тиімдірек болады.

Үлгісіз тілдер үлгілері

Қазіргі кездегі барлық тұрақты өрнектер кітапханаларында кездесетін көптеген мүмкіндіктер, тұрақты тілдердің шегінен асып түсетін экспрессивтік қуатты қамтамасыз етеді. Мысалы, көптеген іске асырулар, кіші өрнектерді жақшалармен топтастыруға және олардың сәйкес келетін мәнін сол өрнекте қайта қолдануға мүмкіндік береді (кері сілтемелер). Бұл, басқа нәрселермен қатар, үлгінің "папа" немесе "WikiWiki" сияқты қайталанатын сөздер тізбегіне сәйкес келуін қамтамасыз етеді, бұл формалды тіл теориясында "квадраттар" деп аталады. Мұндай тізбектерге арналған үлгі: (.+)\1. Квадраттар тілі тұрақты емес, сонымен қатар, соғу леммасына сәйкес, контекстсіз де емес. Дегенмен, көптеген қазіргі заманғы құралдар қолдайтын, шексіз кері сілтемелермен сәйкестіру әлі де контекстке сезімтал. Кез келген сандағы кері сілтемелерді сәйкестендірудің жалпы мәселесі NP-толық, ал белгілі алгоритмдердің орындалу уақыты пайдаланылатын кері сілтеме топтарының санына қарай экспоненциалды түрде өседі. Алайда, мұндай құрылымдарды ұсынатын көптеген құралдар, кітапханалар және қозғалтқыштар өз үлгілері үшін "тұрақты өрнек" терминін қолдануын жалғастыруда. Бұл, формалды тіл теориясы мен үлгі сәйкестігінде "тұрақты өрнек" терминінің әртүрлі мағыналарына әкелді. Осы себепті, кейбір адамдар соңғысын сипаттау үшін "regex", "regexp" немесе жай ғана "үлгі" терминдерін қолданады. Perl бағдарламалау тілінің авторы Ларри Уолл, Raku дизайны туралы эссесінде былай жазады:

Блокquote|1="Regular expressions" [ ] нақты тұрақты өрнектермен тек шешімді түрде байланысты. Дегенмен, бұл термин біздің үлгіні сәйкестендіру қозғалтқыштарымыздың мүмкіндіктерімен бірге өсті, сондықтан мен тілдік қажеттілікпен күресуге тырыспаймын. Алайда, мен оларды әдетте "regex" (немесе "regexen", егер мен англосаксондық көңіл-күйде болсам) деп атаймын, сондай-ақ 1994 жылы пайда болған "lookaround" сияқты бірнеше күрделі кеңейтулерді де атауға болады. Lookaround сәйкестіктің айналасын анықтайды, бірақ сәйкестіктің өзіне кірмейді, бұл тек жол іздеу жағдайында ғана маңызды ерекшелік. Олардың кейбіреулерін, қоршаған ортаны тілдің бөлігі ретінде қарастыру арқылы тұрақты тілде модельдеуге болады. 1=(?= ) және (?! ) ең болмағанда 1994 жылдан бері, Perl 5-тен бастап қолданылып келеді. 1=(?<= ) және (?<! ) кері қаралымдары 1997 жылдан бері, Ілия Захаревичтің Perl 5.005-ке жасаған өзгертулерінде куәландырылған.

Орындау және жұмыс істеу уақыты

Бар ең кемі үш түрлі алгоритм бар, олар берілген регекстің жолмен сәйкес келе ма және қалай сәйкес келетінін анықтайды. Ең көне және ең жылдамы формальды тіл теориясының нәтижесіне негізделген, ол кез келген нондетерминистік автоматты (NFA) детерминистік автоматқа (DFA) түрлендіруге мүмкіндік береді. DFA нақты түрде құрылып, содан кейін алынған кіріс жолында бір символдан кейін символмен орындалуы мүмкін. m өлшемді регекс үшін DFA құрастыру O(2^m) уақыт және жадты қажет етеді, бірақ n өлшемді жолда O(n) уақытында орындалуы мүмкін. Ескеріңіз, сандық көрсеткіштер сияқты қысқартулар кеңейтілгеннен кейін өрнектің өлшемі есептеледі. Балама тәсіл – NFA-ны тікелей модельдеу, әр DFA күйін қажет болғанда құру және келесі қадамда оны жою. Бұл DFA-ны жасырын қалдырады және экспоненциалды құрылыс шығындарынан сақтайды, бірақ орындалу құны O(mn) дейін өседі. Нақты тәсіл DFA алгоритмі деп аталады, ал жасырын тәсіл NFA алгоритмі деп аталады. NFA алгоритміне кэш қосу көбінесе «жалтақ DFA» алгоритмі деп аталады, немесе DFA алгоритмі деп аталады, ешқандай айырма жасамай. Бұл алгоритмдер жылдам, бірақ топталған қосымша өрнектерді, жалтақ сандықтарды және ұқсас мүмкіндіктерді еске алу үшін оларды пайдалану қиын. Қазіргі заманғы іске асырулардың арасында Кокс кодына негізделген re1, re2 және sregex отбасы бар. Үшінші алгоритм – үлгіні кіріс жолымен кері қадаммен сәйкестендіру. Бұл алгоритм әдетте NFA деп аталады, бірақ бұл терминология шатастыру тудыруы мүмкін. Оның орындалу уақыты экспоненциалды болуы мүмкін, қарапайым іске асырулар алмасу және шексіз сандықтарды қамтитын өрнектермен сәйкес келгенде, алгоритм экспоненциалды түрде өсетін кіші жағдайлардың санын қарастыруға мәжбүр болады. Бұл Regular Expression Denial of Service (ReDoS) деп аталатын қауіпсіздік мәселесін тудыруы мүмкін. Кері қадаммен іске асыру нашар жағдайда ғана экспоненциалды кепілдік береді, бірақ олар әлдеқайда икемді және күшті. Мысалы, кері сілтемелерді пайдалануға мүмкіндік беретін немесе Perl енгізген әртүрлі кеңейтулерді іске асыратын кез келген іске асыру кері қадамды қамтуы керек. Кейбір іске асырулар екі алгоритмнің де артықшылықтарын алуға тырысады, алдымен жылдам DFA алгоритмін іске қосып, сәйкестік кезінде кері сілтеме кездескенде ғана ықтимал баяу кері қадам алгоритміне қайта оралады. GNU grep (және оның негізіндегі gnulib DFA) осындай стратегияны қолданады. Бойер-Мур (BM) алгоритмдері және кері сканерлеу сияқты DFA-ны оңтайландырудың байланысты әдістерін қолдану арқылы сызықтық емес орындалу уақытын алуға қол жеткізілді. POSIX синтаксисі мен кеңейтулерінің кең спектрін қолдайтын GNU grep, алғашқы өту үшін BM-ді пайдаланады, содан кейін жасырын DFA-ны пайдаланады. Wu agrep, шамамен сәйкестікті іске асырады, BDM-де (артқа DAWG сәйкестігінде) DFA-ға алдын ала сүзгілеуді біріктіреді. NR grep-тің BNDM-і BDM техникасын Shift немесе бит деңгейімен параллелизммен кеңейтеді. Кері сілтемелер үшін кері қадамға бірнеше теориялық баламалар бар, олардың «экспоненттері» тек кері сілтемелер санына байланысты, POSIX сияқты кейбір регекс тілдерінің тұрақты қасиеті. Кері қадамды емес NFA-ны әр кері сілтеме жазбасы үшін көшіретін бір қарапайым әдістің күрделілігі n ұзындығындағы және k кері сілтемелері бар RegExp үшін {\mathrm O}(n^{2k+2}) уақыт және {\mathrm O}(n^{2k+1}) жадты құрайды. Жақында жад автоматтарына негізделген теориялық жұмыс қолданылған «белсенді» айнымалы түйіндерге негізделген тығыз шекті және кейбір кері сілтемеленген регексптер үшін полиномиялық мүмкіндікті ұсынады.

There are at least three different algorithms that decide whether and how a given regex matches a string. The oldest and fastest relies on a result in formal language theory that allows every nondeterministic finite automaton (NFA) to be transformed into a deterministic finite automaton (DFA). The DFA can be constructed explicitly and then run on the resulting input string one symbol at a time. Constructing the DFA for a regular expression of size m has the time and memory cost of O(2m), but it can be run on a string of size n in time O(n). Note that the size of the expression is the size after abbreviations, such as numeric quantifiers, have been expanded. An alternative approach is to simulate the NFA directly, essentially building each DFA state on demand and then discarding it at the next step. This keeps the DFA implicit and avoids the exponential construction cost, but running cost rises to O(mn). The explicit approach is called the DFA algorithm and the implicit approach the NFA algorithm. Adding caching to the NFA algorithm is often called the "lazy DFA" algorithm, or just the DFA algorithm without making a distinction. These algorithms are fast, but using them for recalling grouped subexpressions, lazy quantification, and similar features is tricky. Modern implementations include the re1 re2 sregex family based on Cox's code. The third algorithm is to match the pattern against the input string by backtracking. This algorithm is commonly called NFA, but this terminology can be confusing. Its running time can be exponential, which simple implementations exhibit when matching against expressions like that contain both alternation and unbounded quantification and force the algorithm to consider an exponentially increasing number of sub cases. This behavior can cause a security problem called Regular expression Denial of Service (ReDoS). Although backtracking implementations only give an exponential guarantee in the worst case, they provide much greater flexibility and expressive power. For example, any implementation which allows the use of backreferences, or implements the various extensions introduced by Perl, must include some kind of backtracking. Some implementations try to provide the best of both algorithms by first running a fast DFA algorithm, and revert to a potentially slower backtracking algorithm only when a backreference is encountered during the match. GNU grep (and the underlying gnulib DFA) uses such a strategy. Sublinear runtime algorithms have been achieved using Boyer Moore (BM) based algorithms and related DFA optimization techniques such as the reverse scan. GNU grep, which supports a wide variety of POSIX syntaxes and extensions, uses BM for a first pass prefiltering, and then uses an implicit DFA. Wu agrep, which implements approximate matching, combines the prefiltering into the DFA in BDM (backward DAWG matching). NR grep's BNDM extends the BDM technique with Shift Or bit level parallelism. A few theoretical alternatives to backtracking for backreferences exist, and their "exponents" are tamer in that they are only related to the number of backreferences, a fixed property of some regexp languages such as POSIX. One naive method that duplicates a non backtracking NFA for each backreference note has a complexity of {\mathrm O}(n^{2k+2}) time and {\mathrm O}(n^{2k+1}) space for a haystack of length n and k backreferences in the RegExp. A very recent theoretical work based on memory automata gives a tighter bound based on "active" variable nodes used, and a polynomial possibility for some backreferenced regexps.

Юникод

Теориялық тұрғыдан алғанда, кез келген токен жиынтығы, алдын ала анықталған жағдайда, тұрақты өрнектермен сәйкес келуі мүмкін. Тарихи іске асырулар тұрғысынан, regex-тер бастапқыда ASCII таңбаларын өздерінің токендер жиынтығы ретінде пайдалану үшін жазылған, бірақ regex кітапханалары көптеген басқа таңбалар жиынтығын қолдады. Көптеген қазіргі заманғы regex қозғалтқыштары Юникодты кем дегенде біраз деңгейде қолдайды. Көптеген жағдайларда таңбалар жиынтығының қандай екені маңызды емес, бірақ Unicode-ті қолдау үшін regex-терді кеңейту кезінде кейбір мәселелер туындайды. Қолданылатын кодтау. Кейбір regex кітапханалары абстрактілік Юникод таңбалары орнына белгілі бір кодтаумен жұмыс істеуді күтеді. Олардың көбіне UTF-8 кодтамасы қажет, ал басқалары UTF-16 немесе UTF-32 күтуі мүмкін. Керісінше, Perl және Java кодтамаларға бейтарап, оның орнына ішкі кодталған таңбалар бойынша жұмыс істейді. Қолдау көрсетілетін Unicode диапазоны. Көптеген regex қозғалтқыштары тек Негізгі көптілді жазықтықты, яғни тек 16 битпен кодталатын таңбаларды қолдайды. Қазіргі уақытта (2016 жылғы жағдай бойынша) тек бірнеше regex қозғалтқыштары (мысалы, Perl және Java) толық 21 биттік Unicode диапазонын басқара алады. ASCII-ге бағдарланған конструкцияларды Unicode-қа кеңейту. Мысалы, ASCII негізделген іске асыруларда [x y] түріндегі таңбалар диапазоны барлық жерде жарамды, егер x және y кодтық нүктелері [0x00,0x7F] аралығында болса және codepoint(x) ≤ codepoint(y) болса. Мұндай таңбалар диапазондарының Unicode-қа табиғи кеңейтілуі тек қана аяқ нүктелерінің [0x00,0x7F] талабын [0x0000,0x10FFFF] деген талапқа өзгертеді. Алайда іс жүзінде бұл жиі орын алмайды. Кейбір іске асырулар, мысалы gawk, Unicode блоктарын таңбалар диапазондарына кесіп өтуге мүмкіндік бермейді. [0x61,0x7F] сияқты диапазон жарамды, өйткені екі ұшы да Basic Latin блогына кіреді, [0x0530,0x0560] сияқты, өйткені екі ұшы да Армения блогына кіреді, бірақ [0x0061,0x0532] сияқты диапазон жарамсыз, өйткені ол бірнеше Unicode блоктарын қамтиды. Басқа қозғалтқыштар, мысалы Vim редакторы, блоктарды кесіп өтуге мүмкіндік береді, бірақ таңбалар мәндері 256-дан артық болмауы керек. Үлкен-кіші әріптерге сезімталдық. Кейбір үлкен-кіші әріптерге сезімталдық белгілері тек ASCII таңбаларына әсер етеді. Басқа белгілер барлық таңбаларға әсер етеді. Кейбір қозғалтқыштарда екі түрлі белгі бар, біреуі ASCII үшін, екіншісі Unicode үшін. POSIX кластарына жататын таңбалардың нақты саны да әр түрлі. Үлкен-кіші әріптерге сезімталдықтың туыстары. ASCII-де үлкен-кіші әріптердің ерекшелігі болғандықтан, үлкен-кіші әріптерге сезімталдық мәтіндік іздеуде логикалық ерекшелікке айналды. Юникодта деванагари сияқты үлкен-кіші әріптерсіз әріптер енгізілген. Бұл үшін үлкен-кіші әріптерге сезімталдық қолданылмайды. Қытайша сияқты жазулар үшін тағы бір айырмашылық логикалық көрінеді: дәстүрлі және оңайлатылған. Араб жазуында бастапқы, орта, соңғы және оқшауланған позицияға сезімталдық қажет болуы мүмкін. Жапон тілінде хирагана мен катакананың арасындағы сезімсіздік кейде пайдалы. Нормализация. Юникодта біріктірілетін таңбалар бар. Ескі жазу машиналары сияқты, жай негізгі таңбалар (ақ бос орындар, тыныш белгілер, символдар, цифрлар немесе әріптер) бір немесе бірнеше аралықсыз символдармен (әдетте диакритика, акцент белгілері сияқты әріптерді өзгерту) біріктірілуі мүмкін, бір жалғыз басылатын таңбаны құру үшін; бірақ Юникодта да шектеулі алдын ала құрастырылған таңбалар бар, яғни бір немесе бірнеше біріктірілетін таңбаларды қамтитын таңбалар. Негізгі таңба + біріктірілетін таңбалар тізбегі бірдей бір алдын ала құрастырылған таңбамен сәйкес болуы керек (осы біріктіру тізбектерінің тек кейбіреуін ғана бір Юникод таңбасына алдын ала құрастыруға болады, бірақ Юникодта көптеген басқа біріктіру тізбектері мүмкін және әртүрлі тілдер үшін қажет, бастапқы негізгі таңбадан кейін бір немесе бірнеше біріктіру таңбаларын қолдану; бұл біріктіру тізбектерінде негізгі таңба немесе ішінара алдын ала құрастырылған таңбаларды біріктіру болуы мүмкін, бірақ міндетті түрде канондық тәртіппен емес және міндетті түрде канондық алдын ала құрастыруларды қолданбайды). Негізгі таңбалардың тізбектерін стандарттау процесі + біріктіру таңбаларын осы каноникалық теңдеу тізбектерін қайта реттеп, оларды каноникалық ретке келтіруден бұрын (және кейбір біріктіру таңбаларын жетекші базалық таңбаға қайта құру) нормализация деп аталады. Жаңа басқару кодтары. Юникод байт реті белгілері мен мәтін бағыт белгілерін енгізді. Бұл кодтармен арнайы жұмыс істеу керек болуы мүмкін. Unicode блоктары, скрипттері және көптеген басқа таңба қасиеттері үшін таңба кластарын енгізу. Блок қасиеттері скрипт қасиеттеріне қарағанда әлдеқайда пайдалы, өйткені блок бірнеше түрлі скрипттерден код нүктелерін, ал скрипт бірнеше түрлі блоктардан код нүктелерін қамти алады. Perl және кітапханада \p{InX} немесе \p{Block=X} түріндегі қасиеттер X блогындағы таңбаларды, ал \P{InX} немесе \P{Block=X} сол блокқа кірмейтін код нүктелерін сәйкестендіреді. Сонымен қатар, \p{Armenian}, \p{IsArmenian} немесе \p{Script=Armenian} Армения скриптіндегі кез келген таңбаны сәйкестендіреді. Жалпы алғанда, \p{X} бинарлық қасиеті X немесе жалпы санат X-ке ие кез келген таңбаны сәйкестендіреді. Мысалы, \p{Lu}, \p{Uppercase Letter} немесе \p{GC=Lu} кез келген үлкен әріпті сәйкестендіреді. Бинарлық қасиеттер, жалпы санаттар емес, \p{White Space}, \p{Alphabetic}, \p{Math} және \p{Dash} кіреді. Бинарлық емес қасиеттердің мысалдары \p{Bidi Class=Right to Left}, \p{Word Break=A Letter} және \p{Numeric Value=10} болып табылады.

In theoretical terms, any token set can be matched by regular expressions as long as it is pre defined. In terms of historical implementations, regexes were originally written to use ASCII characters as their token set though regex libraries have supported numerous other character sets. Many modern regex engines offer at least some support for Unicode. In most respects it makes no difference what the character set is, but some issues do arise when extending regexes to support Unicode. Supported encoding. Some regex libraries expect to work on some particular encoding instead of on abstract Unicode characters. Many of these require the UTF 8 encoding, while others might expect UTF 16, or UTF 32. In contrast, Perl and Java are agnostic on encodings, instead operating on decoded characters internally. Supported Unicode range. Many regex engines support only the Basic Multilingual Plane, that is, the characters which can be encoded with only 16 bits. Currently (as of as of 2016) only a few regex engines (e. g., Perl's and Java's) can handle the full 21 bit Unicode range. Extending ASCII oriented constructs to Unicode. For example, in ASCII based implementations, character ranges of the form [x y] are valid wherever x and y have code points in the range [0x00,0x7F] and codepoint(x) ≤ codepoint(y). The natural extension of such character ranges to Unicode would simply change the requirement that the endpoints lie in [0x00,0x7F] to the requirement that they lie in [0x0000,0x10FFFF]. However, in practice this is often not the case. Some implementations, such as that of gawk, do not allow character ranges to cross Unicode blocks. A range like [0x61,0x7F] is valid since both endpoints fall within the Basic Latin block, as is [0x0530,0x0560] since both endpoints fall within the Armenian block, but a range like [0x0061,0x0532] is invalid since it includes multiple Unicode blocks. Other engines, such as that of the Vim editor, allow block crossing but the character values must not be more than 256 apart. Case insensitivity. Some case insensitivity flags affect only the ASCII characters. Other flags affect all characters. Some engines have two different flags, one for ASCII, the other for Unicode. Exactly which characters belong to the POSIX classes also varies. Cousins of case insensitivity. As ASCII has case distinction, case insensitivity became a logical feature in text searching. Unicode introduced alphabetic scripts without case like Devanagari. For these, case sensitivity is not applicable. For scripts like Chinese, another distinction seems logical: between traditional and simplified. In Arabic scripts, insensitivity to initial, medial, final, and isolated position may be desired. In Japanese, insensitivity between hiragana and katakana is sometimes useful. Normalization. Unicode has combining characters. Like old typewriters, plain base characters (white spaces, punctuation characters, symbols, digits, or letters) can be followed by one or more non spacing symbols (usually diacritics, like accent marks modifying letters) to form a single printable character; but Unicode also provides a limited set of precomposed characters, i. e. characters that already include one or more combining characters. A sequence of a base character + combining characters should be matched with the identical single precomposed character (only some of these combining sequences can be precomposed into a single Unicode character, but infinitely many other combining sequences are possible in Unicode, and needed for various languages, using one or more combining characters after an initial base character; these combining sequences may include a base character or combining characters partially precomposed, but not necessarily in canonical order and not necessarily using the canonical precompositions). The process of standardizing sequences of a base character + combining characters by decomposing these canonically equivalent sequences, before reordering them into canonical order (and optionally recomposing some combining characters into the leading base character) is called normalization. New control codes. Unicode introduced amongst others, byte order marks and text direction markers. These codes might have to be dealt with in a special way. Introduction of character classes for Unicode blocks, scripts, and numerous other character properties. Block properties are much less useful than script properties, because a block can have code points from several different scripts, and a script can have code points from several different blocks. In Perl and the library, properties of the form \p{InX} or \p{Block=X} match characters in block X and \P{InX} or \P{Block=X} matches code points not in that block. Similarly, \p{Armenian}, \p{IsArmenian}, or \p{Script=Armenian} matches any character in the Armenian script. In general, \p{X} matches any character with either the binary property X or the general category X. For example, \p{Lu}, \p{Uppercase Letter}, or \p{GC=Lu} matches any uppercase letter. Binary properties that are not general categories include \p{White Space}, \p{Alphabetic}, \p{Math}, and \p{Dash}. Examples of non binary properties are \p{Bidi Class=Right to Left}, \p{Word Break=A Letter}, and \p{Numeric Value=10}.

Тілдік қолдау

Көптеген жалпы мақсаттағы бағдарламалау тілдері режекс мүмкіндіктерін не туғаннан, не кітапханалар арқылы қолдайды. Толыққанды қолдау келесілерде қамтылған:

Қолданылуы

Регулярлы өрнектер мәтін өңдеудің, және жалпы алғанда, мәтіндік емес деректермен жұмыс істеудің түрлі тапсырмаларында пайдалы. Көптеген қолданыс салаларының ішінде деректерді тексеру, деректерді жинау (әсіресе вебтен дерек жинау), деректерді қайта өңдеу, қарапайым талдау, синтаксистік бөліштерді көрсету жүйелерін құру және тағы да көптеген міндеттер бар. Регулярлы өрнектер интернет іздеу жүйелерінде тиімді болғанымен, оларды бүкіл деректер базасында өңдеу, өрнектің күрделігіне және құрылымына байланысты, компьютерлік ресурстарды тым көп жұмсауы мүмкін. Көп жағдайда жүйе әкімшілері регулярлы өрнектерге негізделген сұраныстарды ішкі жүйеде орындай білсе де, көптеген іздеу жүйелері бұл мүмкіндікті жалпы қолданушыларға ұсынбайды. Google Code Search және Exalead осы ереженің ерекше жағдайлары. Дегенмен, Google Code Search 2012 жылдың қаңтар айында тоқтатылды.

Индукция

Үлгілі өрнектерді мысалдар жиынтығы негізінде жиі жасауға болады ("сауықтыру" немесе "оқыту"). Бұл жүйелі тілдерді индукциялау деп аталады және есептеу оқыту теориясындағы грамматикалық индукцияның жалпы мәселесінің бір бөлігі болып табылады. Формальды түрде, егер жүйелі тілдегі тізбектердің мысалдары берілсе, және мүмкін, сол жүйелі тілге жатпайтын тізбектердің мысалдары да берілсе, онда сол тілдің грамматикасын, яғни осы тілді құратын үлгілі өрнекті тудыруға болады. Барлық жүйелі тілдерді осылай индукциялау мүмкін емес (шектегі тілдерді анықтауға қараңыз), бірақ көптеген тілдерді индукциялауға болады. Мысалы, {1, 10, 100} мысалдар жиынтығы және {11, 1001, 101, 0} теріс жиынтығы (қарсы мысалдар) 1⋅0* (1-ден кейін нөл немесе одан көп 0-лер) үлгілі өрнегін индукциялау үшін қолданылуы мүмкін.