Появилась идея сделать механизм, автоматизирующий вытаскивание полезной информации из html. Скажем, имеем мы в описании справочника очень похожие структуры данных вида



Есть задача вытащить всю полезную информацию, по ходу игнорируя лишние пробелы и переносы. Превратить всё в упорядоченный поток вида

чтобы по нему затем восстановить html. Видно, что  требуются включения рег.выр. и участков кода, зависящие от конкретного списка.  Что-то подобное делается в XSLT, только не кодирование из HTML. Получился бы удобный кодировщик регулярных страниц. Идеально было бы записывать эти преобразования как обратимые.

есть объекты FSO и др. с ними можно генерить новую страницу через JS. 

тебе нужно проходить по дереву, "правильно" собирать innerText каждого тэга.
а свойства тэга можно получить for in.

а в чем, собственно, сложности?

регулярные выражения могут даже не понадобиться.
если хочешь делать без Delphi и др., то простой и удобный вариант на HTA. 
но опять же, ты встретишься с утечкой памяти и косяками JS

FSO не надо, потому что часть декодирования должна работать везде, как обычный компонент скрипта.

Вопрос в том, чтобы наглядно описывать выбрасываемые части страницы и сделать достаточно общее решение, чтобы встраивать его.

Кодирующую часть делать всё равно на чём, но лучше на кросссистемных скриптах. JS вполне способен это осилить.

Важно, чтобы потом поменьше программировать. Может, пойти от конца - создания шаблона? Берём образец страницы, заменяем в ней поля переменных на вставки переменных типа <...> или <span class=...>, вставляем учитываем возможность пробелов и переносов где угодно - и вперёд.

хорошо, можно образец сунуть в переменную и использовать в скрипте. понятно.
я думаю, что стоит определиться с форматом шаблона для облегчения поиска с использованием RegExp. 

!TAGNAME! [ 
attr = ... ;
...

]

но тут возникает вопрос: полезная информация - эта та информация, без использования лишних тэгов и атрибутов типа STYLE?

имеет ли смысл придумывать новый формат для последующего создания той же страницы только без мусора?

а говоря о кроссбраузерности, то мне кажется, что лучшим решением будет 
генерить сценарий, содержащий в себе массив, состоящий из дочерних массивов.

var IMG = [["SRC","значение"],["ALIGN", "top"] ];

очень легко оттуда извлекать информацию и записывать.

Да, это вся сухая информация без украшений и тегов, которую потом в новой генерации страницы оформим по-своему. Это автоматизированный извлекатель информации с группы похожих страниц или из одной большой с повторяющимися элементами.

К массиву я тоже прихожу, но ещё более эффективно хранить в строке или столбике, где переносы строк вместо запятых, а кавычки отсутствуют. Потом её легко переводим в многомерный массив.

12345c, не понял в чём вопрос...
Собрать документ по шаблону с файла что ты привёл есть дело 10 минут кодинга на PHP. Обраное преобразование (с целого документа в инфу) потребуеться знание шаблона, что тоже просто если перед парсингом шаблон известен. Другой вопрос: а нафига? ты .htm документы справочника в что то другое конвертишь или индексы делаешь?

Вопроса насущного нет, есть желание выработать методы, алгоритмы преобразований и достаточно наглядное представление шаблонов. Чтобы не кодировать каждый раз заново, а пользоваться методами.

Обратная задача (извлечение инф-ы из разметки) нужна, чтобы доставать инф-у из разных htm-страниц, утяжелённая вольностью ручной кодировки этих страниц разными авторами и верстальщиками. Тоже нужен набор методов, чтобы применять при таком подходе, для автоматизации процесса и для перевода информации в своё представление, со своей разметкой.

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

Вчера, например, по задаче синтеза html придумал такую вещь, как встраивание кода в шаблон, чтобы потом его исполнять в циклах по eval().

Ну было дело, по шаблону генерить страницу: http://forum.vingrad.ru/index.php?showtopic=34621

А вот анализ страницы, это уже другое. Если структуру мы вообще не знаем, то приплываем к классическому вопросу "что было раньше курица или яйцо?"   Анализируя страницу тебе нужна конкретная инфа, а не то что анализатор сумеет "выделить". Например поисковик будет выдлелять крупный текст, в странице, тем самым менюшки и прочее не индексируеться. Крупный текст всегда поделен на блоки (параграфы), в которых присутствует только inline разметка. Если у тебя есть справочник, то ты должен задать его структуру, что бы выделить то, что ты хочешь, иначе задача выруливет в область фантастики с настоящим ИИ, который знает твои увлечения, психотип и т.д. что бы "выделить" нужную инфу 


