Node-webkit(nw.js) это гибрид ноды и webkit — движка того же хрома, к примеру. Так что да, он умеет большую часть из того, что умеет нормальный браузер, соответственно, у него и запросы по ресурсам приблизительно те же(запустил сейчас просто окно с гуглом, отожрало около 140МБ). Впрочем, большую часть отъедает, скорее всего, рендер.
По скорости работы не замерял, основным критерием в большинстве случаев служило удобство. Если не хватает клиентского/нодовского js'а, всегда можно дописать либо использовать код на плюсах при помощи аддонов либо через node-ffi, либо код на C# через edge.js. Главный же профит для парсеров это, конечно же, использование jQuery. К примеру, это может выглядеть как-то так:
//функция для построения DOM
var _html=function(html){
return $('<div></div>').html(html);
};
//К примеру, скомбинируем node'овский request и jQuery
request.get(url, function(err,res,html){
var container=_html(html);
var name=container.find('.name span').text().trim();
});
//Или то же самое на чистом jQuery
$.get(url, function(html){
var container=_html(html);
var name=container.find('.name span').text().trim();
});
У меня выбор был между защитой информации и электроникой. На 1 ехать минут на 15-20 дольше и пары начинались минут на 15 раньше. Выбрал электронику, не жалею(стал программистом, верхушка моих знаний по электронике — отличить транзистор от резистора. Иногда.).
Очень повезло с преподавателями и группой: как минимум, 1 преподаватель дал толчок к развитию интереса к программированию, 2 одногруппника нынче мои коллеги(еще 1 уже ушел на другую работу).
Курса с 3 занятия практически не посещал, так что университет работе особо не мешал, но базовые знания и умения в жизни дал(основы умения договариваться, основы общения с разными людьми, умение быстро искать нужные материалы, умение лить водичку в дипломе, в конце-концов).
В итоге, хотя и поступал в ВУЗ, в котором после 3 курса бывал довольно редко и по принципу «поближе к дому», все равно не жалею — оно того стоило)
Угу, когда есть интерес и вдохновение, экспериментирую с разными языками. Пока лидируют C# и js.
Да и, если на то пошло — если задачу можно реализовать на языке без большого геммороя — то чем плох этот язык для этой задачи? Можно кодить на системном уровне(причем с простым и читальбельным синтаксисом… если не считать callback-in-callback) — почему бы и нет? Да и нода поддерживает нативные аддоны, не хватает функционала — дописываем на плюсах)
Согласен, хотя в контексте «получить данные из 'интернет-обозревателя'(С)» и «А напишите в комментариях, какие ещё решения вам приходят в голову и мы подумаем, получится или нет.», сойдет.
Да и статья, как я понимаю, про MSAA, а не то, как стырить данные из браузера)
Есть еще один способ(по крайней мере, под шарп) — использование FiddlerCore.
Перехватываем все исходящие/входящие соединения и, если перехваченный трафик содержит в себе html, добавляем к нему js.
А внутри js уже можно писать любую необходимую логику, да и доступ к dom-елементам никто не отменял
Позвольте уточнить, трафик read-only только в случае с pcap.
Как минимум, трафик можно редактировать посредством прокси(из готовых решений — тот же WPF-или-как-там-его-и-его-аналоги). Защита от подобных программ далеко не всегда работает, взять тот же Hackshield в Archeage. Кроме того, это — довольно универсальный способ.
Кроме того, зачастую довольно удобно управлять поведением игры при помощи упомянутого dll-inject'а и перехватом нужных функций. Это, кстати говоря, решает проблему с окнами — dll много памяти не скушает, всю работу, по факту, выполняет клиент. Кроме того, если у клиента нет проверки на checksum, а защита не расчитана на подобные экзерсисы, можно поправить таблицу импорта и подгружать dll уже на старте приложения, а не перетыкать ее инжектором.
Еще довольно неплох в плане подхода micromacro — есть базовые функции для работы с памятью, а вся логика строится на lua/xml(код/путевые точки). Главный минус — вряд ли будет работать с адекватной защитой.
Со сканированием пикселей — согласен, сам такой подход не пробовал, но для комплексных задач представляется довольно сложным в реализации и несколько ограниченным в функционале.
За способ, описанный в статье, отдельное спасибо(особенно — за шарп), интересный подход. Еще вместо расчета офсета вручную можно было бы применить GetProcAddress, но это работает только для экспортированных функций.
Естественно, даже в тестовой версии сделал простенькое окно загрузки) И да, согласен с замечанием — применения загрузчика в итоге не дает разницы между обычной подгрузкой и подгрузкой 1 файлом.
По скорости работы не замерял, основным критерием в большинстве случаев служило удобство. Если не хватает клиентского/нодовского js'а, всегда можно дописать либо использовать код на плюсах при помощи аддонов либо через node-ffi, либо код на C# через edge.js. Главный же профит для парсеров это, конечно же, использование jQuery. К примеру, это может выглядеть как-то так:
Но вообще, из того, что пробовал использовать для написания парсеров, лучше nw.js+jQuery не видел.
Очень повезло с преподавателями и группой: как минимум, 1 преподаватель дал толчок к развитию интереса к программированию, 2 одногруппника нынче мои коллеги(еще 1 уже ушел на другую работу).
Курса с 3 занятия практически не посещал, так что университет работе особо не мешал, но базовые знания и умения в жизни дал(основы умения договариваться, основы общения с разными людьми, умение быстро искать нужные материалы, умение лить водичку в дипломе, в конце-концов).
В итоге, хотя и поступал в ВУЗ, в котором после 3 курса бывал довольно редко и по принципу «поближе к дому», все равно не жалею — оно того стоило)
Да и, если на то пошло — если задачу можно реализовать на языке без большого геммороя — то чем плох этот язык для этой задачи? Можно кодить на системном уровне(причем с простым и читальбельным синтаксисом… если не считать callback-in-callback) — почему бы и нет? Да и нода поддерживает нативные аддоны, не хватает функционала — дописываем на плюсах)
Нет. Не может быть. Ну точно не может быть. Это же....Javascript!
Извините, не удержался.
Да и статья, как я понимаю, про MSAA, а не то, как стырить данные из браузера)
А за вопросы такие еще в детстве по жопе бить нужно(за шуточные — шуточно) ).
Перехватываем все исходящие/входящие соединения и, если перехваченный трафик содержит в себе html, добавляем к нему js.
А внутри js уже можно писать любую необходимую логику, да и доступ к dom-елементам никто не отменял
Как минимум, трафик можно редактировать посредством прокси(из готовых решений — тот же WPF-или-как-там-его-и-его-аналоги). Защита от подобных программ далеко не всегда работает, взять тот же Hackshield в Archeage. Кроме того, это — довольно универсальный способ.
Кроме того, зачастую довольно удобно управлять поведением игры при помощи упомянутого dll-inject'а и перехватом нужных функций. Это, кстати говоря, решает проблему с окнами — dll много памяти не скушает, всю работу, по факту, выполняет клиент. Кроме того, если у клиента нет проверки на checksum, а защита не расчитана на подобные экзерсисы, можно поправить таблицу импорта и подгружать dll уже на старте приложения, а не перетыкать ее инжектором.
Еще довольно неплох в плане подхода micromacro — есть базовые функции для работы с памятью, а вся логика строится на lua/xml(код/путевые точки). Главный минус — вряд ли будет работать с адекватной защитой.
Со сканированием пикселей — согласен, сам такой подход не пробовал, но для комплексных задач представляется довольно сложным в реализации и несколько ограниченным в функционале.
За способ, описанный в статье, отдельное спасибо(особенно — за шарп), интересный подход. Еще вместо расчета офсета вручную можно было бы применить GetProcAddress, но это работает только для экспортированных функций.
И по поводу следующих статей — однозначно писать!
Обновил браузер — все разом заработало через Blob. Так что для мобильных платформ способ также подходит, по крайней мере, для android.