QueryPath парсинг документа

Господа поделитесь тайным знанием кто с этой либой работал.
Код: http://pastebin.com/qfHc4SzD

строка 1: строка с которой работаем
строка 3: загружаем строку в либу
строки: 5,7,9,10,11: пытаемся строку вынуть из либы.

Как строку то выдернуть? без еблизма. Строку загрузили, с ней внутри либы поработали, теперь ее надо сохранить в строку. Все методы перебрал. Должно быть что-то типа $html->save_to_string(). без лишних хуйнюшек вдовесок.

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

Код:

echo $html->innerXHTML('body div')

mr. snatch писал:

ну, если у тебя есть исходная строка, то зачеп ей из объекта выдёргивать, можно просто исходную строку и юзать. Если же нужна именно провалидированная (исправленная), то например так Код: echo $html->innerXHTML('body div')

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

Короче либа тухлая.
Для поисковиков: QueryPath отзывы, QueryPath мануал, QueryPath учебник, QueryPath статья, QueryPath как пользоваться, QueryPath описание.

Проблема кодировок. Жуткая. Лишняя функциональность входящей и исходящей кодировки, которая не работает. Дополнительно вырезать непонятно откуда появившийся body конечно круто. Два последних метода(строки 9, 10):

$html->innerHTML(); # Двойные теги делает одинарными (<a></a> -> <a />). Одинарные не коверкает.
$html->innerXHTML(); # Одинарные теги делает двойными (<img /> -> <img></img>). Двойные не коверкает.

Зачем оно это делает тоже непонятно. Проблему кодировок (русский текст из UTF-8 php-файла выводим в консоль обычной убунты - кракозябры) не решил. Короче хуйня. альтернатива: htmldomparser

эм, ну хз, как по мне лично норм

Цитата:

Проблема кодировок. Жуткая. Лишняя функциональность входящей и исходящей кодировки, которая не работает

это общая проблема всего, что юзает libxml или mb_detect_encoding, если конечно дополнительно не производить каких-то манипуляций и собственных проверок (угадывания реальной кодировки не смотря на то, что у нас в <meta http-equiv... charset=... или что вернул сервер в заголовке)
а так же, очень часто, когда исходная кодировка utf-8 с BOM. Вот его нужно просто вырезать из всех ответов безотносительно от того, юзаем ли мы QueryPath, phpQuery или просто DomDocument.
Третья проблема, возникающая с кодировками (когда используется libxml) в тех случаях, когда кодировка страницы не в ISO (допустим cp1251 или кириллица в том же UTF-8) и ДО тэга <meta http-equiv="Content-Type" content="text/html; charset= идёт какой-то не ISO текст, например, вот как на мастере ;) :

Код:

<title>QueryPath парсинг документа > Master-X.com </title>    <meta http-equiv="Content-Type" content="text/html; charset=windows-1251" />

правильно, кодировка для этого документа уже не преобразуется... я на это как то сам случайно ещё давно натолкнулся, и эта особенность libxml как то не документирована, так что, после проверки на наличие BOM-сигнатуры я проверяю структуру документа, и если такое встречается, то всовываю тэг <meta> перед <title> простыми регулярками, затем уже отдаю DomDocument (QueryPath - это просто оббёртка над ним)

Цитата:

$html->innerHTML(); # Двойные теги делает одинарными (<a></a> -> <a />). Одинарные не коверкает. $html->innerXHTML(); # Одинарные теги делает двойными (<img /> -> <img></img>). Двойные не коверкает.

ну, это не баг, а особенности реализации этих конкретных ф-ций.
сама QueryPath юзает DomDocument, который в методах saveHTML/XML имеет второй параметр - $options, который на данный момент может принимать только одно значение нейтивной константы от libxml - LIBXML_NOEMPTYTAG, указывание которого и приводит к тому, что ты говоришь:

Цитата:

LIBXML_NOEMPTYTAG (integer) Expand empty tags (e.g. <br/> to <br></br>)

почему разрабы запихнули его в innerHTML, я хз, но если это как-бы не устраивает, просто добавляешь свой собственный метод именно нужной в твойм случае сериализации, и как бы всё... например я так и делал когда-то - DOM в массив перегонял.

имхо, QueryPath - штука хорошая, но для своей области применения, и следовательно со своей спецификой, и если что-то не устраивает в какой-либо конкретной специфической реализации, то это всегда можно переопределить или расширить (у неё вменяемое АПИ для написания своих каких-то плагинов) так что, я бы всё-таки не спешил её выкидыть, но это разумеется имхо )

mr. snatch писал:

это общая проблема всего, что юзает libxml или mb_detect_encoding, если конечно дополнительно не производить каких-то манипуляций и собственных проверок (угадывания реальной кодировки не смотря на то, что у нас в <meta http-equiv... charset=... или что вернул сервер в заголовке)

так в том и дело что ничего определять не требуется. требуется просто не лезть. а оно лезет. просто долго сидел на хтмлдомпарсере. там такой проблемы нет как явления

mr. snatch писал:

почему разрабы запихнули его в innerHTML, я хз, но если это как-бы не устраивает, просто добавляешь свой собственный метод именно нужной в твойм случае сериализации, и как бы всё... например я так и делал когда-то - DOM в массив перегонял. имхо, QueryPath - штука хорошая, но для своей области применения

ну видимо она не для парсинга а для создания заточена. отсюда и кодировки и довстраивание плюшек и коверкание тегов. если уж на то пошло то определятор кодировки - отдельная либа. исправлятор невалидной верстки - отдельная. парсер должен только спарсить. хтмлдомпарсер заебись, но устарела она. 2008 года. и пару моментов не понимает, сложные селекторы типа a.class1.class2, sel1>sel2, a[name="name"]

sel1>sel2 дописал, остальные не осилил

FXIX писал:

хтмлдомпарсер заебись, но устарела она. 2008 года. и пару моментов не понимает, сложные селекторы типа a.class1.class2, sel1>sel2, a[name="name"]

угу, от именно поэтому когда-то и начал сабж юзать )