Blog. Just Blog

Быстрый поиск

Введите фрагмент названия статьи для поиска

"Я знаю AJAX, ЧПУ, CMS и много других страшных слов"

28.03.2009 | Категория: Web-мастеру и не только | Автор: ManHunter
Немного перефразированную шутку из названия я часто вспоминаю, когда посещаю многие сайты, популярные и не очень. Web-мастера, начитавшись умных слов и получив в свое распоряжение готовые CMS сайтов и фреймворки, облегчающие разработку, начинают их активно использовать. И в результате очень часто в жертву приносится такая важная составляющая сайтов, как юзабилити. Если единственное, для чего вам нужен сайт - это завешать его порнушными баннерами и поп-апами в три слоя, разместить стыренный контент исключительно на платных файлообменниках, чтобы любыми средствами срубить бабла, то валите отсюда подальше, мне с такими мразями говорить не о чем. Эта статья для немногочисленных web-мастеров, которые стремятся к тому, чтобы на их сайт посетителям хотелось вернуться, чтобы от результатов их труда все получали только удовольствие. Я никого не хочу ни в чем убеждать, но если кто-нибудь после прочтения задумается, значит моя цель достигнута. Мало знать современные технологии, надо уметь их грамотно применять. Вполне возможно, что какие-то вещи будут для вас очевидными, просто наболело :)

В современном web-строительстве очень популярно использование так называемых ЧПУ - "человекопонятных УРЛ". Это красивые, интуитивно понятные ссылки, формируемые из названия раздела и статьи. Например:

http://www.site.ru/category/subcategory/article_name
При обращении к такой ссылке она разбирается средствами сервера на отдельные параметры и дальше обрабатывается как обычная ссылка. Один из основных принципов формирования ЧПУ заключается в том, что при обрезании ссылки до последнего слеша, посетитель должен попадать на вышестоящий раздел сайта. Это хорошо и правильно, но до тех пор, пока в ссылке не начинает присутствовать дата:

http://www.site.ru/2009/01/25/article_name
По логике вроде бы все правильно: дата добавления статьи, название статьи. При обрезании ссылки до дня получаем все статьи за день, до месяца - за месяц и т.д. Проблема в том, что такая система формирования ссылок хорошо подходит для новостных сайтов, но категорически не годится для основного контента порталов. Информация на новостных сайтах привязана ко дню, когда случилось это событие и после публикации на сайте вряд ли когда изменится. А в популярных портальных движках (названий не указываю, кому надо и так поймет) дата публикации обычно равна дате последнего редактирования статьи, и вот тут начинаются косяки. Реальный случай из жизни: на каком-нибудь сайте выложили какую-то нужную мне информацию. Я зашел на сайт, добавил ссылку в закладки браузера или послал ссылку товарищу в аську. На следующий день пользователь, разместивший статью, отредактировал ее. В результате дата изменилась, ссылка, соответственно, тоже, а сохраненная ранее ссылка становится недействительной. Приходится заново тратить время, искать нужную статью, что никак не добавляет положительного отношения к сайту. Аналогичная ситуация складывается, если идентификация в ЧПУ жестко завязана на полном названии статьи. Удобно? Нет.

Читать статью целиком »
Просмотров: 5104 | Комментариев: 9

Парсер REFERER'ов с поисковых систем

04.02.2009 | Категория: Web-мастеру и не только | Автор: ManHunter
Обработка заголовка HTTP referer является одной из важных задач при раскрутке сайта и сборе статистики. По нему можно определить, какие ресурсы ссылаются на ваш сайт. Но особую ценность представляют данные посещений с поисковых систем, так как эта информация позволяет наиболее четко определить, по каким ключевым словам ваш сайт может быть найден, а также проанализировать эффективность поисковой оптимизации вашего ресурса. Если вы пользуетесь сторонними счетчиками посещений, то эту информацию они обычно предоставляют сами. В некоторых случаях такие данные предоставляют серверные системы статистики типа Webalizer. Я принципиально не пользуюсь ни тем, ни другим, обрабатываю все данные самостоятельно. Для этого была написана функция обработки рефереров, которую я использую в своих проектах. Данные поискового запроса обычно передаются методом GET и содержатся в строке браузера, но основная проблема в том, что кодировка этих данных может быть разной даже в пределах одной и той же поисковой системы. Как выяснилось, не везде доступна штатная функция PHP is_unicode(), поэтому для подстраховки пришлось написать свою. Проверка выполняется согласно правилам формирования Юникода.
  1. // Функция проверки является ли переменная строкой в Юникоде 
  2. // Если штатная функция не определена, то применить нашу
  3. if (!function_exists('is_unicode')) {
  4.   function is_unicode($str) {
  5.     for ($i=0$i<strlen($str); $i++) {
  6.       // Если символ с кодом больше 191, то возможно это юникод
  7.       if (ord($str[$i])>191) {
  8.         // Следующий символ должен быть в интервале
  9.         // 10000000b ... 10111111b (128...191)
  10.         if (ord($str[($i+1)])<128 || ord($str[($i+1)])>191) {
  11.           // Условие не выполнено, значит это не юникод
  12.           return false;
  13.         }
  14.         else {
  15.           // Пропускаем один байт, т.к. он является частью символа
  16.           $i++;
  17.         }
  18.       }
  19.     }
  20.     // Проверка пройдена, это юникод
  21.     return true;
  22.   }
  23. }
Теперь, когда мы можем четко определить кодировку строки запроса, нам необходимо выделить ее из строки URL. Для этого достаточно выполнить в интересуемом поисковике любой запрос и посмотреть как формируется ссылка.

Читать статью целиком »
Просмотров: 15577 | Комментариев: 27

01 02 03 next
Наверх
Powered by PCL's Speckled Band Engine 0.2 RC3
© ManHunter / PCL, 2008-2019
При использовании материалов ссылка на сайт обязательна
Время генерации: 0.27 сек. / MySQL: 3 (0.0565 сек.) / Память: 4.75 Mb
Наверх