Доброго времени суток, друзья!

Представляю Вашему вниманию перевод статьи Regex Cheat Sheet автора Emma Bostian.

Регулярные выражения или regex используются для поиска совпадений в строке.

Ищем совпадение по шаблону

Используем метод .test()

const testString = 'My test string'const testRegex = /string/testRegex.test(testString) // true

Ищем совпадение по нескольким шаблонам

Используем | альтернацию

const regex = /yes|no|maybe/

Игнорируем регистр

Используем флаг i

const caseInsensitiveRegex = /ignore case/iconst testString = 'We use the i flag to iGnOrE CasE'caseInsensitiveRegex.test(testString) // true

Извлекаем первое совпадение в переменную

Используем метод .match()

const match = 'Hello World!'.macth(/hello/i) // 'Hello'

Извлекаем все совпадения в массив

Используем флаг g

const testString = 'Repeat repeat rePeAt'const regexWithAllMatches = /Repeat/gitestString.match(regexWithAllMatches) // ['Repeat', 'repeat', 'rePeAt']

Ищем любой символ

Используем символ.

const regexWithWildCard = /.at/giconst testString = 'cat BAT cupcake fAt mat dog'const allMatchingWords = testString.match(regexWithWildCard) // ['cat', 'BAT', 'fAt', 'mat']

Ищем один вариативный символ

Используем классы, позволяющие в [ ] определять группу искомых символов

const regexWithCharClass = /[cfm]at/gconst testString = 'cat fat bat mat'const allMatchingWords = testString.match(regexWithCharClass) // ['cat', 'fat', 'mat']

Ищем буквы алфавита

Используем диапазон [a-z]

const regexWithCharRange = /[a-e]at/const catString = 'cat'const batString = 'bat'const fatString = 'fat'regexWithCharRange.test(catString) // trueregexWithCharRange.test(batString) // trueregexWithCharRange.test(fatString) // false

Ищем определенные числа или буквы

Используем диапазон [a-z0-9]

const regexWithLetterAndNumberRange = /[a-z0-9]/igconst testString = 'Emma19382'testString.macth(regexWithLetterAndNumberRange) // true

Ищем единственный неизвестный символ

Для исключения ненужных символов используем символ ^ отрицательный набор

const allCharsNotAllowed = /[^aeiou]/giconst allCharsOrNumbersNotAllowed = /^aeiou0-9/gi

Ищем символы, встречающиеся в строке один или более раз

Используем символ +

const oneOrMoreAsRegex = /a+/giconst oneOrMoreSsRegex = /s+/giconst cityInFlorida = 'Tallahassee'cityInFlorida.match(oneOrMoreAsRegex) // ['a', 'a', 'a']cityInFlorida.match(oneOrMoreSsRegex) // ['ss']

Ищем символы, встречающиеся в строке ноль или более раз

Используем символ *

const zeroOrMoreOsRegex = /hi*/giconst normalHi = 'hi'const happyHi = 'hiiiiii'const twoHis = 'hiihii'const bye = 'bye'normalHi.match(zeroOrMoreOsRegex) // ['hi']happyHi.match(zeroOrMoreOsRegex) // ['hiiiiii']twoHis.match(zeroOrMoreOsRegex) // ['hii', 'hii']bye.match(zeroOrMoreOsRegex) // null

Ленивый поиск совпадений

Ищем наименьшую часть строки, удовлетворяющую заданному условию.
Regex по умолчанию является жадным (ищет самую длинную часть строки, удовлетворяющую условию). Используем символ?

const testString = 'catastrophe'const greedyRegex = /c[a-z]*t/giconst lazyRegex = /c[a-z]*?t/gitestString.match(greedyRegex) // ['catast']testString.match(lazyRegex) // ['cat']

Ищем с помощью стартового шаблона (шаблона начала строки)

Для поиска строки по стартовому шаблону используем символ ^ (снаружи набора символов в [ ] в отличие от отрицательного набора)

const emmaAtFrontOfString = 'Emma likes cats a lot.'const emmaNotAtFrontOfString = 'the cats Emma likes are fluffy'const startingStringRegex = /^Emma/startingStringRegex.test(emmaAtFrontOfString) // truestartingStringRegex.test(emmaNotAtFrontOfString) // false

Ищем с помощью завершающего шаблона (шаблона конца строки)

Для поиска строки по завершающему шаблону используем символ $

