fixes & suggestions

Author: mykhaliuk

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

@@ -1,4 +1,4 @@
-# Проблема поиска с бесконечным бэктрекингом
+# Проблема поиска с бесконечным возвратом
 
 Некоторые регулярные выражения, с виду являясь простыми, могут выполняться оооочень долго, и даже "подвешивать" интерпретатор JavaScript.
 
@@ -8,7 +8,7 @@
 
 В веб-браузере такой случай убивает страницу. Явно плохая ситуация.
 
-Такой код, выполняемый на стороне сервера, может стать уязвимостью, так как он использует регулярные выражения для обработки пользовательских данных. Некорректный ввод данных приведет к зависанию процесса и, как следствие, отказу сервиса. Автор лично видел и сообщал о таких уязвимостях даже для очень известных и широко используемых программ.
+Ну а для серверного JavaScript это может стать серьёзной уязвимостью, так как регулярные выражения используются для обработки пользовательских данных. Некорректный ввод данных приведет к зависанию процесса и, как следствие, отказу сервиса. Автор лично видел и сообщал о таких уязвимостях даже для очень известных и широко используемых программ.
 
 Так что проблема, несомненно, достойна рассмотрения.
 
@@ -22,11 +22,11 @@
 
 Например, давайте рассмотрим поиск тегов в 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:<[^>]+>` не работает, потому что оно останавливает поиск на первом `>`, а нам нужно игнорировать `<>`, если они являются частью атрибута.
+Простое регулярное выражение `pattern:<[^>]+>` не работает, потому что оно останавливает поиск на первом `>`, а нам нужно игнорировать `<>`, если они являются частью атрибута.
 
 ```js run
 // поиск не достигает конца тега - неверно!
@@ -41,7 +41,7 @@ alert( '<a test="<>" href="#">'.match(/<[^>]+>/) ); // <a test="<>
 
 Если мы подставим это в паттерн, описанный выше, и добавим дополнительные пробелы `pattern:\s`, то получим следующее: `pattern:<\w+(\s*\w+="[^"]*"\s*)*>`.
 
-Это регулярное выражение неидеально! Оно всё ещё не поддерживает все детали HTML, например, значения в кавычках, и, хотя и есть способы улучшить его, давайте не будем его усложнять. Оно продемонстрирует нам проблему.
+Это регулярное выражение неидеально! Оно не поддерживает все детали синтаксиса HTML, например, значения без кавычек, есть способы улучшить его, но давайте не будем его усложнять. Оно продемонстрирует нам проблему.
 
 Кажется, регулярное выражение работает:
 
@@ -55,9 +55,9 @@ alert( str.match(reg) ); // <a test="<>" href="#">, <b>
 
 Отлично! Нашло длинный `match:<a test="<>" href="#">` и короткий `match:<b>` теги.
 
-Теперь у нас есть рабочее на вид решение. А теперь – демонстрация проблемы.
+Теперь когда у нас есть рабочее на вид решение, взглянем на проблему.
 
-## Чёрная дыра бэктрекинга
+## Бесконечный возврат
 
 Если запустить пример ниже, то он может подвесить браузер (или другую среду, где выполняется JavaScript):
 
@@ -122,15 +122,15 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+)*$/) );
     ```
 2. Затем движок пытается применить квантификатор `pattern:*`, но больше цифр нет, так что звёздочка ничего не даёт.
 
-3. Затем в шаблоне идёт символ конца строки `pattern:$`, а в тексте символ `subject:z`, так что соответствий нет:
+3. Далее по шаблону ожидается конец строки `pattern:$`, а в тексте символ `subject:z`, так что соответствий нет:
 
     ```
                X
     \d+........$
     (123456789)z
     ```
 
-4. Так как соответствие не найдено, то "жадный" квантификатор `pattern:+` отступает на один символ (бэктрекинг).
+4. Так как соответствие не найдено, то "жадный" квантификатор `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
@@ -193,12 +193,12 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+)*$/) );
 
 Что же делать?
 
