fixes

Author: mykhaliuk

9-regular-expressions/15-regexp-infinite-backtracking-problem/article.md

@@ -1,30 +1,30 @@
-# Проблема поиска с вечным бэктрекингом
+# Проблема поиска с бесконечным бэктрекингом
 
 Некоторые регулярные выражения, с виду являясь простыми, могут выполняться оооочень долго, и даже "подвешивать" интерпретатор JavaScript.
 
-Рано или поздно, с этим сталкивается любой разработчик, потому что нечаянно создать такое регулярное выражение –- проще простого.
+Рано или поздно с этим сталкивается любой разработчик, потому что нечаянно создать такое регулярное выражение –- проще простого.
 
 Типичная ситуация: регулярное выражение работает нормально, но иногда, с некоторыми строками, "подвешивает" интерпретатор и потребляет 100% процессора.
 
 В веб-браузере такой случай убивает страницу. Явно плохая ситуация.
 
-Такой код, выполняемый на стороне сервера, может стать уязвимостью, так как он использует регулярные выражения для обработки пользовательских данных. Некорректный ввод данных приведет к зависанию процесса и, как следствие, отказу сервиса. Автор(?) лично видел и сообщал о таких уязвимостях даже для очень известных и широко используемых программ.
+Такой код, выполняемый на стороне сервера, может стать уязвимостью, так как он использует регулярные выражения для обработки пользовательских данных. Некорректный ввод данных приведет к зависанию процесса и, как следствие, отказу сервиса. Автор лично видел и сообщал о таких уязвимостях даже для очень известных и широко используемых программ.
 
 Так что проблема, несомненно, достойна рассмотрения.
 
 ## Вступление
 
 План изложения у нас будет таким:
 
-1. Сначала посмотрим на проблему в реальной ситуации.
-2. Потом упростим реальную ситуацию до "корней" и увидим, откуда она берётся.
-3. Ну и, на конец, исправим её.
+1. Сначала взглянем на проблему, на то, как это могло произойти.
+2. Потом упростим ситуацию и увидим, почему проблема возникает.
+3. Ну и, наконец, исправим её.
 
 Например, давайте рассмотрим поиск тегов в HTML.
 
-Мы хотим найти все теги с атрибутами (или без них), типа: `subject:<a href="..." class="doc" ...>`. Нужно чтобы регулярное выражение работало надёжно, так как HTML приходит из Интернета и может быть запутанным.
+Мы хотим найти все теги с атрибутами (или без них) типа: `subject:<a href="..." class="doc" ...>`. Нужно, чтобы регулярное выражение работало надёжно, так как HTML приходит из Интернета и может быть "грязным".
 
