FXIX
Господа поделитесь тайным знанием кто с этой либой работал.
Код:
http://pastebin.com/qfHc4SzD
строка 1: строка с которой работаем
строка 3: загружаем строку в либу
строки: 5,7,9,10,11: пытаемся строку вынуть из либы.
Как строку то выдернуть? без еблизма. Строку загрузили, с ней внутри либы поработали, теперь ее надо сохранить в строку. Все методы перебрал. Должно быть что-то типа $html->save_to_string(). без лишних хуйнюшек вдовесок.
FXIX
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
mr. snatch
эм, ну хз, как по мне лично норм
Цитата:
Проблема кодировок. Жуткая. Лишняя функциональность входящей и исходящей кодировки, которая не работает
это общая проблема всего, что юзает 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 - штука хорошая, но для своей области применения, и следовательно со своей спецификой, и если что-то не устраивает в какой-либо конкретной специфической реализации, то это всегда можно переопределить или расширить (у неё вменяемое АПИ для написания своих каких-то плагинов) так что, я бы всё-таки не спешил её выкидыть, но это разумеется имхо )
FXIX
mr. snatch писал:
это общая проблема всего, что юзает libxml или mb_detect_encoding, если конечно дополнительно не производить каких-то манипуляций и собственных проверок (угадывания реальной кодировки не смотря на то, что у нас в <meta http-equiv... charset=... или что вернул сервер в заголовке)
так в том и дело что ничего определять не требуется. требуется просто не лезть. а оно лезет. просто долго сидел на хтмлдомпарсере. там такой проблемы нет как явления
mr. snatch писал:
почему разрабы запихнули его в innerHTML, я хз, но если это как-бы не устраивает, просто добавляешь свой собственный метод именно нужной в твойм случае сериализации, и как бы всё... например я так и делал когда-то - DOM в массив перегонял.
имхо, QueryPath - штука хорошая, но для своей области применения
ну видимо она не для парсинга а для создания заточена. отсюда и кодировки и довстраивание плюшек и коверкание тегов. если уж на то пошло то определятор кодировки - отдельная либа. исправлятор невалидной верстки - отдельная. парсер должен только спарсить. хтмлдомпарсер заебись, но устарела она. 2008 года. и пару моментов не понимает, сложные селекторы типа a.class1.class2, sel1>sel2, a[name="name"]