Почему preg_match_all появляется после стольких символов?

Question

У меня проблема с моим утверждением preg_match_all. Он работал отлично, так как я печатал статью, но внезапно после того, как она прошла, определенная длина перестала работать все вместе. Это известная проблема с функцией, которая просто не выполняет ничего после стольких символов?

$number = preg_match_all("/(<!-- ([\w]+):start -->)\n?(.*?)\n?(<!-- \\2:stop -->)/s", $data, $matches, PREG_SET_ORDER);

Все это время он работал нормально и отлично работает на других страницах, но как только эта статья прошла определенную длину, фу, она перестала работать для этой статьи. Есть ли другое решение, которое я могу использовать, чтобы заставить его работать с более длинными блоками текста? Длина обрабатываемой статьи - около 33 000 символов (включая пробелы).

Я задавал такой вопрос раньше, но получил только один ответ, который я никогда не проверял. В прошлый раз я только что нашел другой способ обойти это для этого конкретного сценария, но на этот раз нет способа обойти это, потому что это всего одна статья. Я попытался изменить pcre.backtrack_limit и pcre.recursion_limit до даже 500 000 без какого-либо эффекта. Есть ли другие идеи о том, почему это происходит, и что я могу сделать, чтобы заставить его продолжать работать даже для этих массивных блоков текста? Предел в 30000 символов, кажется, немного низок, это всего лишь 5000-6000 слов (это около 5700 слов). Разбить его на части не очень удобно, потому что он не найдет начало и конец, если они находятся в двух отдельных блоках текста.

Answer 1

Я столкнулся с этим один раз, и единственный способ, которым я мог решить это тогда, был разделением строки. Вы могли бы explode() или preg_split().

Цитируя буквально из моего исходного кода:

    // regexps have failed miserably on very large tables...
    $parts = explode("<table",$html);

Но это было два года назад.

Answer 2

Похоже, вы работаете с HTML.Вы можете рассмотреть возможность работы с одним из различных парсеров.Например, DOM имеет специальный класс для комментариев , поэтому мы знаем, что он может работать с ними.К сожалению, с DOM работать немного неудобно.

Другой вариант может заключаться в использовании XMLReader , который читает XML как поток и обрабатывает его как токены.Кажется, чтобы понять, что комментарии.Я никогда не использовал это сам, поэтому я не могу сказать вам, насколько хорошо это работает.(Вы можете использовать методы DOM loadHTML и saveXML для преобразования вашего HTML в XML, предполагая, что он не слишком ужасно сформирован.)

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