Помогите составить регулярное выражение для замены первого вхождения слова в HTML, но строго вне анкоров и атрибутов?

Question

[Алексей]

Друзья, регуляркой требуется найти и заменить в тексте, размеченном в HTML:

1. Первое вхождение заданного слова
2. Которое при этом не обёрнуто внутрь тега <a>…</a> (т.е. не попадает в анкор какой-либо ссылки)
3. Которое при этом не является частью какого-либо атрибута (типа alt у тега img)

Ниже представляю текст для примера и тестов. Замена должна случиться лишь во фрагменте «… каждый огурец, только что...» (первое предложение последнего абзаца). Все остальные вхождения слова «огурец» нарушают какое-либо из перечисленных условий.

<p>Самые вкусные огурцы росли у меня на даче прошлым летом, это был отличный сезон. Когда я их срывал, то уплетал вот так: <br /> <img src="cucumber-eater.png" alt="Я ем огурец"></p>
<p>Кстати, вы знали, что <a href="http://example.com/super-facts/blue-cucumber" title="По ссылке рассказ про то, как вырастить синий огурец">обычный огурец может быть синим</a>? Я вот — не знал, думал, что они все только зелёные.</p>
<p>Лично мне аппетитным кажется каждый огурец, только что сорванный с грядки. Хотя свежий на вид огурец и зимой можно купить в любом супермаркете, я предпочитаю кушать только то, что выращено своими руками под бдительным контролем.</p>

Проблема решаема за счёт работы с DOM (обходятся отдельно иннертексты всех узлов с помощью simplehtmldom.sourceforge.net или иного парсера и замены просто не делаются для иннертекстов элементов <a>). Но намного удобнее было бы иметь решение в виде работающего регулярного выражения (производительность не принципиальна). Его осилить — не могу, ибо с регулярками слабо знаком.

Заранее спасибо за ваше внимание к такому нетривиальному случаю.

P.S. В комментариях — много интересного. Война регулярок и контрпримеров. Спасибо хабралюдям Jaguar_ko, yui_room9, dsd_corp за разыгравшуюся зарубу :-)

Answer 1

[Jaguar_ko]

/(search)(?!.*(?:)|(".*>))/
Это чисто теоретически:)
Проверить в час ночи на телефоне нет возможности)
П.С: search — искомое слово :)

Comments

[Jaguar_ko]

/(search)(?!.*(?:<\/a>)|(".*>))/
Извиняюсь :)

[Алексей]

Не, к сожалению не матчит: regexr.com?3143c (хотя с телефона этот годный он-лайн сервис тоже, наверное, не откроется).

[Алексей]

О, а второй вариант с конкретным уже тегом работает :-) regexr.com?3143f Ничего себе! Вот спасибо. Пойду тестировать усиленно.

[Jaguar_ko]

Удачи :) Всегда рад помочь) Если будет работать некорректно, то завтра допилю (если не сможете сами)

[Quiz]

Теперь я знаю на каком языке с нами будет общаться НЛО и кого слать дипломатом в первую очередь.

[Jaguar_ko]

Ага:) Они меня этому и научили:)

[Алексей]

Александр, а, пользуясь случаем, нельзя ли вас попросить прокомментировать регулярку «поэлементно»? Наверное, будет полезно, если это сделает автор выражения, прежде всего для тех, кто сюда заглянет в поисках какого-то похожего, но всё же не идентичного решения. И, к тому же, ниже заявлялось, что задачу вообще не решить регулярным выражением. А тут вдруг появилось бы подробное опровержение с комментариями :-)

[dsd_corp]

Вам правильно заявляли. Такие задачи простыми регулярками не решаются.
Поробуйте вставить слово «огурец» в тексте во все возможные валидные места.
При данной товарищем Jaguar_ko регулярке она не сработает на слово «огурец» фактически до знака вопроса в вашем текстовом примере(да закрывающего тега A все выпадает автоматически).
То есть фактически данная регулярка притянута к конкретному текстовому примеру, а не к вашему набору условий.
Даже если ее попытаться допилить, с высокой вероятностью все-равно найдутся валидные ситуации, на которых она не сработает, либо невалидные, на которых сработает.

[Jaguar_ko]

