на самом деле сделать визуализацию довольно просто: достатано сделать экспорт результата расчета в формат DOT.
это обычный текстовый файл вида:
strict digraph G { top -> page1; top -> page2; page1 -> page2; page2 -> page3; page3 -> page1; page3 -> top; top [label="top\n1.25"]; page1 [label="page1.html\n0.3"]; page2 [label="page2.html\n0.35"]; page3 [label="page3.html\n0.25"]; }
по структуре файла даже и объяснять нечего. :)
(на цифры не смотреть, это только пример)
дальше файл DOT скармливаем graphviz или чему-то подобному. примеры готовых графов
при желании, можно взять их либы и интегрировать в свой софт... но я предпочитаю раздельное питание :)
ага, они такие...
вот недавно ко мне гугльбот заходил с украиского беспроводного 3g провайдера 😂
ну еще иногда яндекс ходит из германии из дешевого дц во франкфурте :)
все можно, но геморойно, но приходится...
вариант решения без плагинов:
http://get-business-online.com/blog/internet-marketing/word-count-for-firefox/
результат работы в виде:
8 words, 44 characters
поправка:
этот ява-скрипт нужно немного поправить, т.к. он не всегда верно возвращает количество слов, т.к. в качестве разделителя там считается только пробел. если используется табуляция или перевод строки, то ой..
количество символов - возвращает верное. хотя я бы все-таки считал два подряд идущих пробела как один.
поправка2: исправил эти глюки, по верхней ссылке можно не ходить.
порядок установки:
1. жмем на этой странице Ctrl+D или добавляем любую страницу в закладки.
2. идем в редактирование закладки и меняем адрес закладки вида http://.... на код
javascript:d=window.getSelection()+'';d=d.replace(/\s+/g,'%20');d=d.replace(/(^\s+)|(\s+$)/g,%20"");d=(d.length==0)?document.title:d;%20alert(d.split('%20').length+'%20words,%20'+d.length+'%20characters');
это все.
теперь выделяем мышкой текст на странице и клацаем на нашей закладке - получаем результат.
- опцию изменения "количества потоков" и "задержку между запросами" - на лету, т.е. не прерывая текущий парсинг.
смотрим на загрузку сервера, если успевает, то еще добавляем потоков, если нет - плавно уменьшаем.
- птичку "турбо" - т.е. с максимальной скоростью без никаких задержек, даже если ошибки - на лету, т.е. не прерывая текущий парсинг.
при обычном парсинге, например, когда встречаем 503 - перегрузка сервера или 504 - проблемы со связью, timeout и некоторые другие ошибки, то логично и правильно, не тревожа пользователя, автоматически увеличить паузу между запросами: чтобы сервер начал успевать обрабатывать запросы или не так интенсивно долбится при проблемах со связью.
кнопочка "турбо" - отменяет всю эту "интеллектуальность" и шлет запросы не смотря ни на что.
задача - собрать максимально быстро как можно больше страниц. остальные "ошибочные" страницы можно будет собрать "повторным парсингом" в обычном режиме.
еще вспомнилось..
- поддержка в парсере gzip (скорее всего у Вас это уже есть)
- в парсере предусмотреть, в обработке ответа от сервера, проверку "Content-Length" из заголовка(если такое поле есть) с размером реально полученной страницы.
временами некоторые ..бип.. провайдеры пережимают канал или глючат их железки и страницы хтмл не полностью догружаются.
к сожалению, не все сервера возвращают это поле для html :( но хоть для некоторых серверов это будет полезно.
...когда-то, по-быстрому, делал проверку в контенте страницы тега </html> если не найдено, то страница не догружена. это не совсем правильно, но для "по-быстрому" мне помогло :)
т.е. расчет будет запускаться только руками? как для меня, так это самый лучший вариант. :)
небольшие пожелания:
- добавьте, плз, в новый парсер парсинг в несколько потоков.
- опцию изменения "количества потоков" и "задержку между запросами"(можно еще птичку "турбо" - т.е. с максимальной скоростью без никаких задержек, даже если ошибки) - на лету, т.е. не прерывая текущий парсинг.
это будет полезно для парсинга своих больших сайтов. когда есть свой мощный сервер способный обрабатывать много запросов.
сейчас на одном потоке я даже не хочу и начинать..
- возможность после окончания парсинга повторно пройтись только по "ошибочным" страницам, т.е. 500, 502,503, timeout, (еще желательно 401,403,404,301,302 - чтобы можно было исправлять мелочевку без повторного полного парсинга) или показывать для повторного парсинга все коды ошибок кроме 200 OK.
логично будет в менюхе показать "код ошибки" - "количество страниц" и чекбокс для повторного парсинга страниц с именно этим кодом ошибки.
это позволит убрать "шум" связанный с каналами связи или временной недоступностью/перегруженностью сервера плюс значительно ускорит правку мелочевки на больших сайтах.
- наверное еще полезной будет птичка "автоматически расчитать вес после окончания парсинга" - чтобы дать возможность сначала глазами проверить все ли страницы собраны, повторно пройтись по ошибочным страницам и только потом самому руками запустить расчет веса.
програмка - полезная, купил :)
вопрос по лицензии, как я понимаю идет привязка к железу.
вопрос: могу ли я на другом компе только просматривать результат работы linkoscop? только просмотр файлов *.lsp , без граба и расчета веса.
предложения о новых фичах:
- в "общую таблицу" полезно будет добавить столбец "внешних ссылок" - будет удобно по нему сортировать и следить за передозировке исходящими внешними ссылоками
- очень хотелось бы экспорт в формат csv, т.к. не везде есть MS эксель(идем к лицензионности...), а без установленного экселя экспорт в xls не идет.
- очень хотелось бы экспорт, только в csv(с xls не стоит и заморачиваться), всей большой простыни "ссылки и страницы". желательно экспортировать все "как есть" со всеми столбцами и т.д. (csv - обычный текстовик, так что экспортироваться будет быстро и за его большой размер переживать не нужно)
второстепенное, но значительно экономит время и свои глаза:
- можно сверху в "общую таблицу" добавить фильтр страниц (или сделать поиск), чтобы по первым буквам (или по маске) он по урлу искал нужную страницу.
- тоже самое и в "ссылки и страницы" - поиск в верхней табличке по урлу и титлу.
еще вопрос: тег <FORM action=...> считается ссылкой, это правильно? если да, то как правильно закрывать эти ссылки?
для теста набросал сайт из 5 страниц http://live.pl.ua
с главной идет ссылки на 4 страницы, на остальных страницах - ссылок больше нет.
скрипт правильно нашел все страницы, расчитал вес - у всех стринац оказался одинаковый вес - 0,2
это правильно? мне казалось, что у главной должен быть меньший вес.
301 - это уже следствие, а не причина.
где-то в программе вкралась "нормализация" при работе урлами и программа считает, что /about = /about/ и /about/ = /about
отсюда и начинаются глюки. может быть стоит, хотя бы опционально(например сделать опцию Strict Links) дать возможность различать эти урлы.
с главной идет ссылки на 4 страницы, на остальных страницах - ссылок больше нет
текст главной:
<a href="/about">a1</a> - link to /about<br /> <a href="/about/">a2</a> - link to /about/<br /><br /> <a href="/bout/">b2</a> - link to /bout/<br /> <a href="/bout">b1</a> - link to /bout<br />
linkoscop 3.17 (сегодня последний день триала, для продолжения тестов придется купить :) )
нашел 3 страницы
/ /about /bout/
если нужно, то исходник тестового сайта
text<br /> <?php if( preg_match('%bout%i', $_SERVER['REQUEST_URI']) ){ echo "<h2>It's a page '{$_SERVER['REQUEST_URI']}'</h2>"; }else{ echo <<<EOF <a href="/about">a1</a> - link to /about<br /> <a href="/about/">a2</a> - link to /about/<br /><br /> <a href="/bout/">b2</a> - link to /bout/<br /> <a href="/bout">b1</a> - link to /bout<br /> EOF; } ?>
и в .htaccess RewriteRule на этот index.php
ну хотя бы чтобы прикрыть свою задницу, на случай если придет запоздалая абуза и в ДЦ начнется разбор полетов.
страницы без расширений используются и в других CMS.
мне кажется, что корректно будет как ссылка написана, так к ней и обращаться, т.е.
если <a href="/about", то /about
если <a href="/about/", то /about/
попутно программа и выявит некорректность линковки. например этим страдает распространенный плагин wp-pagenavi (последние пару версии не смотрел, т.к. надоело править)
