
Всем привет!
Как можно было догадаться из заголовка речь пойдет о парсинге HTML (далее хтмл).

Всем привет!
Как можно было догадаться из заголовка речь пойдет о парсинге HTML (далее хтмл).

Продолжаю свой предыдущий пост. Время сфокусироваться на деталях внутреннего устройства синтаксического анализатора. В качестве языка реализации я выбрал Go, поскольку хотел малой ценой получить параллельный (в смысле, использующий все доступные ядра CPU) производительный инструмент, без погружения в низкоуровневую пучину C++.
Полученный код предоставляет следующий API:
type Attribute struct {
Name string
Value string
}
type ParseMatch struct {
Text string
Nonterminal string
Rule string
Attributes []Attribute
Submatches []ParseMatch
Hypotheses []string
HypothesisCount uint
}
func Parse(text, nonterminal string, hypotheses_limit uint) []ParseMatch
Match ссылается на дочерние объекты того же типа, соотвествующие нетерминалам или лексическим терминалам подошедшего правила. В общем случае, из-за неоднозначности, присущей естественным языкам, тексту соответствует несколько разборов (например, из-за наличия омонимов). Поэтому функция Parse возвращает множество объектов Match. Вышеупомянутая неоднозначность синтаксического разбора должна устраняться на следующем (семантическом) уровне анализа текста.
Итак, функция Parse берёт text — текст для разбора, nonterminal — название нетерминала (например, «sentence»), а также максимальное число выдвигаемых гипотез hypotheses_limit (об этом чуть ниже). Параметр nonterminal может быть пустым. В этом случае тексту будет сопоставляться лексический терминал, найденный в морфологической базе.
В терминах данного анализатора гипотеза — это предположение того, что нарушенное ограничение значения атрибута вызвано случайной причиной. Если анализатор встречает несоответствие значения атрибута ограничению, заданному рассматриваемым в данный момент правилом, а число выдвинутых гипотез не достигло hypotheses_limit, то данное несоответствие игнорируется. В противном случае рассматриваемое правило отбрасывается. Данный механизм удобен для отладки правил, но должен избегаться в реальной работе, поскольку чудовищно замедляет процесс разбора.
Читать полностью »
Недавно возникла задача массовой рассылки писем, текст которых формируется на основе шаблона, в котором помимо статического содержимого есть информация о получателе и фрагменты текста. В моем случае это шаблон автоматического оповещения подписчиков о публикации новых статей, соответственно в нем есть обращение к адресату и красиво оформленная ссылка на публикацию.
Сразу возник вопрос — как это реализовать? На ум приходили различные решения, начиная от задания в шаблоне неких константных значений, которые бы заменялись на данные модели, и заканчивая полноценными вьюхами Razor (сайт построен на MVC 5).
После непродолжительной битвы с самим собой, я пришел к выводу, что эту достаточно распространенную задачу пора решить раз и навсегда, и что ее решение должно быть не очень сложным (т.е. не должно зависеть от библиотек, не входящих в состав .NET Framework 4), но при этом достаточно функциональным, чтобы решать поставленную задачу и иметь запас по расширяемости.
В данной статье я расскажу о решении на основе генератора байт-кода, которое удовлетворяет этим требованиям, а также прокомментирую наиболее интересные фрагменты кода.
Если вас интересует только шаблонизатор, ссылочки ниже:
Исходные коды шаблонизатора (Genesis.Patternizer) и тестовой консоли в проекте на SourceForge: https://sourceforge.net/projects/open-genesis/?source=navbar
Или в архиве одним файлом: Patternizer.zip
В повседневной работе постоянно сталкиваюсь с разработкой приложений использующих REST сервисы. Существующие библиотеки помогающие в построении запросов и их обработку не слишком меня устраивали по ряду причин. Возникла мысль о создании простого инструмента наподобие Universal Image Loader позволяющего быстро строить запросы и парсить полученные данные. В результате появился Android Data Processor
Процессор данных предназначен для выполнения REST запросов к сервисам или локально к файлам.
Запросы могут выполнятьс синхронно или асинхронно. Процессор не содержит парсеров. Для обработки результатов вы используете свои любимые парсеры данных и передаете им полученные данные в виде InputStream, String, JSONObject.
Читать полностью »
Раньше основной библиотекой для парсинга был JSDOM, который страдал излишней тяжеловесностью и на самом деле тормозил скорее процесс парсинга. Но время изменились и пришел cheerio. Он делает почти все то же самое, и отбрасывает лишние из процесса, при этом сам реализует какую-то часть jQuery(а именно ту, которая нам нужна для парсинга). И за счет этого позволяет наконец написать не тормозящий парсер, при этом не используя regexp'ы ради увеличения производительности. Он справляется и с xml, только нужно вызвать его с {xmlMode: true}. О том как можно легко парсить на nodeJS под катом.
Читать полностью »
Если ты меня вообще помнишь, читатель — то, наверняка, помнишь и то, что мои посты в подавляющем количестве случаев разочарующе длинны и довольно-таки часто им предшествует лирическая предыстория. Заверяю тебя, этот пост отнюдь не исключение — я настолько же надёжный графоман, как и ранее, а то ещё и более закалённый.
По сходным обстоятельствам, мало что из описанного в тех постах было доведено до ума и они, преимущественно, содержали лишь общие предпосылки к размышлениям. И по этому пункту я так же не менее верен тебе и сейчас, дорогой читатель.
Как и раньше, в посте будет множество гиперссылок и кода. А ещё больше — кириллических букв.
Всё как в старые добрые времена. Добро пожаловать, друг.
На днях закрыли очередной проект. Суть: создание новой версии интернет-каталога. Старая версия сайта, в силу ряда причин, клиента не устраивала. Особенностью проекта была его номенклатурная база. Объём номенклатуры каталога составлял ~26000 позиций раскиданных по дереву из 513 узлов + характеристики товара. Почти каждая номенклатурная позиция имела описание на 1-2К текста.
Файл выгрузки каталога в формате ComerceML 2 для старого сайта весил 104 MB. Формировался на стороне 1С 10 минут и после передачи на хостинг, парсился на стороне сайта полтора часа (!) со 100% загрузкой CPU.
Читать полностью »
Вы когда-нибудь задумывались о том, как расширить ядро PHP? Что нужно для того, чтобы создать новое ключевое слово или даже разработать новый синтаксис? Если у вас есть есть базовые знания языка C, то проблем с созданием небольших изменений возникнуть не должно. Да, я понимаю, что это может быть немного бессмысленно, но неважно — забавно ведь.
Давайте создадим альтернативный способ определения класса. Самый простой способ определения, разрешённый в PHP, выглядит следующим образом:
<?php
class ClassName {}
Мы можем упростить синтаксис и заменить фигурные скобки на точку с запятой.
<?php
class ClassName;
Если вы попытаетесь выполнить этот код, то он, очевидно, выдаст ошибку. Не проблема, мы можем это исправить.
Читать полностью »
Добрый день, уважаемыее. В данном посте речь пойдет о совместном проекте S. C. Chen и John Schlick под названием PHP Simple HTML DOM Parser (ссылки на sourceforge).
Идея данного проекта — создать инструмент позволяющий работать с html кодом используя jQuery подобные селекторы. Оригинальная идея принадлежит Jose Solorzano's и реализована для php четвертой версии. Данный же проект является более усовершенствованной версией базирующейся на php5+.
В обзоре будут представлены краткие выдержки из официального мануала, а так же пример реализации парсера для twitter. Справедливости ради, следует указать, что похожий пост уже присутствует на habrahabr, но на мой взгляд содержит слишком малое количество информации. Кого заинтересовала данная тема, добро пожаловать под кат.
Читать полностью »
В рамках создания фреймворка для некоторой системы Enterprise класса, у меня стояла задача создания утилиты для автоматизированной генерации кода по UML модели. Ничего наиболее подходящего для быстрого и эффективного решения задачи, кроме как использование Ruby, и встроенного шаблонизатора ERB, под руку не подвернулось.
Файл проекта из среды UML моделирования представлял собой базу данных формата SQLite3, однако некоторую часть информации в этой БД среда хранила в виде сериализованных в BLOB поля объектов. Формат сериализации был текстовый, но не совместимый ни с одним из известных, такими как XML, YAML, совсем отдаленно напоминал JSON. Использовать существующие в природе парсеры было невозможно.
В простых случаях, когда вам не требуется весь объект целиком, а только пара скалярных полей конкретной инстанции, то конечно можно тупо добраться до нужного регулярками. В противном случае, есть универсальное решение проблемы, позволяющее быстро создавать собственные парсеры для подобных структур, десериализующие их в объекты Ruby.
Читать полностью »