Как я писал выше «регулярка написана на коленке».
Если есть возможность, покажите пожалуйста невалидный вариант?
Поэлементно:

[smartup]

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

[Алексей]

По ходу действительно беда, вот пример: regexr.com?314en Самое первое вхождение в первом предложении тут под условия подходит, но регулярка его пропускает.

И пример, про который говорил smartup (где единственное корректное вхождение заперто между ссылками и поэтому совсем не находится): regexr.com?314et

[Jaguar_ko]

(огурец) — искомое слово. Заключено в скобки для уточнения, что это единый элемент.
(огурец)(?! элемент) — находит все варианты, где после огурца не стоит «элемент»
Далее нам нужно узнать, не текст ли это ссылки — .*<\/a>
И не атрибут ли это — .*".*>
Записываем каждое условие, как единый элемент (оборачивая в скобки) и добавляем между ними «или» (|)
Получаем — .*(<\/a>)|(".*>)
Вставляем это в конструкцию (?! )
Получаем готовый вариант: (огурец)(?!.*(<\/a>)|(".*>))
Profit!

[dsd_corp]

smartup, у меня есть решение конкретно этой задачи(ради интереса собрал). Но не одной регуляркой(хотя они там частично юзаются). Кода довольно много, используется модуль парсера, но работает гибко, достаточно быстро и не грохается при косяках, в отличии от сишных XML парсеров, встроенных в PHP.
Если автор попросит(если ему подойдет решение не на одной «волшебной» регулярке), то конечно вывалю, не вопрос.

[Алексей]

dsd_corp выкладывайте конечно же. Как минимум, пригодится всем, кто сюда забредет по поиску. Как я в самом вопросе писал, у меня «не через регулярку» тоже есть скрипучее решение через simplehtmldom.sourceforge.net, но вот оно как раз неустойчиво к невалидному HTML (хотя устойчивости от регулярки я тоже не ожидал, например, я понимаю, что внутрь атрибутов могут писать и нечто похожее на теги). Так что ваше стабильное — безусловно интересно.

[dsd_corp]

smartup, kostin: выложил ниже в отдельном ответе.

[yui_room9]

И Ап :)

(search)(?:(?!.*(?:<\/a>)|(?:".*>))|(?=[^>]*(?:<a\s)))

1) http://regexr.com?314gp
2) http://regexr.com?314gs

[Алексей]

yui_room9, увы, есть проблемка: regexr.com?314h2 (тут вхождение в самом первом предложении должно выделяться, а выделяется другое). Но всё равно круто! Спасибо. Прямо битва какая-то вокруг этой регулярки разворачивается.

[yui_room9]

Ап x2 :)

(огурец)(?:(?![^>]*(?:<\/a>)|(?:".*>))|(?=[^>]*(?:<a\s)))

1) http://regexr.com?314h8
2) http://regexr.com?314hb
3) http://regexr.com?314he

[Алексей]

yui_room9, вы маньяк в хорошем смысле этого слова :-) Завтра на свежую голову постараюсь потестить с пристрастием, пока не нашёл контрпримера.

[yui_room9]

Всегда пожалуйста :-D
Будет контр, будем двигаться дальше :)

[dsd_corp]

Вы так будете двигаться дальше бесонечно )))
Вот ваш контрпример:

<p>Самый <a><i>вкусный</i> огурец <b>корявый</b></a> рос ...

[Jaguar_ko]

Начало было положено:) Если до конца моей командировки не будет найдено верное решение, присоединюсь к битве :)

[Jaguar_ko]

А что если попробовать так:
(?:(?!.*(?!<\/a>)))(огурец)(?:(?!(.*<\/a>)|(.*".*>)
И доработать?:) Насчет первого условия не уверен.
Тут главное идея:)

[Алексей]

Пошла суровая мясорубка :-) Вот и от меня контрпример на свежую голову: regexr.com?314jp (самое первое вхождение в кавычках, но при этом не является атрибутом).

[Jaguar_ko]

