Есть несколько вещей, которые необходимо уточнить, прежде чем ответить на этот вопрос:
- follow-sibling вернет ВСЕ последующие братья, а не только непосредственные. Поэтому, если после этого есть узлы, они также будут возвращены.
- HTML не является XML. Хотя LXML попытается очистить исходный код для вас, если вы не можете доверять чистоте входящего HTML-кода, ваши XPath-файлы могут потерпеть неудачу. Например. Я полагаю, что теги заголовков не нуждаются в закрывающих тегах в HTML, поэтому в зависимости от того, насколько поврежден источник, LXML может неправильно поставить дочерний элемент, что может нарушить XPath
- У заголовков не может быть дочерних элементов, что может влиять на то, как LXML очищает их (например, добавление тега тела между ними и т. Д.).
Проверка этого в редакторе XML показывает, что ваш XPath действителен, но я испытывал недостаток элементов при тестировании в LXML, что может означать, что он каким-то образом изменяет XML (но я не проверял).
Я бы порекомендовал переосмыслить, если XPath является инструментом для этой работы, особенно если вы пытаетесь использовать его для подкачки веб-страниц или аналогичного.
Вы также можете подумать о переписывании оператора XPath, чтобы он также был немного более читабельным.
//*[contains(text(),'some_text')]/following-sibling::*
Это говорит: найдите мне любой элемент, у которого есть «некоторый текст» в тексте, затем найдите следующих его братьев и сестер.
//*[preceding-sibling::*[position()=1 and contains(text(),'some_text') and ]]
В то время как это говорит: найдите мне элемент, у которого у первого предыдущего родного брата есть текст, который содержит "некоторый текст".
Это может быть проблема стиля, но я нахожу последнее более читабельным.