const emmaAtBackOfString = 'The cats do not like Emma'const emmaNotAtBackOfString = 'Emma loves the cats'const endingStringRegex = /Emma$/endingStringRegex.test(emmaAtBackOfString) // trueendingStringRegex.test(emmaNotAtBackOfString) // false

Ищем все буквы или числа

Используем \w

const longHand = /[A-za-z0-9_]+/const shortHand = /\w+/const numbers = '42'const myFavouriteColor = 'magenta'longHand.test(numbers) // trueshortHand.test(numbers) // truelongHand.test(myFavouriteColor) // trueshortHand.test(myFavouriteColor) // true

Ищем любые символы, за исключением букв и чисел

Используем \W

const noAlphaNumericCharRegex = /\W/giconst weirdCharacters = '!_$!'const alphaNumericCharacters = 'ab24EF'noAlphaNumericCharRegex.test(weirdCharacters) // truenoAlphaNumericCharRegex.test(alphaNumericCharacters) // true

Ищем числа

Используем \d вместо [0-9]

const digitsRegex = /\d/gconst stringWithDigits = 'My cat eats $20.00 worth of food a week'stringWithDigits.match(digitsRegex) // ['2', '0', '0', '0']

Ищем не числа

Используем \D

const nonDigitsRegex = /\D/gconst stringWithLetters = '101 degrees'stringWithLetters.match(nonDigitsRegex) // [' ', 'd', 'e', 'g', 'r', 'e', 'e', 's']

Ищем пробелы

Используем \s

const sentenceWithWhitespace = 'I like cats!'const spaceRegex = /\s/gspaceRegex.match(sentenceWithWhitespace) // [' ', ' ']

Ищем любые символы, за исключением пробелов

Используем \S

const sentenceWithWhitespace = 'C a t'const nonWhitespaceRegex = /\S/gsentenceWithWhitespace.match(nonWhitespaceRegex) // ['C', 'a', 't']

Ищем определенное количество символов

Используем {от, до} квантификатор

const regularHi = 'hi'const mediocreHi = 'hiii'const superExcitedHey = 'heeeeyyyyy!!!'const excitedRegex = /hi{1,4}/excitedRegex.test(regularHi) // trueexcitedRegex.test(mediocreHi) // trueexcitedRegex.test(superExcitedHey) // false

Ищем минимальное количество символов

Используем {от, }

const regularHi = 'hi'const mediocreHi = 'hiii'const superExcitedHey = 'heeeeyyyyy!!!'const excitedRegex = /hi{2,}/excitedRegex.test(regularHi) // falseexcitedRegex.test(mediocreHi) // trueexcitedRegex.test(superExcitedHey) // false

Ищем точное количество символов

Используем {число символов}

const regularHi = 'hi'const mediocreHi = 'hiii'const superExcitedHey = 'heeeeyyyyy!!!'const excitedRegex = /hi{2}/excitedRegex.test(regularHi) // falseexcitedRegex.test(mediocreHi) // trueexcitedRegex.test(superExcitedHey) // false

Ищем ноль или один символ

Используем ? после искомого символа

const britishSpelling = 'colour'const americanSpelling = 'Color'const langRegex = /coloru?r/ilangRegex.test(britishSpelling) // truelangRegex.test(americanSpelling) // true

Прим. пер.: шпаргалка от MDN.

Благодарю за потраченное время. Надеюсь, оно было потрачено не зря.

Сегодня мы померяемся парсерами. Точнее, померяем эффективность разных вариантов JavaScript-парсеров на примере одной простой задачи преобразования строки конкретного формата в объект.


Вопросы сложностей организации многопоточности в JavaScript оставим за рамками этой статьи и сосредоточимся на различных вариантах и малоизвестных способах использования регулярных выражений для разбора строки buffers-атрибута узла плана PostgreSQL.

То есть из строки вида 'Buffers: shared hit=123 read=456, local hit=789' мы хотим как можно быстрее получить JSON такого формата:

{  "shared-hit"  : 123, "shared-read" : 456, "local-hit"   : 789}

Выглядит вроде все тривиально, правда же?

Немного предыстории

Откуда вообще возникла такая задача разбирать строки как можно быстрее?

Я уже рассказывал, что у нас в Тензоре используется много сотен серверов PostgreSQL. И чтобы приглядывать за актуальной производительностью запросов на них, мы разработали коллектор-анализатор логов этой СУБД, который выцепляет из потока от сервера планы запросов, разбирает их и вычисляет нагрузку для каждого отдельного узла, что не так уж и просто.