(?:(?!.*.*(?!<\/a>)))(огурец)(?:(?!(.*<\/a>)|(.*".*>)

[Jaguar_ko]

Хабр съедает «» (вначале между двумя .*)

[Jaguar_ko]

<a< (последний знак «<» перевернуть :)

[Алексей]

Jaguar_ko тоже не проходит тест, когда слово в кавычках, но не атрибут (т.е. эти кавычки не внутри тега).

[Jaguar_ko]

(?:(?!<a.•>.*(?!<\/a>)))(огурец)(?:(?!(.*<\/a>)|(.*".*>)

[Jaguar_ko]

(?:(?!<a.*>.*(?!<\/a>)))(огурец)(?:(?!(.*<\/a>)|(.*".*>)
Всё:)

[Алексей]

Это что там за спецсимвол «•» после «a.»? :-)

[yui_room9]

Эх, я пропустить пати :(((

Жду конра на последний эксп от Jaguar_ko :-D
Let's the party begin

[Алексей]

Вечеринка продолжается, не расходимся :-) Контр: regexr.com?314kn (не матчится корректное вхождение в самом первом предложении)

[yui_room9]

И Ап :)
Что то у меня эксп от Jaguar_ko не воркает как надо,
Поэтому мой улучшенный с кавычками :)

"?(огурец)"?(?:(?![^>]*(?:<\/a>)|(?:".*>))|(?=[^>]*(?:<a\s)))

1) regexr.com?314kq
2) regexr.com?314kt

[yui_room9]

Кстати пример от dsd_corp работает отлично не как контр :-D regexr.com?314l0

[Алексей]

yui_room9, вот тут должно матчится самое первое слово: regexr.com?314l9 А сейчас матчится второе вхождение. Крутой батл разворачивается :-) Отмахиваюсь от коллег и всяких дел, когда получаю новую регулярку на тестирование.

[yui_room9]

И Ап :)

Это из за большой «О», так как эксп буквально берёт маленькую, то есть если надо обе то такой вариант
"?([Оо]гурец)"?(?:(?![^>]*(?:<\/a>)|(?:".*>))|(?=[^>]*(?:<a\s)))

[dsd_corp]

Ну… У меня сейчас на примере из вопроса выделяет огурец в alt аттрибуте тега img: regexr.com?314li
Сколько не пытайтесь, я вам все-равно придумаю контрпример. Ломать — не строить ))
Кроме всего прочего в этой ветке я смотрю даже жадность(greedy) в регекспах не ограничивает никто )))

[yui_room9]

И Ап :)

dsd_corp Мой косяк, когда ковычки добавлял не учёл внутри тэгов :)

"?(огурец)("(?![^>]*>))?(?:(?![^>]*(?:<\/a>)|(?:".*>))|(?=[^>]*(?:<a\s)))

1) regexr.com?314lr

[dsd_corp]

Лучше сразу ставить там опцию global и смотреть что совпало, а что нет — так удобнее.
Вам кстати не надоело? Это бесконечная игра.
Тогда вот вам еще невалидные совпадения: regexr.com?314lu
Убивайте время дальше )))

[Алексей]

Так это ж уже примерно как кроссворд разгадывать. Не убийство времени, а времяпрепровождение.

[yui_room9]

И Ап :)

This is sparta!!! :D

"?(огурец)("(?![^>]*>))?(?:(?!(?:\s*<[^Aa][^>]*>\s*[^<>]*)*[^>]*(?:<\/a>)|(?:[^"'>]*["'][^>]*>))|(?=[^>]*(?:<a\s)))

1) regexr.com?314mm

[Алексей]

Да, для простоты давайте сразу договоримся о модификаторах /gi :-)

[Алексей]

Контр: regexr.com?314ms (не матчит первое вхождение в кавычках, но вне атрибута).

[yui_room9]

kostin
Вылезайте из моей головы :-D
Только собирался это написать.
Экспы это же замечательная головоломка.

Так то понятно что если ещё включить невалидный HTML и прочие прелести то експ не спасёт,
но при валидном можно покрыть до 70-80% случаев, а этого иногда и достаточно.

[yui_room9]

И снова Ап :)

"?(огурец)("(?=[^>]*<\/))?("(?![^>]*>))?(?:(?!(?:\s*<[^Aa][^>]*>\s*[^<>]*)*[^>]*(?:<\/a>)|(?:[^"'>]*["'][^>]*>))|(?=[^>]*(?:<a\s)))

