Каковы были бы последствия вставки положительного lookbehind для n-байтов, (?<=\C{n}), в начало любого произвольного регулярного выражения, особенно при использовании для операций замены?
По крайней мере, внутри PHP функции соответствия регулярному выражению preg_match и preg_match_all позволяют начинать сопоставление после заданного смещения байта. В любой из других функций PCRE PHP нет соответствующей функции - вы можете указать ограничение на количество замен, выполняемых preg_replace, например, но не на то, что совпадения замен должны появляться после n-байтов.
Очевидно, что некоторые из них (давайте назовем их тривиальными) последствиями для производительности и удобочитаемости, но будут ли какие-либо (нетривиальные) воздействия, например, совпадения становятся несоответствиями (за исключением случаев, когда они не смещены на n байтов) или заменители становятся неверными?
Некоторые примеры:
/some expression/ становится /(?<=\C{4})some expression/ для 4-байтового смещения
/(this) has (groups)/i становится /(?<=\C{2})(this) has (groups)/i для 2-байтового смещения
Насколько я могу судить, и из ограниченных тестов, которые я выполнил, добавление в этот lookbehind эффективно имитирует этот параметр смещения и не путается с любыми другими lookbehinds, заменами или другими шаблонами управления; но я также не специалист по Regex.
Я пытаюсь определить, есть ли какие-либо возможные последствия для создания функций замены/фильтрации, вставив n-байт lookbehind в шаблоны. Он должен работать так же, как работает параметр смещения функции смещения. Таким образом, простое выполнение выражения против substr( $subject, $offset ) не будет работать по тем же причинам, что и для preg_match (в первую очередь это отсекает любые lookbehinds и ^ затем неправильно совпадает с началом подстроки, а не с исходной строкой).