И что это получилось? Браузер сам может без всяких eval выполнить код в странице, зачем каким то путём доставать верстку со скриптами в переменную, из которой затем вырезать скрипты и выполнять как в шаблонизаторе? В prototype.js есть такая фича, но не врубаюсь где можно это заюзать (мой разум свободен от каких либо паттернов мышления, я сейчас вижу как минимум 2 более красивых решения для подобного функционала, а если задача станет точней, то и решения будут лучше). Не, ну конечно нет предела изврату... 

Резюмирую: какова задача? Я пока вижу три направления:

• анализатор по шаблону - находит в документе с точно известной структурой (вариации структуры в пределах "допустимого") инфу, например из справочника выделяет куски кода помеченные как "пример".
• анализатор по задаче - достаточно сложная вещь, как например чистилка баннеров. По разным признакам пытаеться угадать контент и придать ему необходимый вид, например файрвол может вырезать рекламу и баннеры. Тут эвристика, обучение и все дела возможны.
• супер разум - ему не нужно ничего обьяснять (иначе он попадает под анализатор по задаче), он сам знает, что тебе нужно, прежде чем ты сам осознал, что же тебе нужно   Пока даже "на бумаге" не возможно.

Говори конкретней.

довольно странно... если мы видим банеры, то работаем с IMG или IFRAME. а так вся разборка текста идет по P, DIV, SPAN, ну списки и прочее в том же духе. и то SPAN нужен, в принципе, только для указания стиля. DIV тоже спорный вариант - украшательства через прямоугольники... 
тогда это все наводит на мысль: причем тут "супер разум"?

по-моему цель должна сводится к выделению контента без банеров, где текст классически состоит из P, BR, SPAN, A, списков, элементов управления.. 

по-моему красота проги будет в разграничении HTML, CSS, JSCRIPT..
управление отображением содержимого - через CLASS.

новый формат не нужен...
нужно просто очистить контент от изображений маленького размера, ссылающихся на другой хост, убрать украшательства и поставить вместо них CLASS в тэге STYLE и присодинять события по ONLOAD в отдельном скрипте.

говоря о сказанном выше, красота декодирования не нужна особенно в JSCRIPT .. мы сразу сформируем основу. от нее отталкиваемся и меняем стиль содержимого через CSS. даже массив со своей многомерностью не нужен.

если я прав, то деятельность сведется лишь к кодированию на JSCRIPT нового контента без вольностей опять же через FSO и вообще HTA.

Это сообщение отредактировал(а) JSman - 25.8.2006, 00:17

Он может ответить на вопрос: что тебе нужно 
Если мне нужна инфа, то я примерно понимаю как выглядит эта инфа, следовательно пишеться по быстрому анализатор первого типа, либо в редких случаях анализатор второго типа. Повторяю: ты знаешь какую инфу ты хочешь получить и как её достать, ты не отдаёшь "выделение" на откуп софту.


К сожалению не всё в вебе оформлено в виде офисных документов, чаще свёрстано на таблицах с жуткими заморочками. Поисковики ориентируються на количество текста для индексации. Ещё картинки ассоциируються с рядом стоящим текстом, так ты можешь "искать картинки".



Это простой анализатор, в DOM дереве всё раздельно. А вот написать конвертор любой кривой вёрстки в красивую структуру со стилями, да так что визуально во всех браузерах будет одинакого и не отличаться от оригинала... не, памятник при жизни точно народ поставит   Потребуеться рендерить страницу, затем упростить вёрстку применяя фиксированный (в смысле не самообучамый) набор правил по удалению лажи (tidy), после полученное DOM дерево со стилями в файл. Можно даже в XSL-FO, и далее в PDF/DjVu - тогда точно "везде одинакого выглядеть будет". А вот под браузерами с их глюками и особенностями без извратов не возможно.
Нафлеймил   



Подробней на этом моменте, как "сразу сформируем основу"? Возьми страницу yandex.ru к примеру, убедись что там масса мелких картинок, баннерами не являющиеся. Можно посмотреть исходники adblock под лису, они открыты, алгоритм бывает лажает но не часто.

Но! из общего абстрактного анализатора контента предложенного 12345c ты сейчас предлагаешь делать банерорезалку  

итак, я предлагаю сделать на первом этапе "банерорезалку" и то, что разграничит контент в страниц е на JSCRIPT, CSS, HTML. а потом будем бороться с "неправильной" версткой. 