1) regexr.com?314n2

[Алексей]

Думаю, в рамках квеста можно: а) считать код заведомо валидным и б) считать, что никто не станет писать теги внутри атрибутов.

[Алексей]

yui_room9, прямо в вашем последнем примере матчится несколько вхождений, а не только первое. То есть этот же пример является и контром.

[dsd_corp]

kostin, Так смысла же такой кроссворд не имеет. Результат известен заранее.
Между тем, мое решение ниже работает стабильно и надежно )

yui_room9, новая порция, теперь валидные в кавычках: regexr.com?314n5

[dsd_corp]

kostin, это из-за галки на опции global. Так удобнее — видеть все вхождения.
Уберите эту галку, и будет только первое.

[yui_room9]

dsd_corp

Предыдущий Ап, уже покрывает :)

1) regexr.com?314n8

[dsd_corp]

yui_room9, Почему в самом конце «Хочу огурец!!!» не покрыто?

[Алексей]

Пардон, с ума схожу, сам же g выше предложил юзать.

Чтобы обессмыслить кроссворд, получается, надо предъявить ту часть формулировки задачи, которая доказывает её нерешаемость на конечном на автомате.

[dsd_corp]

kostin, эта часть формулировки задачи неявна — это сам HTML.
В данном конкретном случае вероятность нахождения полностью рабочего решения есть(при условии валидности разметки). Но в целом:
1. Регулярка разрастется до неудобоваримого вида(вы уже через неделю не сможете разобрать, что именно она делает).
2. У нее будет хреновое быстродействие. При больших объемах текста для парсинга мое решение ниже выиграет по скорости. Это только на небольших текстовых кусочках оно работает медленнее. Так же как при записи файлов в файловую систему — большие файлы пишутся гораздо быстрее, чем куча мелких того же объема.
3. Любые изменения в ТЗ станут для вас адом.
4. При усложнении ТЗ быстро наступит момент, где единичная регулярка любой сложности уже не поможет. Ваш случай еще простой ))

[yui_room9]

И снова Ап :)

"?(огурец)[^><\s'"]*(?:"(?=[^>]*<\/))?(?:"(?![^>]*>))?(?:(?!(?:\s*<[^Aa][^>]*>\s*[^<>]*)*[^>]*(?:<\/a>)|(?:[^"'>]*["'][^>]*>))|(?=[^>]*(?:<a\s)))

1) regexr.com?314nk

Там прадва матчер кривой в самом софте,
показывает

1 capturing groups: group 1: (огурец)

А выделяет «огурец» или огурец!!!

При этом на локале матчит всё как надо :)

[yui_room9]

dsd_corp

Да почти всё верно :)

Кроме 2,
бывает что большие куски экспом обрабатываються быстрее чем малые, но пример уже не приведу, давно дело было :)

Ну и бывает что эксп быстрее дома, а бывает и наоборот, это всё надо мерять чтобы точно сказать.

А так эксп в этом случае будет нужен только если он не будет меняться и служить ровно одной цели, матчить слово в HTML. Если его будут улучшать то это уже адовое дело будет, особенно для того кто не сильно рубит в экспах.

[dsd_corp]

yui_room9, с матчером там все нормально.
Просто возврат регулярки подразумевает, что $matches[0] — это совпадение всего выражения, $matches[1] — первые скобки(subpattern), $matches[2] — вторые, и так далее.
capturing groups у данного матчера и есть все ваши возвращаемые субпаттерны. основное совпадение $matches[0] он туда не выводит, но он его подсвечивает в тексте.
То есть в вашем последнем выражении искомое в скобках '(огурец)' и является $matches[1].
Итого ваше выражение для preg_match подойдет, для preg_replace — нет.
preg_replace будет заменять полное совпадение, заменять может на любую комбинацию этих capture groups, но подлежащее замене будет именно полное совпадение.
Есть еще хинт, получить вашей регуляркой оффсеты с помощью preg_match с опцией PREG_OFFSET_CAPTURE, взяв оффсет самого слова 'огурец' из $matches[1], а потом уже с помощью substr_replace заменить именно слово огурец везде, где нужно, не взирая на остальной мусор.

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

