Рубрика «regular expressions»

image

Регулярное выражение (далее также — регулярка) — это последовательность специальных символов, формирующих паттерн или шаблон (pattern), который сопоставляется со строкой.

Цель такого сопоставления может состоять либо в поиске подстроки в строке, например, для замены подстроки, либо в определении соответствия строки шаблону для валидации строки.

В данной статье мы сосредоточимся на валидации.

Что конкретно мы будем делать? Мы возьмем несколько регулярок из validator.js (наиболее популярной библиотеки для валидации данных с помощью регулярных выражений) и произведем их подробный разбор. Также мы рассмотрим несколько дополнительных регулярок и один алгоритм.

Как результат, мы реализуем несколько полезных функций, которые вы впоследствии сможете использовать в своих проектах.

Читать полностью »

Привет! Эта статья про плагин Rainbow CSV, который я написал для 5 текстовых редакторов:

VS Code, Vim, Sublime Text 3, Atom, Gedit

Думаю, что многие читатели этой статьи периодически сталкиваются с CSV (comma-separated), ТSV (tab-separated) и подобными файлами. Если попробовать открыть их в текстовом редакторе (а как иначе узнать что там внутри?), то откроется совершенно невзрачная картина как с левой стороны изображения. Глядя на это сложно сказать даже сколько колонок в таблице. С правой стороны картинки тот же файл с включенным RainbowCSV, читаемость значительно повысилась за счет синтаксической подсветки.

image

Читать полностью »

RegExp Unicode Property Escapes перешли на 4-ю ступень и будут включены в ES2018.

В V8 они доступны без флага начиная с v6.4, так что готовы к использованию во всех текущих каналах Google Chrome от стабильного до Canary.

В Node.js они будут доступны без флага уже в v10 (выходит в апреле). В других версиях требуется флаг --harmony_regexp_property (Node.js v6–v9) или --harmony (Node.js v8-v9). Сейчас без флага их можно испробовать или в ночных сборках, или в ветке v8-canary.

При этом нужно иметь в виду, что сборки Node.js, скомпилированные без поддержки ICU, будут лишены возможности использовать этот класс регулярных выражений (подробнее см. Internationalization Support).

Подробнее о поддержке в других движках и средах см. в известной таблице (после перехода проскрольте чуть выше).

Я не буду повторять описания этой долгожданной возможности, лишь сошлюсь на несколько статей от известных специалистов: Читать полностью »

Вчера я шёл куда-то по городу и вдруг задумался, как можно реализовать на JavaScript деление строки по символам при помощи регулярного выражения и с полным учётом Юникода.

После перехода от Perl к JavaScript много лет тому назад, я всё испытывал за свой новый язык некоторый комплекс неполноценности из-за недостаточной поддержки Юникода. За всё то время, пока JavaScript совершал в этом направлении свой большой скачок (при переходе от ES5 к ES6), у меня в закладках осталось несколько хороших статей.

The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
JavaScript has a Unicode problem
Unicode-aware regular expressions in ECMAScript 6
ES6 Strings (and Unicode, ) in Depth

В последней из них предлагался рецепт разбиения строки на символы с учётом Юникода при помощи нового оператора ... Читать полностью »

I. Возможности

Когда я прочитал на MDN про String.raw(): «The static String.raw() method is a tag function of template literals, similar to the r prefix in Python or the @ prefix in C# for string literals» — я здорово обрадовался, потому что мне часто не хватало в JavaScript чего-то вроде одиночных кавычек в Perl.

Я сразу придумал несколько видов использования и стал активно применять их в скриптах.

1. Определение путей к файлам Windows без двойного экранирования.

const r = String.raw;

const test_module = require(r`e:DOCprgjsnode-libtest.js`);

2. Определение путей к ключам реестра Windows.

const r = String.raw;

const Winreg = require('winreg');

const regKey = new Winreg({
  hive: Winreg.HKCU,
  key: r`SoftwareMPC-HCMPC-HCSettings`
});

3. Создание сложных регулярных выражений из составных литералов.

См. пример кода в одной из недавних статей.

II. Ограничения

Однако со временем я стал натыкаться на неожиданные ограничения. Написав об одном из них в багтрекер V8, я получил отрезвляющее объяснение. Оказывается, хоть String.raw и выдаёт строку без интерпретации экранированных литералов, на стадии парсинга кода анализатор всё равно требует, чтобы литералы соответствовали правилам. Из этого следуют неочевидные ограничения для упомянутых случаев применения. Читать полностью »

1. C чего всё началось

Недавно у меня возникла необходимость написать очередную утилиту, обрабатывающую текстовый файл в формате, похожем на упрощённый BBCode, а именно в формате исходников для словарей ABBYY Lingvo — DSL (Dictionary Specification Language). (Не путать с другим DSL (Domain-specific language) — интересный случай, когда гипоним является омонимом к гиперониму).

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

Одной из задач утилиты было как раз нахождение этих тегов с исключением экранированных сочетаний.

Поскольку в регулярных выражениях JavaScript с недавнего времени можно пользоваться lookbehind assertions (в личных целях), я подумал, нельзя ли реализовать поиск при помощи этого средства, — тем более что в данной разновидности lookbehind можно использовать выражения переменной длины. Читать полностью »