-В частности, нам нужно, чтобы оно соответствовало тегам типа: `<a test="<>" href="#">` -- т.е. с символами `<` и `>` внутри атрибутов, так как это поддерживается [стандартом HTML](https://html.spec.whatwg.org/multipage/syntax.html#syntax-attributes).
+В частности, чтобы регулярное выражение находило теги типа: `<a test="<>" href="#">` -- т.е. с символами `<` и `>` внутри атрибутов, так как это поддерживается [стандартом HTML](https://html.spec.whatwg.org/multipage/syntax.html#syntax-attributes).
 
 Как видим, простое регулярное выражение `pattern:<[^>]+>` не работает, потому что оно останавливает поиск на первом `>`, а нам нужно игнорировать `<>`, если они являются частью атрибута.
 
@@ -35,11 +35,11 @@ alert( '<a test="<>" href="#">'.match(/<[^>]+>/) ); // <a test="<>
 
 Для того, чтобы правильно обрабатывать подобные ситуации, нужно более сложное регулярное выражение. Оно будет иметь вид: `pattern:<tag (key=value)*>`.
 
-1. Для `tag`: `pattern:\w+`,
-2. Для `key`: `pattern:\w+`,
-3. И для `value`: строка в кавычках `pattern:"[^"]*"`.
+1. Для имени тега `tag`: `pattern:\w+`,
+2. Для имени атрибута `key`: `pattern:\w+`,
+3. И значения атрибута `value`: строка в кавычках `pattern:"[^"]*"`.
 
-Если мы подставим это в паттерн описанный выше и добавим дополнительные пробелы `pattern:\s`, то получим следующее: `pattern:<\w+(\s*\w+="[^"]*"\s*)*>`.
+Если мы подставим это в паттерн, описанный выше, и добавим дополнительные пробелы `pattern:\s`, то получим следующее: `pattern:<\w+(\s*\w+="[^"]*"\s*)*>`.
 
 Это регулярное выражение неидеально! Оно всё ещё не поддерживает все детали HTML, например, значения в кавычках, и, хотя и есть способы улучшить его, давайте не будем его усложнять. Оно продемонстрирует нам проблему.
 
@@ -55,11 +55,11 @@ alert( str.match(reg) ); // <a test="<>" href="#">, <b>
 
 Отлично! Нашло длинный `match:<a test="<>" href="#">` и короткий `match:<b>` теги.
 
-Теперь у нас есть на вид рабочее решение. А теперь – демонстрация проблемы.
+Теперь у нас есть рабочее на вид решение. А теперь – демонстрация проблемы.
 
 ## Чёрная дыра бэктрекинга
 
-Если запустить пример ниже, то он может подвесить браузер (или другой JavaScript хост):
+Если запустить пример ниже, то он может подвесить браузер (или другую среду, где выполняется JavaScript):
 
 ```js run
 let reg = /<\w+(\s*\w+="[^"]*"\s*)*>/g;
@@ -79,10 +79,10 @@ alert( str.match(reg) );
 
 Давайте упростим регулярное выражение, удалив имя тега и кавычки. Теперь мы ищем только атрибуты -- пары `key=value`: `pattern:<(\s*\w+=\w+\s*)*>`.
 
-К сожалению, регулярное выражение все еще "зависает":
+К сожалению, регулярное выражение всё ещё "зависает":
 
 ```js run
-// поиск только по атрибутам, разделенных пробелом
+// поиск только по атрибутам, разделённым пробелом
 let reg = /<(\s*\w+=\w+\s*)*>/g;
 
 let str = `<a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b
@@ -94,11 +94,11 @@ alert( str.match(reg) );
 */!*
 ```
 
-На этом мы закончим с демонстрацией "практического примера" и перейдём к разбору происходящего и способам устранения проблемы.
+На этом мы закончим с демонстрацией практического примера и перейдём к разбору происходящего и способам устранения проблемы.
 
 ## Подробный пример
 
-Чтобы сделать пример еще проще, давайте рассмотрим `pattern:(\d+)*$`.
+Чтобы сделать пример ещё проще, давайте рассмотрим `pattern:(\d+)*$`.
 
 Это регулярное выражение имеет ту же проблему. В большинстве движков регулярных выражений этот поиск занимает очень много времени (осторожно - может "зависнуть"):
 
@@ -165,7 +165,7 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+)*$/) );
 
     ...увы, всё ещё нет соответствия для `pattern:$`.
 
-    Поисковой движок снова должен отступить назад. В общем бэктрекинг работает так: последний жадный квантификатор понижает количество повторений до тех пор, пока это возможно. Затем понижает предыдущий "жадный" квантификатор и т.д. В нашем случае последний "жадный" квантификатор -- это второй `pattern:\d+`, сокращающий `subject:89` до `subject:8`, а звёздочка берёт `subject:9`:
+    Поисковый движок снова должен отступить назад. В общем, бэктрекинг работает так: последний жадный квантификатор понижает количество повторений до тех пор, пока это возможно. Затем понижает предыдущий "жадный" квантификатор и т.д. В нашем случае последний "жадный" квантификатор -- это второй `pattern:\d+`, сокращающий `subject:89` до `subject:8`, а звёздочка берёт `subject:9`:
 
     ```
                    X
@@ -204,7 +204,7 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 
 **"Ленивые" регулярные выражения делают то же самое, но в обратном порядке.**
 
-Просто подумайте о том, как будет в этом случае работать поисковой движок.
+Просто подумайте о том, как будет в этом случае работать поисковый движок.
 
 Некоторые движки регулярных выражений содержат хитрые проверки и конечные автоматы, которые позволяют избежать бесконечного перебора или кардинально ускорить его, но не все движки и не всегда.
 
@@ -246,15 +246,15 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 (name=value) name=value
 ```
 