-Может нам стоит использовать ленивый режим?
+Может нам стоит использовать "ленивый" режим?
 
 К сожалению, нет: если мы заменим `pattern:\d+` на `pattern:\d+?`, то регулярное выражение всё ещё будет "зависать" (осторожно! Может "подвесить" браузер):
 
 ```js run
-//  мееедленно ~доооолго~
+//  доооолго
 alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 ```
 
@@ -212,7 +212,7 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 
 В примере выше, когда в строке `subject:<a=b  a=b  a=b  a=b` мы ищем теги по паттерну `pattern:<(\s*\w+=\w+\s*)*>`, происходит то же самое.
 
-В конце строки нет `>`, поэтому совпадение невозможно, но движок не в курсе этого и, отступая, пробует другие комбинации `pattern:(\s*\w+=\w+\s*)`:
+В конце строки нет `>`, поэтому совпадение невозможно, но движок не в курсе этого и, отступая, пробует другие комбинации `pattern:(\s*\w+=\w+\s*)`. Таких комбинаций много, поэтому это и занимает много времени.:
 ```
 (a=b a=b a=b) (a=b)
 (a=b a=b) (a=b a=b)
@@ -240,30 +240,30 @@ alert( '12345678901234567890123456789123456789z'.match(/(\d+?)*$/) );
 
 Никаких "откатов" здесь не нужно.
 
-Другими словами, если мы нашли три пары `name=value`, а `>` после них найти не можем, то не нужно понижать число повторений. Последнего (`>`) точно нет после предыдущих двух пар `name=value` (мы "откатились" на одну пару `name=value`):
+Другими словами, если мы нашли три пары `name=value`, а `>` после них найти не можем, то не нужно понижать число повторений. Последнего (`>`) точно нет после предыдущих двух пар `name=value` (мы "откатились" на одну пару `name=value`, там находится эта пара):
 
 ```
 (name=value) name=value
 ```
 
-В современных регулярных выражениях для решения этой проблемы придумали сверхжадные ("possessive") квантификаторы, которые вообще не используют бэктрегинг. То есть, они даже проще, чем "жадные" – берут максимальное количество символов и всё. Поиск продолжается дальше. Также есть "атомарные скобочные группы" -- средство, запрещающее перебор внутри скобок.
+В современных регулярных выражениях для решения этой проблемы придумали сверхжадные ("possessive") квантификаторы, которые вообще не используют возврат. То есть, они даже проще, чем "жадные" – берут максимальное количество символов и всё. Поиск продолжается дальше. Также есть "атомарные скобочные группы" -- средство, запрещающее перебор внутри скобок.
 
 К сожалению, в JavaScript они все не поддерживаются.
 
 ### Предпросмотр в помощь!
 
 Но мы можем исключить бэктрекинг с помощью предпросмотра.
 
-Паттерн, совершающий максимальное количество повторений без "отката", выглядит так: `pattern:(?=(a+))\1`.
+Паттерн, совершающий максимальное количество повторений без возврата, выглядит так: `pattern:(?=(a+))\1`.
 
 Другими словами:
 - Предпросмотр `pattern:?=` ищет максимальное количество `pattern:a+`, доступных с текущей позиции.
 - А затем они "берутся в результат" обратной ссылкой `pattern:\1` (`pattern:\1` соответствует содержимому вторых скобок, т.е. `pattern:a+`)
 
-Откат в этой логике в принципе не предусмотрен, поскольку предпросмотр "откатываться" не умеет. То есть, если предпросмотр нашёл 5 `pattern:a+`, и в результате поиск не удался, то он не будет откатываться на 4 повторения.
+Возврат в этой логике в принципе не предусмотрен, поскольку предпросмотр "откатываться" не умеет. То есть, если предпросмотр нашёл 5 `pattern:a+`, и в результате поиск не удался, то он не будет откатываться на 4 повторения.
 
 ```smart
-Больше о взаимодействиях сверхжадных квантификаторов и предпросмотра вы можете найти в статьях [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).
 ```
 
 Такой метод нивелирует проблему.