Регулярные выражения в JavaScript понемногу догоняют PCRE.

Недавно упомянутая возможность lookbehind перешла на стадию флага --es_staging.

Разработчики V8 также начали добавлять в регулярные выражения свойства Юникода (см. общее описание и спецификацию этой характеристики символов).

В продвижении lookbehind и character properties, на мой взгляд, есть две разницы: первая возможность вводит совсем немного нового синтаксиса по сравнению со второй, зато вторая меньше изменяет поведение всего процесса (сравните количество затрагиваемых изменениями файлов в исходниках V8 по двум упомянутым ссылкам). По сути, свойства Юникода — всего лишь удобные сокращения, синонимы для разных групп codepoint-ов, поэтому от них можно ожидать минимум подвохов при интеграции в систему.

Конечно, обе возможности не советуют применять в продукции (кроме Google Chrome, они нигде в браузерах не реализованы, а Node.js только-только переходит на соответствующую им версию V8, в которой они всё равно пока под флагами).

Но для личных нужд (утилиты по обработке текста и т.д.), мне кажется, они вполне применимы. Возможно, коду разработчиков V8, даже экспериментальному, можно порой доверять с ничуть не большим риском, чем разнообразным библиотекам на npmjs или GitHub.Читать полностью »

Кажется, прошла незамеченной хорошая новость.

Разработчики V8 активно взялись за добавление lookbehind assertions в регулярные выражения JavaScript.

Несмотря на уверения в последнем абзаце статьи, я не смог проверить эту возможность в Google Chrome Canary.

Но.

В этом месяце выходит шестая версия Node.js, основанная на V8 5.0, и в ней уже можно включить поддержку lookbehind при помощи флага командной строки --harmony_regexp_lookbehind.

Если совсем не терпится, можно потестировать на последней ночной сборке шестой версии (она, правда, старовата, месячной давности, но в неё включена V8 4.9, где как раз появилась поддержка lookbehind). Для Windows можно даже просто скачать портабельные бинарники из папок win-x64 или win-x86. Читать полностью »

Кто-то парсирует текстовый файл программой на Питоне, другой пишет скрипт с регулярными выражениями на Перле, Си-программист стыдливо возится с буферами и указателями, иногда применяя Yacc и Lex.

А можно ли парсировать текст голым железом? Вообще без программы?

— А как это?, — спросил меня знакомый, — С помощью Ардуино?

— Внутри Ардуино стоит вполне фон-неймановский процессор и работает программа, — ответил я, — Нет, еще более голое железо.

— А-а-а-а, этот, микрокод?, — догадался мой товарищ и взглянул на меня победно.

— Нет, термин «микрокод» использовался для специфической организации процессоров в 1970-е годы, потом его использование сошло на нет, — ответил я и добавил, — Правда есть еще микрооперации в интеловских процессорах, в которые перекодируется x86, но это тоже другое. Нет, я имею в виду парсинг текста устройством, состоящим из логических элементов И-ИЛИ-НЕ и Д-триггерами, как на картинке ниже.

— Невозможно! — воскликнул мой приятель, — в таком устройстве где-то сбоку должен сидеть процессор и хитро подмигивать!

— Почему это невозможно?, — парировал я, — Вот машину Тьюринга знаешь? Парсирует текст на ленте, а сбоку никакие интелы и ардуино не подмигивают.

— Нуу, машина Тьюринга, — протянул приятель, — это абстракция, типа Демона Максвелла.

— Никакой абстракции, сейчас увидишь работающую схему, парсирующую текст, — сказал я и прибавил, — но сначала расскажу, зачем мне вообще это понадобилось.

mfp_srec_parser_fragment
Читать полностью »

От переводчика: прочитав статью, начал было отвечать в комментариях, но решил, что текст, на которую я собирался ссылаться, достоин отдельной публикации. Встречайте!

Если вы знаете, как валидировать email-адрес, поднимите руку. Те из вас, кто поднял руку — опустите её немедленно, пока вас кто-нибудь не увидел: это достаточно глупо — сидеть в одиночестве за клавиатурой с поднятой рукой; я говорил в переносном смысле.

До вчерашнего дня я бы тоже поднял руку (в переносном смысле). Мне нужно было проверить валидность email-адреса на сервере. Я это уже делал несколько сот тысяч раз (не шучу — я считал) при помощи классного регулярного выражения из моей личной библиотеки.

В этот раз меня почему-то потянуло ещё раз осмыслить мои предположения. Я никогда не читал (и даже не пролистывал) RFC по email-адресам. Я попросту основывал мою реализацию на основе того, что я подразумевал под корректным email-адресом. Ну, вы в курсе, что обычно говорят о том, кто подразумевает. [прим. перев. Игра слов: «when you assume, you make an ass of you and me» — «когда вы подразумеваете, вы делаете /./удака из себя и из меня»]

И обнаружил кое-что занимательное: почти все регулярные выражения, представлены в интернете как «проверяющие корректность email-адреса», излишне строги.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js