Но вообще, как только вы в регулярке начинаете использовать ()|(), особенно на пару с (?...), производительность падает на порядки. На мелком куске текста оно конечно не покажет, на на больших наборах данных тупит по-страшному.

>> А так эксп в этом случае будет нужен только если...
Так это… вы сами посмотрите на то выражение, которое у вас уже получилось на данный момент. Через неделю-месяц если вам вдруг надо будет поменять в нем какие-то условия, у вас же зубы ныть начнут сразу )))

[yui_room9]

dsd_corp

Да я уже понял что он целиком выводит [0] вместо паттерна :)
Ну там можно через ещё один lookbehind сделать так что и в [0] будет только паттерн а не выражение, просто лениво :-D У нас же не реплэйс а матч и то первого вхождения.

>>, у вас же зубы ныть начнут сразу ))
Не начнут, я извращенец :-D
Ну и плюс можно эксп упростить, просто опять же лениво :-D

[dsd_corp]

yui_room9, cитуация осложняется еще и тем, что lookbehind должен быть фиксированной длины.
По крайней мере в движках регулярок большинства языков.

[yui_room9]

dsd_corp

Ошибся я, торможу после бессонной ночи :-D там через ещё один lookahead :) не через lookbehind.
Про behind знаю, так бы было проще через него много написать в этом экспе, но ограничения не дают :)

[Алексей]

Контр: regexr.com?314ur (не матчит перво вхождение, которое попадает внутрь цитаты, заключенной в кавычки).

[yui_room9]

kostin И снова ап :)

"?(огурец)[^><\s'"]*(?:"(?=[^>]*<\/))?(?:"(?![^>]*>))?(?:(?!(?:\s*<[^Aa][^>]*>\s*[^<>]*)*[^>]*(?:<\/a>)|(?:[^"'>]*["'][^>]*>))|(?=[^>]*(?:<a\s))|(?=(?:[^"'>]*["'][^>]*<)))

1) regexr.com?3151r

[Jaguar_ko]

Кажется нашли решение на 99.9% случаев:)

Answer 2

[Ents]

Сделать подобное невозможно никаким регулярным языком. Если интересно почему — читайте про конечные автоматы (частным случаем которых, являются регулярки)

Смотрите в сторону DOM

Comments

[Алексей]

Ents, а вы бы не могли указать на то, какое именно из условий поставленной задачи делает невозможным её решение на конечном автомате?

[Ents]

Которое при этом не обёрнуто внутрь тега … (т.е. не попадает в анкор какой-либо ссылки)
Которое при этом не является частью какого-либо атрибута (типа alt у тега img)

— вот-эти два. В частности они подразумевают наличие у системы неограниченной памяти, а у конечного автомата память конечна (как видно из названия :) )

Вообще задачи скобочных последовательностей регулярками не решаются. Ещё раз советую посмотреть в сторону ДОМ. Потому что вы сейчас тут напишите регулярку, которая ПОЧТИ работает, и она вас подведет в самый неподходящий момент

[Алексей]

Спасибо. Это я уже из академического интереса спрашивал. Через DOM-то текст уже обрабатывается (правда, с невалидным кодом есть проблемы и там), плюс своё отдельное DOM-решение ниже представил другой знатный участник этой дискуссии.

Answer 3

[Quiz]

Когда человек сталкивается с проблемой, он думает «Я могу легко решить эту проблему при помощи регулярного выражения!». С тех пор у него две проблемы...

Comments

[smartup]

Ну, да. Это я понимаю. И культовый ответ на вопрос про html и регулярки мне тоже известен :-) Но если уж оно совсем нерешаемо регулярками, то интересно было бы разобраться, что именно тут непреодолимого.

[Алексей]

Вообще я далеко от решения завяз, но основным боком является невозможность вывести то, что совпадает с одной группой и не совпадает со второй. Как это реализовать — я не знаю.

[egorinsk]

Несмотря на комментарий на SO.

HTML можно резать регуляркой на блоки (блоки типов: доктайп, комментарий, PI, тег, CDATA, текст), например, с помощью preg_split и дальше проходить по массиву матчей и в них менять что требуется. Но это не очень простая задача, например, для тега, если вы пишете регулярку, надо помнить, что символ «больше» внутри кавычек не закрывает тег, и подобные сложности. Это сложно и чревато ошибками.