То есть надо уметь сидеть на потоке и быстро-быстро анализировать (а потому иметь максимальную производительность и минимальный прирост памяти) примерно вот такие блоки текста, а среди них и наши buffers-строки:

Hash Left Join (actual time=9.248..51.659 rows=551 loops=1)  Hash Cond: (c.reloftype = t.oid)  Buffers: shared hit=5814 read=251 dirtied=63  ->  Hash Join (actual time=2.990..7.148 rows=551 loops=1)        Hash Cond: (c.relnamespace = nc.oid)        Buffers: shared hit=4249 read=2        ->  Seq Scan on pg_class c (actual time=0.046..3.922 rows=555 loops=1)              Filter: ((relkind = ANY ('{r,v,f,p}'::"char"[])) AND (pg_has_role(relowner, 'USAGE'::text) OR has_table_privilege(oid, 'SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER'::text) OR has_any_column_privilege(oid, 'SELECT, INSERT, UPDATE, REFERENCES'::text)))              Rows Removed by Filter: 3308              Buffers: shared hit=1829        ->  Hash (actual time=2.931..2.931 rows=7 loops=1)              Buckets: 1024  Batches: 1  Memory Usage: 9kB              Buffers: shared hit=2420 read=2              ->  Seq Scan on pg_namespace nc (actual time=0.035..2.912 rows=7 loops=1)                    Filter: (NOT pg_is_other_temp_schema(oid))                    Rows Removed by Filter: 784                    Buffers: shared hit=2420 read=2  ->  Hash (actual time=6.199..6.199 rows=1629 loops=1)        Buckets: 2048  Batches: 1  Memory Usage: 277kB        Buffers: shared hit=105 read=162 dirtied=63        ->  Hash Join (actual time=0.338..5.640 rows=1629 loops=1)              Hash Cond: (t.typnamespace = nt.oid)              Buffers: shared hit=105 read=162 dirtied=63              ->  Seq Scan on pg_type t (actual time=0.015..4.910 rows=1629 loops=1)                    Buffers: shared hit=57 read=162 dirtied=63              ->  Hash (actual time=0.307..0.307 rows=791 loops=1)                    Buckets: 1024  Batches: 1  Memory Usage: 86kB                    Buffers: shared hit=48                    ->  Seq Scan on pg_namespace nt (actual time=0.004..0.121 rows=791 loops=1)                          Buffers: shared hit=48

Формат строки

В общем случае, формат описан в исходниках PostgreSQL. Если представить его в виде JS-кода, то получится что-то вроде:

