Pull to refresh

Comments 13

Я для асинхронной загрузки кучи страниц использовать модуль async и метод async.map.
Круто. Ребята использую итератор Iterator — совсем уж забыл про него. Допишу как будет время с ним.
На Node.js очень удобно парсить… Но, собственно, это и единственное, что на нём делается действительно удобно. Например, сферический пример №1 из статьи не сможет обработать redirect, придётся вставлять рекурсию:
if ( [301, 302].indexOf(res.statusCode) > -1 ) {
	download(res.headers.location); 
	return;
}

Да и к тому же работать с кукисами приходится вручную, а все мало-мальски сложные странички их проверяют (сервер всегда готов выслать дулю вместо странички, если что не так). И совсем уж плохо, когда часть контента страницы формируется с помощью Javascript.
Всё сильно упрощается при использовании фреймворка node-webkit, на котором мне даже удалось написать универсальную качалку статей (sciencedirect, springerlink, ACS и RSC), но по граблям пришлось потоптаться солидно, даже исключая баги самого NWK и ограничиваясь лишь Node.js-частью.
Самое противное в этой ноде то, что она о-очень неохотно убивает объекты — открытые файлы, сокеты и т.д.
Например, построив простейшую процедуру закачки столкнулся с тем, что закачивается… ровно пять файлов! После чего скорость закачки падает до одного файла в минуту. Оказывается, нода не прибивает сокеты после request'а, а на каждый запрос создаётся новый сокет. Частично проблема решилась через увеличение лимита сокетов и отключение Agent'а в опциях запроса, полностью же удалось победить зловредный фреймворк лишь отловом события подключения, запоминанием socket-объекта во временной переменной и последующим вызовом socket.destroy().
И вот там полно таких проблем, возникающих буквально на пустом месте. Например, файлы после вызовов end() и close() всё равно числятся открытыми и, к примеру, не могут быть удалены сторонними программами, пока фреймворк активен (а всё потому, что работа со stream'ами там организована мягко говоря не очевидным способом).
Цитата из официального репозитория: «Request is designed to be the simplest way possible to make http calls. It supports HTTPS and follows redirects by default.» Должен поддерживать редирект — не все так плохо. Ну насчет кукисов вообщем-то они стандартные можно от своего браузера вписать + jar опцию чтобы он запоминал их, но я просто брал из своего браузера при посещение сайта и копировал в куки агента.
Насчет сокетов у меня конечно на всех серверах стоит максимум открытых соединений, поэтому никогда в это не упираюсь, но вроде работает и в долгом режиме оно все, может и с неохотой но убивает Garbage Collector'ом. Так что 5 сокетов видимо ему просто мало чтобы разогнатся — не считает наверное garbage collector своим долгом, но вообще там можно поставить ограничение на количество одновременных агентов(у реквеста опять же).
Просто так в лоб написать парсер с Request не получится. Он не умеет работать, например, с win-1251
С кодировками, да, беда. Бросил идею парсинга по этой причине.
ну почему беда.
Берете http.get, iconv и вперед
Ну да. Нужно принять как Buffer и прогнать через iconv.

Сейчас внесу пример в статью.
Там тоже jsdom внутри. Cheerio можно предложить автору или самому форкнуть — должно ускорится в этом плане.
При попытке парсинга статей с этого сайта nginx выдаёт 403 Forbidden. Вероятно, администрация приняла какие-то меры по защите, потому что на остальных сайтах всё впорядке. Подскажите, пожалуйта, как обойти эту ошибку в сугубо исследовательских целях.
PS: тоже использую request и cheerio.
pastebin.com/NvGcvPwq
сервер требует(хз зачем видимо такая защита) user-agent. Я изначально подумал что без хоста не разроучивает до конца(но оказалось и без хоста это прекрасно живет). Так что просто дополнительным параметром передал user-agent в header. Вообще коненчо нужно брать header'ы браузера и пытаться их пробовать на других страницах, если такие проблемы возникают.
Sign up to leave a comment.

Articles