-В современных регулярных выражениях для решения этой проблемы придумали "possessive" (сверхжадные? неоткатные? точный перевод пока не устоялся) квантификаторы, которые вообще не используют бэктрегинг. То есть, они даже проще, чем "жадные" – берут максимальное количество символов и всё. Поиск продолжается дальше. Также есть "атомарные скобочные группы" -- средство, запрещающее перебор внутри скобок.
+В современных регулярных выражениях для решения этой проблемы придумали сверхжадные ("possessive") квантификаторы, которые вообще не используют бэктрегинг. То есть, они даже проще, чем "жадные" – берут максимальное количество символов и всё. Поиск продолжается дальше. Также есть "атомарные скобочные группы" -- средство, запрещающее перебор внутри скобок.
 
 К сожалению, в JavaScript они все не поддерживаются.
 
 ### Предпросмотр в помощь!
 
 Но мы можем исключить бэктрекинг с помощью предпросмотра.
 
-Паттерн, совершающий максимальное количество повторений без "отката" выглядит так: `pattern:(?=(a+))\1`.
+Паттерн, совершающий максимальное количество повторений без "отката", выглядит так: `pattern:(?=(a+))\1`.
 
 Другими словами:
 - Предпросмотр `pattern:?=` ищет максимальное количество `pattern:a+`, доступных с текущей позиции.
@@ -263,7 +263,7 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 Откат в этой логике в принципе не предусмотрен, поскольку предпросмотр "откатываться" не умеет. То есть, если предпросмотр нашёл 5 `pattern:a+`, и в результате поиск не удался, то он не будет откатываться на 4 повторения.
 
 ```smart
-Больше о взаимодействиях кватификаторов "possessive" и предпросмотра вы можете найти в статьях [Regex: Emulate Atomic Grouping (and Possessive Quantifiers) with LookAhead](http://instanceof.me/post/52245507631/regex-emulate-atomic-grouping-with-lookahead) и [Mimicking Atomic Groups](http://blog.stevenlevithan.com/archives/mimic-atomic-groups).
+Больше о взаимодействиях сверхжадных кватификаторов и предпросмотра вы можете найти в статьях [Regex: Emulate Atomic Grouping (and Possessive Quantifiers) with LookAhead](http://instanceof.me/post/52245507631/regex-emulate-atomic-grouping-with-lookahead) и [Mimicking Atomic Groups](http://blog.stevenlevithan.com/archives/mimic-atomic-groups).
 ```
 
 Такой метод нивелирует проблему.
@@ -274,7 +274,7 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 // регулярное выражение для поиска 'name=value'
 let attrReg = /(\s*\w+=(\w+|"[^"]*")\s*)/
 
-// используем new RegExp() чтобы красиво вставить его source в (?=(a+))\1
+// используем new RegExp() чтобы красиво вставить его исходную строку (source) в (?=(a+))\1
 let fixedReg = new RegExp(`<\\w+(?=(${attrReg.source}*))\\1>`, 'g');
 
 let goodInput = '...<a test="<>" href="#">... <b>...';
@@ -283,9 +283,9 @@ let badInput = `<tag a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b
   a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b  a=b`;
 
 alert( goodInput.match(fixedReg) ); // <a test="<>" href="#">, <b>
-alert( badInput.match(fixedReg) ); // null (нет резульатов, быстро!)
+alert( badInput.match(fixedReg) ); // null (нет резульатов, отработало быстро!)
 ```
 
 Отлично, всё работает! Нашло как длинный тег  `match:<a test="<>" href="#">`, так и одинокий `match:<b>`, и (!) не "вешает" интерпретатор при некорректных данных.
 
-Обратите внимание на свойство `attrReg.source`. Объект `RegExp` предоставляет доступ к своей (?)исходной(?) строке. Это удобно, когда мы хотим вставить одно регулярное выражение в другое.
+Обратите внимание на свойство `attrReg.source`. Объект `RegExp` предоставляет доступ к своей исходной (`source`) строке. Это удобно, когда мы хотим вставить одно регулярное выражение в другое.