Добавлено @ 02:14 
1й этап - разграничение на 3 логических части.
2й этап - нахождение одинаковых стилей для разных тэгов (например отступы параграфа)
3й этап - поиск альтернативы последовательности тэгов.

Добавлено @ 02:24 
дополнения

между 1м и 2м этапом: "банерорезалка".
по 2му этапу: будем создавать классы и вписывать общие inline-стили. 


а location.href включает .yandex


- это этап №1



на TABLE как я понял, чтобы не спутал с CSS   - этап №3 - борьба с бессмысленной последовательностью

тэгов

Добавлено @ 02:28 
блин, ну если реально сделать эту штуку, то ващще будет

Добавлено @ 02:32 
ребят, я советую сделать на HTML, а не PDF и тд - помучаемся, зато итог классный:

мало весит, код красивый - ай, сказка  

и JSCRIPT впихнем в реализацию кодирования

Сейчас придёт 12345c и будет нас матом крыть за испохабленную идею 

Во вторых, форум != чат, пиши в одном посте 


Вижу ты мало верстал. Можно написать рендер страницы, не графический естественно, мне на первый взгляд на Java уйдёт от силы 2 месяца (для JS можно Rhino прикрутить + стандартные браузерные обьекты). Рендер будет "рисовать" вёрстку в нечто промежуточное со стилями, как это делает браузер. Фактически <p>, <i> и прочие элементы это всё один элемент с разными стилями "по умолчанию".
НО! возникнут проблемы:

• браузеры глючны по определению, вёрстка всё равно будет смотреться криво и по разному в разных бродилках, потому и пользуем извраты.
• 70% JS скриптоделов "знают" JS из пары учебников "за 24 часа", потому скрипты завязанны на конкретной вёрстке, а она то изменяеться.
• проблема филосовского характера - кому это будет нужно? 

В PDF хорошо тем, что рендерит с well-defined XSL-FO, всегда можно тыкнуть пальцем и сказать "ламо написали глюкавый рендер", в отличии от браузеров, которые рождены много раньше чем стандарты которые они должны поддерживать. Конечно результаты представляют чисто научный интерес, ибо в жизни ты с этими PDF'ками... хотя из XSL-FO легко HTML+CSS генерить.


Долго думал... собери мысль по новой 

кстати, он кажется забил уже на нее ))))) не видно его!



нечаянно! просто ночью мысль в голове била!



согласен, но она прикрепляется через атрибуты-события ( ONCLICK="...") - можно присоединить ID и сделать по загрузке attachEvent/addListener либо просто присвоить событию функцию напрямую. проблем нет!

дизайн дизайном, верстка - нечто отдельное. 


ну не скажи.. вот недавно я пришел на фирму, меня попросили переверстать страницы сделанные на frontpage (сколько мусора было! ужас!)! вот эта программа бы понадобилась. а так вручную минут 5 потратил! 12345c тоже хочет.
. 

ну шо вы такое говорите. понятное дело, что будем учитывать поддержку различных браузеров.


1й этап предлагаю сделать на JSCRIPT ради приличия хоть... товарищи, форум-то джаваскриптовый!

анализаторы, анализаторы...
графический не нужен. забадаемся, и вообще гибельное дело. разборы на прямоугольники, смотреть что куда сместить.. не стОит.
лучше думать над удалением ненужных стилей, изменении существующих, объединении. 
моя точка зрения состоит в том, что анализатор кода совершенней анализатора графики. 

Я не про привязку по ID. Например сейчас нет в JS нормального XPath (пинать ленивых разработчиков браузера, и совсем презирать ламов из ECMA, не шевеляться), следовательно приходиться перебирать ноды в ручную. Следовательно ожидаешь что какие то ноды существуют и где они находяться. А тут раз разметка поменялась, скрипты слетели. Зри глубже  


Я бы сказал "обьясни это 80% всех верстальщиков", но не смогу, т.к. сам верстаю с извратами. Почему? Потому что сначала верстаешь хорошо по стандартам, а потом подгоняешь напильником под все браузеры, вот тогда она самая серемяжная правда наружу и вылезает   


Тут сложней анализ будет, front page отстойно вещи на абсолютную позицию ставить любит, следовательно нужно как то проецировать на документ и вгонять в поток документа с нормальными стилями. А это очень даже не простая задача...


А иначе как вынести стили? Выкладывай свою идею 


JSman, давай поменьше бравады и больше здравых мыслей, взрослые же люди всё таки