Вам наверно проще использовать DOM или потоковый парсер XML.

Answer 4

[dsd_corp]

По просьбам выше выкладываю.
Идем в этот репозиторий.
Тащим оттуда три файла: xmlp.inc, progress.inc и cucumbers.zip.
Сам пример по вашему вопросу в cucumbers.zip.
xmlp.inc — парсер типа DOM.
progress.inc — просто вспомогательный, используется примером для замера и вывода на экран времени работы.

Нужно распаковать zip и в получившуюся директорию скопировать остальные два файла.

Собственно запускаем пример example.php

Основная нужная вам функция: replace_text()
Первые два параметра понятны и так — это текст для поиска и искомое.
Четвертый параметр $ignore_tags — это массив имен тегов, которые мы пропускаем. В вашем случае по условию это 'A'. 'IMG' в примере можно исключить из этого массива — я просто так добавил )
Третий параметр — на что заменить найденные вхождения.
Но если этот третий параметр false(я так сделал опцию), то функция вернет не измененную строку, а массив оффсетов найденных вхождений.
Функция не останавливается на первом валидном вхождении — заменяет все, что найдет, и все, что подходит по условию.
Если вы не хотите, чтобы функция правила косяки HTML/XML ее собственному разумению, ну и заодно хотите заменить только определенные по счету вхождения, тогда вы можете получить оффсеты, и потом либо в цикле заменить все PHP-шной функцией substr_replace(т.к. оффсеты вхождений у вас есть, а длину искомой строки вы тоже знаете), либо заменить только первое вхождение по первому оффсету из возвращенного массива.

В примере функции frt1(), frt2() и frt3() идентичны по функционалу, frt1() работает рекурсивно, в остальных от рекурсии я избавился. frt3() от frt2() отличается только ассоциативной индексацией стека(в глазах не так рябит и понятнее). А так все три эти функции делают одно и то же, первые две можно удалить.
Фактически используется frt3() для поиска с заменой и frt4() для получения оффсетов.

Файл cucumbers.txt — это ваш пример, в cucumbers1.txt я напихал еще огурцов в разные места )))
Эти файлы используются как входные, ну там разберетесь, видно все по коду.
Результаты работы экзампла тоже в файлы выплевываются, вы их увидите в той же директории после отработки скрипта.
Будут вопросы — задавайте.

Comments

[dsd_corp]

P.S. Ах да, там 1251 кодировка, если у вас система не винда, конвертните example.php и .txt-шники перед использованием.

[Алексей]

Основательно. Ответ на вопрос тянет на отдельный пост. Спасибо! Обязательно на выходных всё это дело погоняю на боевых данных.

[dsd_corp]

Сам файл xmlp.inc давно тянет на отдельный пост, все вот время никак не выберу… парсер написан еще три года назад(в репозитории ссылку на хабрастатью видели наверно? в ней есть пруф о трех годах).

Кстати, чтобы лучше понять, что мы получаем в этой DOM-оподобной структуре, и возможно применить этот парсер где угодно еще, можете внутри функции replace_text сразу после вызова xmlp_data2struct_with_offset вставить такую строчку:

file_put_contents('./struct.txt', var_export($struct, true));

После чего в выводном файле struct.txt уже рассматривать структуру в человеческом виде.
Собственно структура будет состоять из двух частей. В $struct[0] будет сама DOM-структура, а в $struct[1] инфа о косяках и список их индексов.

Например(кликнуть для просмотра)

Пример части с ошибками:

  1 => 
  array (
    0 => 
    array (
      'description' => 'Unknown closing tags: 9',
      'data' => 
      array (
        55 => 56,
        58 => 59,
        62 => 65,
        66 => 67,
        69 => 70,
        71 => 72,
        50 => 111,
        119 => 122,
        123 => 124,
      ),
    ),
    1 => 
    array (
      'description' => 'Unclosed tags recovered: 4',
      'data' => 
      array (
        0 => 55,
        1 => 66,
        2 => 69,
        3 => 123,
      ),
    ),
  ), 

