Чтобы сказать из заключения, я думаю, что внешний вид JavaScript не реализован, поскольку никто не знает, как он должен себя вести, а существующие реализации показывают, что добавление поддержки look-behind довольно сложно.

JavaScript / ECMAScript отличается от других языков тем, что спецификация включает абстрактную реализацию механизма regex, в то время как большинство других языков останавливается только при описании поведения каждой части синтаксиса регулярного выражения, с небольшим описанием того, как разные токены взаимодействуют друг с другом.

Взгляд? Легко реализовать

. Реализация взгляда вперед довольно проста. Вам нужно только обработать шаблон внутри внешнего вида таким же образом, как и внешний внешний вид, и выполнить совпадение слева направо в соответствии с обычным, за исключением того, что после успешного выполнения поиска 1) текущая позиция восстанавливается до входа в режим ожидания, и 2) точки выбора внутри look-ahead отбрасываются после того, как они сопоставлены.

Нет ограничений на то, что можно включить в look-ahead, поскольку это очень простое дополнение к существующим естественным средствам сравнения слева направо.

Look-behind? Не так просто

С другой стороны, реализация look-behind не так прямолинейна.

Представьте себе, как реализовать следующую конструкцию look-behind:

(?<=fixed-string)
(?<=a|fixed|string)
(?<=t[abc]{1,3})
(?<=(abc){2,6})
(?<=^.*abc.*)
(?<=\G"[^"]+");
(?<=^(.....|.......)+)
\b(\w+)\b(?<!\b\1\b.*\1)

Помимо основного случая (?<=fixed-string), который должна поддерживаться любой реалистичной реализацией, (?<=a|fixed|string) - очень желательный случай для поддержки.

У разных двигателей регулярных выражений различный уровень поддержки для регулярного выражения выше.

Давайте посмотрим, как они реализованы в .NET и Java. (Это два разновидности, чье поведение позади, которое я изучил.)

.NET-реализация

В реализации Microsoft .NET все эти регулярные выражения действительны, поскольку .NET реализует look-behind, используя режим справа налево, со стартовым смещением в текущей позиции. Конструкция look-behind сама по себе не генерирует никакой точки выбора.

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

Реализация Java

Напротив, Java regex реализация реализует look-back путем повторного использования возможностей совпадения слева направо.

Сначала анализирует шаблон внутри внешнего вида для минимальной и максимальной длины шаблона. Затем, look-behind реализуется, пытаясь сопоставить шаблон внутри слева направо, начиная с (current position - minimum length) до (current position - maximum length).

Не хватает ли чего-нибудь? Да! Поскольку мы сопоставляем слева направо, мы должны убедиться, что совпадение заканчивается прямо в позиции перед входом в look-behind (current position). В Java это реализуется путем добавления узла в конец шаблона внутри look-behind.

Эта реализация очень неэффективна, так как есть maximum - minimum + 1 точки выбора, созданные в самом внешнем виде, прежде чем мы даже поговорим о точках выбора, созданных шаблоном внутри look-behind.

Проверка привязки внешнего вида также неэффективна, поскольку она помещается в конец шаблона и не может обрезать

Резюме

Как вы можете видеть, добавление поддержки look-behind не является easy:

• Подход справа налево представляется достаточно эффективным. Тем не менее, он требует дополнительной спецификации для сопоставления справа налево в других существующих конструкциях.
• Подход к повторному использованию объектов соответствия слева направо сложно определить и очень неэффективен. Это также требует введения анализа шаблонов в спецификацию, чтобы производительность не выходила из окна.

(Обратите внимание, что я еще не рассмотрел поведение, когда внешний вид используется внутри

Эти технические препятствия также упоминаются Вальдемар Хорват (который написал спецификацию ES3 regex) в почта указана в ответе nils :

Никто еще не представил четко сформулированное предложение для lookbehinds в таблице. Lookbehinds трудно перевести на язык, используемый спецификацией, и получить довольно нечеткие, когда порядок оценки частей регулярного выражения имеет значение, что и происходит, если речь идет о захвате круглых скобок. Где вы начинаете искать lookbehind? Самый короткий первый, самый длинный первый или обратная строка? Жадный или нет? Возвращение в результаты?