Подскажите пжл хороший парсер который может понимать не валидный html. Пытался использовать Tinyxml и родной xml парсер Builder'а (TXmlDocument), но они "спотыкаются" на не валидном html. Мне нужно простое решние т.е. каких-нить гигантов типа Xerces не предлагать. Вообще суть данного парсера для того чтобы грабить input'ы для формирования post запроса. Пробовал для этих целей TRegExpr, для этих целей но он не подошел (при использовании в многпоточном режиме raise Exception). Также важно чтоб был thread-safe.
Компонент по регуляркам отлично пашет в потоках. Главное его там создавать, юзать и удалять. в чем проблема с первыми? Сделай поиск на </html>, если найдено - скармилвай парсерам, если нет - перекачивай
В проекте использовалось достаточно много раз рекулярки и при наличии нескольких потоков выдает ошибку что выполнены ф-йия execnext перед ф-цией exec, что в принципе быть не может (просматривал код по нескольку раз). Поэтому решил что синтаксический анализатор будет лучше. ЗЫ Щас я что-то датый вообщем надо бы еще разок код пересмотреть, но вопрос остается открытым, парсинг HTML альтернативы регуляркам, два требования работа с невалидым HTML и thread-safe
Гыгы, лол Поток А выполнил Exec, переключился контекст, поток Б заного выполнил Exec и сразу ExecNext, переключился контекст, поток А пытается выполнить свой ExecNext а тут облом, ибо регулярка сброшена. Ты либо в крит. секцию оборачивай, либо создавай локальные копии TRegExpr для каждого потока, но так дела не делаются. Еще хорошо что класс генерит эксепшн, тебе сразу давая понять что ты что-то неправильно делаешь, а иначе была бы у тебя каша малаша, поток А работал с результатами для потока Б, и наоборот, и ты бы думал ах почему ничего не работает или работает криво Ну и да, автор компонента как всегда виноват Парсинг html - ресурсоемкая задача, а вот TRegExpr работает достаточно шустро. Что так трудно прицепить критическую секцию?
Мен я же не совсем баран (во всяком случае хочется в это верить) у меня создан отдельный класс в котором и реализуется все операции с парсингом (с помощью TRegExpr) внутри каждого потока создается экземпляр класса. Я думал этого вполне достаточно чтобы не заключать ф-ции для работы с данными в критические секции т.к. это не общие данные, а данные потока. Если я ошибаюсь, буду рад услышать твои рекомендации.
Код создания и объявления нужен чтобы на 100% тебе сказать ответ А по этим симптомам пока все указывает на то что я написал выше Возможно что ты где-то накосячил и объект класса регулярки у тебя оказался расшаренным между тредами ЗЫ В соседней твоей теме тоже все указывает на это
Если нужно спарсить конкретные данные со страницы, то с помощью стандартных функций для работы со строками будет быстрее работать, чем с помощью TRegExpr.
причем здесь стандартные функции если человек ищет парсер HTML Я говорю про что целиком парсить с помощью парсеров ресурсоемко