Это лог ошибок с файла 276604.fb2, который есть в корне репозитория на ГитХабе.
Здесь встреченных неизвестных(неожиданных) закрывающих тегов: 9
Первый из этих девяти втречен в элементе 56 и закрыл собой элемент 55.
Найти их по индексу можно в том же файле struct.txt, ища строку ['ind' => 55] (56-го элемента уже не найдете, т.к. закрывающие теги в результирующую древовидную структуру не входят).
В исходном тексте это соответствует строке '<p>Анджей <a>Пилипюк</p>', где тег 55 это '<a>', а тег 56 это '</p>'.
Эту же часть вы в struct.txt по индексам найдете как:

                    3 => 
                    array (
                      'ind' => 54,
                      'offset' => 1166,
                      'end_offset' => 1169,
                      'length' => 3,
                      'name' => 'p',
                      'lname' => 'p',
                      'known' => 1,
                      'type' => 1,
                      'content' => 
                      array (
                        0 => 'Анджей ',
                        1 => 
                        array (
                          'ind' => 55,
                          'offset' => 1176,
                          'end_offset' => 1179,
                          'length' => 3,
                          'name' => 'a',
                          'lname' => 'a',
                          'known' => 1,
                          'type' => 1,
                          'content' => 
                          array (
                            0 => 'Пилипюк',
                          ),
                        ),
                      ),
                    ),

Фактически это значит, что есть тег [id#54 <p>], который в себе содержит('content' =>) два элемента:
1. строка 'Анджей ';
2. тег [id#55 <a>], содержащий в себе('content' =>) один элемент: строку 'Пилипюк'.

Неожиданный тег [id#56 </p>] (неожиданный, потому что текущим открытым был [id#55 <a>]) закрыл оба предыдущих тега: незакрытый [id#55 <a>] и свой «родной» [id#54 <p>].

Так произошло потому, что парсер при встрече такого неожиданного тега пытается откатиться по стеку назад и закрыть ближайший подходящий(с тем же именем), попутно закрывая остальные открытые.
Таким образом, к примеру, строка:

<p>Анджей <a>Пилипюк шел <b>по улице, насвистывая <i>незатейливую мелодию</p>

превратится в результате в:

<p>Анджей <a>Пилипюк шел <b>по улице, насвистывая <i>незатейливую мелодию</i></b></a></p>

Собственно, этот же незакрытый тег [id#55 <a>], закрывшийся автоматически, мы встречаем первым в следующем разделе ошибок 'Unclosed tags recovered: 4'.

Вот как-то так.

[Алексей]

dsd_corp, а ваш xmlp.inc отдельно от всего прочего позволяете юзать в опенсоурсных проектах? Например, в модулях для открытых CMS?

[dsd_corp]

Да без проблем. Делайте с ним что хотите. Не забывайте только периодически в git поглядывать за обновлениями. Даже если вы будете полностью менять файл под себя, и обновления основной ветки вам не нужны, там все-равно могут появиться полезные для вас комментарии и правки найденных в последствии багов.
Например на текущий момент парсер все-таки предназначен для работы в основном с более-менее логичными XML структурами, чем с бесбашенным HTML.

Для XML не реализована обработка спецтегов типа CDATA.
Предпарсер не обрабатывает в аттрибутах тегов(внутри кавычек) упомянутую выше ситуацию с символами <>.
Все руки не доходят это доделать.

Для HTML есть куча косяковых нюансов со вложенностью тегов, типа автоузнавания и автозакрытия некоторых последовательно идущих одинаковых:
Как обрабатывать вложенные ссылки <a>? Оставлять вложенными или закрывать каждую, разбивая любую сложную ссылку на массив последовательных?
Некоторые авторы пишут абзацы <p>, не закрывая эти теги, то есть вообще не используя </p>. На данный момент парсер их позакрывает сам, но сделает при этом в DOM-дереве вложенную елочку из этих тегов. А надо бы, чтобы перед каждым следующим абзацем предыдущий закрывался. И это только, если каждый новый открывающийся <p> идет на том же уровне, что и предыдущий. Иначе ведь бывает, что в абзаце внутри таблица, а в ней еще идет текст абзацами.
Ну и т.п. Для HTML есть куча нюансов логической обработки структур и разных допущений, не относящихся к общему парсингу DOM.