Лет пять-шесть назад, когда я ещё программировал преимущественно на PHP, я начал использовать библиотеку curl для парсинга сайтов. Мне нужен был инструмент, который позволял эмулировать сессию пользователя на сайте, отсылать заголовки обычного браузера, давать удобный способ отсылки POST-запросов. Сначала я пытался использовать напрямую curl-расширение, но его интерфейс оказался очень неудобным и я написал обёртку с более простым интерфейсом. Время шло, я пересел на python и столкнулся с таким же дубовым API curl-расширения. Пришлось переписать обёртку на python.

Редактор Emacs, флагманский продукт GNU и самая знаменитая разработка Ричарда Столлмана, как оказалось, нарушает лицензию GPL с 28.09.2009 г, когда в комплекте с программой началось распространение бинарников без исходных кодов.

Речь идёт о пакете CEDET для анализа статичного кода. Версии Emacs 23.2 и 23.3 содержали синтаксические анализаторы (парсеры), созданные программой bison по грамматикам, без приложения соответствующих грамматик. Технически, сами эти парсеры можно считать исходным кодом (они компилируются и пригодны для чтения человеком), хотя фактически они таковыми не являются — видимо, из-за этого и произошла путаница в толковании условий лицензии GPL. Сокрушаться по поводу такого «нарушения» могут только самые принципиальные люди вроде Ричарда Столлмана.

«Мы совершили очень серьёзную ошибку, — написал Ричард Столлман в рассылке emacs-devel. — Каждый, кто распространял эти версии Emacs, нарушал GPL не по своей вине. Нам нужно исправить данные релизы ретроспективно (или удалить их), и нужно сделать это немедленно. Я вижу два быстрых способа исправить релизы: удалить скомпилированные файлы или добавить для них исходные коды».

Разработчики Emacs не знают, куда пропали исходники CEDET, они уже начали поиски. Сам Ричард Столлман не имеет отношения к разработке Emacs с 2008 года.

Здравствуй Хабр!

Месяц тому писал как можно много сайтов на одной странице разместить для пересылки и открытия одним кликом.

На днях вышел Вордпрес плагин, который делает следующее.

1. Сканирует каждый пост и / или страницу и находит там все ссылки.

2. Группирует эти ссылки в одну.

3. Внизу поста добавляет линк, при нажатии на который всё открывается в табах одним кликом.



Вопрос: зачем мне и моим читателям это нужно?

Я вот чего давно не могу понять — почему MySQL до сих пор не встроила защиту от инъекция прямо в парсер? Ведь ее парсер в любом случае разбирает запрос любой сложности на составляющие и точно знает, куда какое значение пойдет. Что мешает, скажем, сделать вот так:

mysql_query_safe("
SELECT * FROM table1
LEFT JOIN table2 ON (table1.field = table2.field)
WHERE name = $1 AND id=$2 AND time = $3
", "habra'1", "blablabla", "NOW()");


Парсер знает, что name — строковое поле. Значит, он автоматически экранирует одиночные кавычки и окружит значение обычными кавычками. Далее, парсер знает что id — числовое поле и выдаст ошибку, что ему посылают строку. И, наконец, парсер знает, что time — это поле типа DATETIME, а NOW() — это функция, выдающая время, и не будет окружать данное значение кавычками.

По-моему, встроить это всё прямо в парсер MySQL — куда логичнее, удобнее и безопаснее, чем извращаться, изготовляя разные ORM для каждого из языков программирования.

UPD: Я идиот, всё это есть, но почти никто не знает. В комментариях хорошие ликбезы.

Каждый, кто пишет парсеры, знает, что можно распарсить сто сайтов, а на сто-первом застрять на несколько дней. Структура очередного отмороженного сайта может быть сколь угодно сложной, и, когда дело касается сжатых javascript-ов и ajax-запросов, расшифровать их и извлечь информацию с помощью обычного curl-а и регекспов становится дороже самой информации.

Грубо говоря, проблема в том, что в браузере работает javascript, а на сервере его нет. Нужно либо писать интерпретатор js на одном из серверных языков (jParser и jTokenizer), либо ставить на сервер браузер, посылать в него запросы и вытаскивать итоговое dom-дерево.

В древности в таких случаях мы строили свой велосипед: на отдельной машине запускали браузер, в нем js, который постоянно стучался на сервер и получал от него задания (джобы), сам сайт грузился в iframe, а скрипт извне отправлял dom-дерево ифрейма обратно на сервер.

Сейчас появились более продвинутые средства — xulrunner (crowbar) и watir. Первый — безголовый firefox. У crowbar есть даже ff-плагин для визуального выделения нужных данных, который генерит специальный парсер-js-код, однако там не поддерживаются cookies, а допиливать неохота. Watir позиционируется разработчиками как средство отладки, но мы будем его использовать по прямому назначению и в качестве примера вытащим какие-нибудь данные с сайта travelocity.com.