const keys = [  ['shared', ['hit', 'read', 'dirtied', 'written']], ['local',  ['hit', 'read', 'dirtied', 'written']], ['temp',   ['read', 'written']] // да, тут другой набор ключей 2-го уровня];let str = 'Buffers: ' + // константное начало  keys    .filter(([keyo, keysi]) => node[keyo])    .map(([keyo, keysi]) => [        keyo      , ...keysi          .filter(keyi => node[keyo][keyi] > 0)          .map(keyi => `${keyi}=${node[keyo][keyi]}`)      ].join(' ') // внутри собираем сегменты через пробел    )    .join(', ');  // снаружи - через запятая-пробел

Методика тестирования

Но поскольку парсить пробелы неинтересно совсем, давайте сразу договоримся, что экспериментировать мы будем на уже нормализованном наборе, где они убраны:

Buffers: shared hit=31770Buffers: shared hit=1159Buffers: shared hit=255Buffers: shared hit=2579 read=2961 dirtied=3Buffers: shared hit=3 read=1Buffers: shared hit=205 read=44Buffers: shared hit=230 read=34 dirtied=3Buffers: shared hit=13Buffers: shared hit=5Buffers: shared hit=6...

Чтобы исключить возможное влияние GC, запускать наши тесты будем с ключами --expose-gc --initial-old-space-size=1024. Оцениваем всех участников по двум показателям: общее время работы и прирост объема памяти, который пришлось использовать (и на чистку которого потом придется потратить время GC и ресурсы CPU).

Шаблон нашего теста будет выглядеть примерно так:

const fs = require('fs');const heapdump = require('heapdump');const buffers = fs.readFileSync('buffers.txt').toString().split('\n');const parseBuffers = line => {// -- 8< --// ...// -- 8< --};global.gc();// нулевое состояние до тестаheapdump.writeSnapshot();const hrb = process.hrtime();for (let line of buffers) {  let obj = parseBuffers(line);}const hre = process.hrtime(hrb);// состояние памяти после тестаheapdump.writeSnapshot();const usec = hre[0] * 1e+9 + hre[1];console.log(usec);

Что ж Приступим, и постараемся грамотно использовать все возможности, которые дают нам современные версии языка.


И начнем с самого простого.

Бронза: обыкновенный .split

const parseBuffers = line => {  let rv = {};  line.slice('Buffers: '.length)              // "константное" начало нас не интересует    .split(', ').forEach(part => {            // 'shared ..., local ..., temp ...' => ['shared ...', 'local ...', 'temp ...']      let [kind, ...pairs] = part.split(' '); // 'shared hit=1 read=2' => ['shared', ['hit=1', 'read=2']]      pairs.forEach(pair => {        let [type, val] = pair.split('=');    // 'hit=1' => ['hit', '1']        rv[`${kind}-${type}`] = Number(val);  // ['shared-hit'] = 1      });    });  return rv;};

Time, avg: 544msSize Delta: +14.8MB: - (sliced string) : +6.8 // сегменты строк без 'Buffers: ' - (string)        : +6.3 // строки имен ключей - (array)         : +1.7 // массивы pairs

Серебро: .lastIndex + итерация по .matchAll(RegExp)

Итак, сделаем выводы из предыдущего теста: .slice и .split нам не друзья, как и динамическая генерация имен ключей.

С именами ключей все понятно давайте сгенерируем их все заранее, их же всего 10 вариантов. А вот .slice строки мы использовали, только лишь чтобы каждый раз сдвинуть начало анализа на одинаковое начало 'Buffers: '. А нельзя ли как-то сделать это без порождения новых строк?

Оказывается, можно, если использовать принудительную установку re.lastIndex для глобального RegExp.

Подробнее про g- и y-ключи и использование .lastIndex для более точного применения RegExp.

На этот раз будем искать в строке только те ключевые слова, которые нас интересуют:

const buffersRE = /(shared|local|temp)|(hit|read|dirtied|written)=(\d+)/g;const buffersKeys = {  'shared' : {    'hit'     : 'shared-hit'  , 'read'    : 'shared-read'  , 'dirtied' : 'shared-dirtied'  , 'written' : 'shared-written'  }, 'local' : {    'hit'     : 'local-hit'  , 'read'    : 'local-read'  , 'dirtied' : 'local-dirtied'  , 'written' : 'local-written'  }, 'temp' : {    'read'    : 'temp-read'  , 'written' : 'temp-written'  }};const parseBuffers = line => {  let rv = {};  let keys;  buffersRE.lastIndex = 9; // сдвигаем начало поиска на 'Buffers: '.length  for (let match of line.matchAll(buffersRE)) {    if (match[1]) {      keys = buffersKeys[match[1]];    }    else {      rv[keys[match[2]]] = Number(match[3]);    }  }  return rv;};

Time, avg: 270msSize Delta: +8.5MB

Золото: полнопозиционный .match(RegExp)

Но ни в одном из предыдущих вариантов мы никак не использовали информацию о том, что наши потенциальные ключи идут в строго определенном порядке.

Чтобы не заниматься двухуровневым спуском по словарю за именами ключей, построим такой страшный RegExp, каждая захватываемая позиция которого всегда соответствует одному и тому же имени ключа. Позиции отсутствующих в строке ключей будут заполнены в match-массиве undefined:

const buffersRE = /^Buffers:(?:,? shared(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? local(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? temp(?: read=(\d+))?(?: written=(\d+))?)?$/;const buffersKeys = ['shared-hit', 'shared-read', 'shared-dirtied', 'shared-written', 'local-hit', 'local-read', 'local-dirtied', 'local-written', 'temp-read', 'temp-written'];const parseBuffers = line =>   line.match(buffersRE)    .slice(1) // в match[0] лежит исходная строка, которая нам не нужна    .reduce(      (rv, val, idx) => (val !== undefined && (rv[buffersKeys[idx]] = Number(val)), rv)    , {}    );

Time, avg: 111msSize Delta: +8.5MB

Наблюдательный читатель сразу же задаст вопрос разве не будет быстрее, если убрать из регулярки константное начало '^Buffers:':

const buffersRE = /(?:,? shared(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? local(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? temp(?: read=(\d+))?(?: written=(\d+))?)?$/;

Ведь результат от этого не должен никак измениться? Но нет, такой вариант на четверть хуже:

Time, avg: 140ms

Дело в том, что наш полный RegExp /^...$/ не содержит ни одной переменной части, а в случае без начала для каждой позиции этого сегмента приходится проверять, не начинается ли тут один из хвостов (shared ...|local ...|temp ...) что требует гораздо больше ресурсов, чем просто впустую проверить совпадение двух подстрок.

Вне конкурса: скрещиваем ужа и ежа

В предыдущем варианте мы все-таки внесли начало строки в регулярку, и оно проверяется каждый раз! Давайте же воспользуемся методом с .lastIndex:

• но он работает только с глобальными RegExp
• для глобального RegExp обычный .match захватывает сразу всю строку, а не позиционно
• для получения позиционного набора нам придется использовать первый (а на самом деле, единственный) результат итератора .matchAll

const buffersRE = /(?:,? shared(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? local(?: hit=(\d+))?(?: read=(\d+))?(?: dirtied=(\d+))?(?: written=(\d+))?)?(?:,? temp(?: read=(\d+))?(?: written=(\d+))?)?$/g;const buffersKeys = ['shared-hit', 'shared-read', 'shared-dirtied', 'shared-written', 'local-hit', 'local-read', 'local-dirtied', 'local-written', 'temp-read', 'temp-written'];const parseBuffers = line => {  buffersRE.lastIndex = 8; // 'Buffers:'.length  return line.matchAll(buffersRE).next().value    .slice(1)    .reduce(      (rv, val, idx) => (val !== undefined && (rv[buffersKeys[idx]] = Number(val)), rv)    , {}    );};

Time, avg: 304msSize Delta: +8.5MB

То есть наш странный гибрид по памяти никакого выигрыша не дал, а по скорости проиграл обоим своим родителям.

Итого

В сегодняшнем забеге кубок вручается обычному полнопозиционному .match(RegExp). Ура, товарищи!

Здравствуйте, меня зовут Дмитрий Карловский и раньше я тоже использовал Perl для разработки фронтенда. Только гляньте, каким лаконичным кодом можно распарсить, например, имейл:

/^(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,})|("(?:((?:(?:([\u{1}-\u{8}\u{b}\u{c}\u{e}-\u{1f}\u{21}\u{23}-\u{5b}\u{5d}-\u{7f}])|(\\[\u{1}-\u{9}\u{b}\u{c}\u{e}-\u{7f}]))){0,}))"))@(?:((?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}(?:\.(?:[\w!#\$%&'\*\+\/=\?\^`\{\|\}~-]){1,}){0,}))$/gsu

Тут, правда, закралось несколько ошибок. Ну ничего, пофиксим в следующем релизе!

Шутки в сторону

По мере роста, регулярки очень быстро теряют свою понятность. Не зря в интернете есть десятки сервисов для отладки регулярок. Вот лишь некоторые из них:

• https://regex101.com/
• https://regexr.com/
• https://www.debuggex.com/
• https://extendsclass.com/regex-tester.html

А с внедрением новых фичей, они теряют и лаконичность:

/(?<слово>(?<буквица>\p{Script=Cyrillic})\p{Script=Cyrillic}+)/gimsu

У регулярок довольно развесистых синтаксис, который то и дело выветривается из памяти, что требует постоянное подсматривание в шпаргалку. Чего только стоят 5 разных способов экранирования:

/\t//\ci//\x09//\u0009//\u{9}/u

В JS у нас есть интерполяция строк, но как быть с регулярками?

const text = 'lol;)'// SyntaxError: Invalid regular expression: /^(lol;)){2}$/: Unmatched ')'const regexp = new RegExp( `^(${ text }){2}$` )

Ну, или у нас есть несколько простых регулярок, и мы хотим собрать из них одну сложную:

const VISA = /(?<type>4)\d{12}(?:\d{3})?/const MasterCard = /(?<type>5)[12345]\d{14}/// Invalid regular expression: /(?<type>4)\d{12}(?:\d{3})?|(?<type>5)[12345]\d{14}/: Duplicate capture group nameconst CardNumber = new RegExp( VISA.source + '|' + MasterCard.source )

Короче, писать их сложно, читать невозможно, а рефакторить вообще адски! Какие есть альтернативы?

Свои регулярки с распутным синтаксисом

Полностью своя реализация регулярок на JS. Для примера возьмём XRegExp:

• API совместимо с нативным.
• Можно форматировать пробелами.
• Можно оставлять комментарии.
• Можно расширять своими плагинами.
• Нет статической типизации.
• Отсутствует поддержка IDE.
• 

В общем, всё те же проблемы, что и у нативных регулярок, но втридорога.

Генераторы парсеров

Вы скармливаете им грамматику на специальном DSL, а они выдают вам JS код функции парсинга. Для примера возьмём PEG.js:

• Наглядный синтаксис.
• Каждая грамматика вещь в себе и не компонуется с другими.
• Нет статической типизации генерируемого парсера.
• Отсутствует поддержка IDE.
• Минимум 2 кб в ужатопережатом виде на каждую грамматику.

Пример в песочнице.

Это решение более мощное, но со своими косяками. И по воробьям из этой пушки стрелять не будешь.

Билдеры нативных регулярок

Для примера возьмём TypeScript библиотеку $mol_regexp:

• Строгая статическая типизация.
• Хорошая интеграция с IDE.
• Композиция регулярок с именованными группами захвата.
• Поддержка генерации строки, которая матчится на регулярку.
• 

Это куда более легковесное решение. Давайте попробуем сделать что-то не бесполезное..

Номера банковских карт

Импортируем компоненты билдера

Это либо функции-фабрики регулярок, либо сами регулярки.

const {    char_only, latin_only, decimal_only,    begin, tab, line_end, end,    repeat, repeat_greedy, from,} = $mol_regexp

Ну или так, если вы ещё используете NPM

import { $mol_regexp: {    char_only, decimal_only,    begin, tab, line_end,    repeat, from,} } from 'mol_regexp'

Пишем регулярки для разных типов карт

// /4(?:\d){12,}?(?:(?:\d){3,}?){0,1}/gsuconst VISA = from([    '4',    repeat( decimal_only, 12 ),    [ repeat( decimal_only, 3 ) ],])// /5[12345](?:\d){14,}?/gsuconst MasterCard = from([    '5',    char_only( '12345' ),    repeat( decimal_only, 14 ),])

В фабрику можно передавать:

• Строку и тогда она будет заэкранирована.
• Число и оно будет интерпретировано как юникод кодепоинт.
• Другую регулярку и она будет вставлена как есть.
• Массив и он будет трактован как последовательность выражений. Вложенный массив уже используется для указания на опциональность вложенной последовательности.
• Объект означающий захват одного из вариантов с именем соответствующим полю объекта (далее будет пример).

Компонуем в одну регулярку

// /(?:(4(?:\d){12,}?(?:(?:\d){3,}?){0,1})|(5[12345](?:\d){14,}?))/gsuconst CardNumber = from({ VISA, MasterCard })

Строка списка карт

// /^(?:\t){0,}?(?:((?:(4(?:\d){12,}?(?:(?:\d){3,}?){0,1})|(5[12345](?:\d){14,}?))))(?:((?:\r){0,1}\n)|(\r))/gmsuconst CardRow = from(    [ begin, repeat( tab ), {CardNumber}, line_end ],    { multiline: true },)

Сам список карточек

const cards = `    3123456789012    4123456789012    551234567890123    5512345678901234`

Парсим текст регуляркой

for( const token of cards.matchAll( CardRow ) ) {    if( !token.groups ) {        if( !token[0].trim() ) continue        console.log( 'Ошибка номера', token[0].trim() )        continue    }    const type = ''        || token.groups.VISA && 'Карта VISA'        || token.groups.MasterCard && 'MasterCard'    console.log( type, token.groups.CardNumber )}

Тут, правда, есть небольшое отличие от нативного поведения. matchAll с нативными регулярками выдаёт токен лишь для совпавших подстрок, игнорируя весь текст между ними. $mol_regexp же для текста между совпавшими подстроками выдаёт специальный токен. Отличить его можно по отсутствию поля groups. Эта вольность позволяет не просто искать подстроки, а полноценно разбивать весь текст на токены, как во взрослых парсерах.

Результат парсинга

Ошибка номера 3123456789012Карта VISA 4123456789012Ошибка номера 551234567890123MasterCard 5512345678901234

Заценить в песочнице.

E-Mail

Регулярку из начала статьи можно собрать так:

const {    begin, end,    char_only, char_range,    latin_only, slash_back,    repeat_greedy, from,} = $mol_regexp// Логин в виде пути разделённом точкамиconst atom_char = char_only( latin_only, "!#$%&'*+/=?^`{|}~-" )const atom = repeat_greedy( atom_char, 1 )const dot_atom = from([ atom, repeat_greedy([ '.', atom ]) ])// Допустимые символы в закавыченном имени сендбоксаconst name_letter = char_only(    char_range( 0x01, 0x08 ),    0x0b, 0x0c,    char_range( 0x0e, 0x1f ),    0x21,    char_range( 0x23, 0x5b ),    char_range( 0x5d, 0x7f ),)// Экранированные последовательности в имени сендбоксаconst quoted_pair = from([    slash_back,    char_only(        char_range( 0x01, 0x09 ),        0x0b, 0x0c,        char_range( 0x0e, 0x7f ),    )])// Закавыченное имя сендборксаconst name = repeat_greedy({ name_letter, quoted_pair })const quoted_name = from([ '"', {name}, '"' ])// Основные части имейла: доменная и локальнаяconst local_part = from({ dot_atom, quoted_name })const domain = dot_atom// Матчится, если вся строка является имейломconst mail = from([ begin, local_part, '@', {domain}, end ])

Но просто распарсить имейл эка невидаль. Давайте сгенерируем имейл!

//  SyntaxError: Wrong param: dot_atom=foo..barmail.generate({    dot_atom: 'foo..bar',    domain: 'example.org',})

Упс, ерунду сморозил Поправить можно так:

// foo.bar@example.orgmail.generate({    dot_atom: 'foo.bar',    domain: 'example.org',})

Или так:

// "foo..bar"@example.orgmail.generate({    name: 'foo..bar',    domain: 'example.org',})

Погонять в песочнице.

Роуты

Представим, что сеошник поймал вас в тёмном переулке и заставил сделать ему "человекопонятные" урлы вида /snjat-dvushku/s-remontom/v-vihino. Не делайте резких движений, а медленно соберите ему регулярку:

const translit = char_only( latin_only, '-' )const place = repeat_greedy( translit )const action = from({ rent: 'snjat', buy: 'kupit' })const repaired = from( 's-remontom' )const rooms = from({    one_room: 'odnushku',    two_room: 'dvushku',    any_room: 'kvartiru',})const route = from([    begin,    '/', {action}, '-', {rooms},    [ '/', {repaired} ],    [ '/v-', {place} ],    end,])

Теперь подсуньте в неё урл и получите структурированную информацию:

// `/snjat-dvushku/v-vihino`.matchAll(route).next().value.groups{    action: "snjat",    rent: "snjat",    buy: "",    rooms: "dvushku",    one_room: "",    two_room: "dvushku",    any_room: "",    repaired: "",    place: "vihino",}

А когда потребуется сгенерировать новый урл, то просто задайте группам нужные значения:

// /kupit-kvartiru/v-moskveroute.generate({    buy: true,    any_room: true,    repaired: false,    place: 'moskve',})

Если задать true, то значение будет взято из самой регулярки. А если false, то будет скипнуто вместе со всем опциональным блоком.

И пока сеошник радостно потирает руки предвкушая первое место в выдаче, незаметно достаньте телефон, вызовите полицию, а сами скройтесь в песочнице.

Как это работает?

Нативные именованные группы, как мы выяснили ранее, не компонуются. Попадётся вам 2 регулярки с одинаковыми именами групп и всё, поехали за костылями. Поэтому при генерации регулярки используются анонимные группы. Но в каждую регулярку просовывается массив groups со списком имён:

// time.source == "((\d{2}):(\d{2}))"// time.groups == [ 'time', 'hours', 'minutes' ]const time = from({    time: [        { hours: repeat( decimal_only, 2 ) },        ':',        { minutes: repeat( decimal_only, 2 ) },    ],)

Наследуемся, переопределям exec и добавляем пост-процессинг результата с формированием в нём объекта groups вида:

{    time: '12:34',    hours: '12,    minutes: '34',}

И всё бы хорошо, да только если скомпоновать с нативной регуляркой, содержащей анонимные группы, но не содержащей имён групп, то всё поедет:

// time.source == "((\d{2}):(\d{2}))"// time.groups == [ 'time', 'minutes' ]const time = wrong_from({    time: [        /(\d{2})/,        ':',        { minutes: repeat( decimal_only, 2 ) },    ],)

{    time: '12:34',    hours: '34,    minutes: undefined,}

Чтобы такого не происходило, при композиции с обычной нативной регуляркой, нужно "замерить" сколько в ней объявлено групп и дать им искусственные имена "0", "1" и тд. Сделать это не сложно достаточно поправить регулярку, чтобы она точно совпала с пустой строкой, и посчитать число возвращённых групп:

new RegExp( '|' + regexp.source ).exec('').length - 1

И всё бы хорошо, да только String..match и String..matchAll клали шуруп на наш чудесный exec. Однако, их можно научить уму разуму, переопределив для регулярки методы Symbol.match и Symbol.matchAll. Например:

*[Symbol.matchAll] (str:string) {    const index = this.lastIndex    this.lastIndex = 0    while ( this.lastIndex < str.length ) {        const found = this.exec(str)        if( !found ) break        yield found    }    this.lastIndex = index}

И всё бы хорошо, да только тайпскрипт всё равно не поймёт, какие в регулярке есть именованные группы:

interface RegExpMatchArray {    groups?: {        [key: string]: string    }}

Что ж, активируем режим обезьянки и поправим это недоразумение:

interface String {    match< RE extends RegExp >( regexp: RE ): ReturnType<        RE[ typeof Symbol.match ]    >    matchAll< RE extends RegExp >( regexp: RE ): ReturnType<        RE[ typeof Symbol.matchAll ]    >}

Теперь TypeScript будет брать типы для groups из переданной регулярки, а не использовать какие-то свои захардкоженные.

Ещё из интересного там есть рекурсивное слияние типов групп, но это уже совсем другая история.

Напутствие

• Подробности в документация по $mol_regexp.
• Пример из дикой природы токенайзеры MarkedText: $hyoo_marked.
• Другие микро библиотеки из экосистемы MAM доступные в NPM.
• Если у вас аллергия на $mol, то в этой статье можете найти ещё несколько популярных библиотек для парсинга.

Но что бы вы ни выбрали знайте, что каждый раз, когда вы пишете регулярку вручную, где-то в интернете плачет (от счастья) один верблюд.

1-6 марта приглашаем на мероприятия, приуроченные к Международному Дню открытых данных 2021.

Это крупнейшее ежегодное международное событие, которое помогает продвигать концепцию открытых данных среди органов государственной власти, бизнес-корпораций, некоммерческих организаций и гражданского общества. Организатором Дня открытых данных в России выступает АНО Информационная культура.

Рассказываем, какие мероприятия мы приготовили для участников в этом году.
Накануне Дня открытых данных, с 1 по 5 марта, проведем серию практических онлайн мастер-классов по работе с открытыми данными.

• 1 марта, мастер-класс Вскрываем декларации. Как при помощи регулярных выражений привести Wordовскую табличку к пригодной для анализа форме. Доступна видеозапись.
• 2 марта, мастер-класс О чем говорят депутаты Госдумы? Анализ текстовых данных на Python.
• 3 марта, мастер-классы по работе с геопространственными данными и картами для новичков и профи.
• 4 марта, мастер-класс по поиску открытых данных от DataMasters.
• 5 марта, мастер-класс Российская официальная статистика: как сделать работу с данными удобнее, а данные понятнее?.
• 5 марта, мастер-класс Визуализация данных в ObservableHQ.

6 марта пройдет онлайн-конференция День открытых данных.

В центре внимания вопросы о том, что происходит с открытостью в России и мире и как использовать данные для эффективного решения конкретных проблем и задач общества. В дискуссиях примут участие не только российские эксперты, но и представители крупнейших международных проектов, продвигающих ценности и идеологию открытых данных: Global Data Barometer, The Humanitarian Data Exchange.

В программе дискуссии и выступления:

• Дискуссия. Бизнес на открытости: зачем заниматься открытым кодом и открытыми данными
• Дискуссия. Как инструменты оценки влияют на открытость государства?
• Дискуссия. Доступность данных о госфинансах
• Дискуссия. Данные переписи населения 2021: приватность vs. польза для общества
• Выступления. Что происходит с тематикой открытости в мире?

Программа и регистрация: opendataday.ru/msk. Трансляция будет доступна и бесплатна для всех желающих.