Этапы большого пути

Рано или поздно каждому веб-мастеру приходит в голову идея улучшить свой сайт. И хорошо, если эти изменения касаются только «косметики» — изменения цвета, текста, добавления картинки или еще одной странички. Но значительно чаще хочется добавить какую-то новую функциональность — счетчик, настройку «под пользователя» или еще что-то подобное. И тут, увы, вполне может оказаться, что хостер не поддерживает требуемые функции. Поэтому сегодня мы попробуем обсудить различные технологии, применяемые при строительстве веб-сайтов, и понять, для чего они могут потребоваться.

Самый простой вид сайта — это набор статичных HTML-страниц. Его поддерживают все хостеры, и каких-либо сложностей при работе с таким сайтом не наблюдается. Единственное, на что стоит обратить внимание — это на то, в какой кодировке выкладываются страницы — чаще всего это будет KOI8-R или Windows-1251. Если вы создаете страницы на своей домашней Windows-машине, а хостер требует их выкладывать в KOI8-R, то не забудьте их перекодировать, иначе ваши посетители, вместо тщательно вами подготовленного рассказа о коте Мурзике, увидят непонятные каракули.

Через некоторое время возникает идея, например, убрать меню с окна браузера при открытии страницы, вывести текущее время или сделать еще что-нибудь похожее. Для подобных «невинных шалостей» вам понадобится скриптовый язык — например, JavaScript или VBScript. Скрипты, написанные на этих языках, никак не связаны с хостингом — они выполняются на компьютере клиента, и единственная проблема, с которой вы можете столкнуться — это посетитель со старым браузером, не поддерживающим скрипты. Или же неправильно с ними работающим…

Кстати, в эту же категорию можно отнести и флэш-ролики: их воспроизведение тоже от хостера не зависит, так что если вы чувствуете в себе таланты аниматора, то можете начинать создавать свои мультфильмы, не боясь, что гадкий хостер будет драть с вас три шкуры за их распространение…

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

Тут вам на помощь придет SSI (Server Side Include) — специальные указания серверу, что в таком-то месте страницы он должен вставить другой файл. Теперь вы можете создать один файл с «шапкой», а во всех страницах просто указать, что «сюда надо вставить такой-то файл», и, как только вы обновите «шапку», эти изменения сразу же станут видны на всех страницах. Не все хостеры поддерживают SSI — дело в том, что эта функция дает дополнительную нагрузку на сервер (ему приходится читать и анализировать все запрашиваемые страницы); кроме того, там могут быть и другие ограничения: хостер может поддерживать SSI только для каких-то определенных расширений файлов (чаще всего .shtml), может разрешать или запрещать вложенный include (когда подключаемый файл тоже должен подключить какой-то другой файл) и т.п. Все это надо узнавать у хостера перед тем, как готовить сайт с использованием SSI. Кстати, SSI не ограничивается только включением каких-то файлов — возможности этой технологии несколько шире, но include является, пожалуй, наиболее важной и часто используемой директивой.

Но, как известно, нет предела совершенству, и довольно скоро вы выясните, что простого включения файлов в статичные страницы вам уже не хватает. Хочется сделать так, чтобы пользователи регистрировались на сервере, хочется добавить поиск, форумы, дать пользователю возможность выбирать нужные данные… Все это потребует скриптов. Но кардинальное отличие этих скриптов от, например, JavaScript заключается в том, что выполняться они должны на сервере, а не на компьютере клиента. Такие скрипты называются CGI (Common Gateway Interface), и они могут писаться на разных языках (самыми популярными являются PHP и Perl). Поддержка скриптов, ограничения по их использованию и допустимые языки программирования полностью зависят от хостера. На бесплатном хостинге скрипты чаще всего запрещены полностью, а на платном обычно есть ограничения по суммарному времени выполнения скриптов и по загрузке процессора. Кроме того, многие хостеры не разрешают вам выкладывать свои скрипты напрямую, а требуют, чтобы сначала вы их переслали в администратору сервера для проверки.

CGI-скрипты по сути являются программами, которые что-то там делают на сервере, а потом выводят HTML-код страницы, которую, в свою очередь, веб-сервер передает посетителю. При этом никто не заставляет вас писать именно скрипты (которые создаются в виде исходного кода и при вызове специальной программой-интерпретатором «переводятся» в нолики и единицы, понятные компьютеру) — если вы знаете, например, язык C, то вполне можете написать CGI на нем и затем вызывать откомпилированную программу. Но скрипты писать намного проще, поэтому в 99% случаев используются именно они.

Кстати, вы можете объединить SSI и CGI, то есть включать в написанную страницу текст, который генерируется скриптом. Для этого вам не надо делать ничего сложного — просто в качестве ссылки для включения файла указать свой CGI-скрипт (есть еще директива EXEC, но хостеры ее обычно блокируют).

Теперь у вас есть динамический сайт, который вполне успешно манипулирует разными данными, выдает пользователю информацию в соответствии с его запросами и настройками, создает для вас отчеты о посетителях и делает всякие другие полезные вещи. Но вот беда — довольно быстро обнаруживается, что выборки данных и их сортировку выполнять достаточно неудобно, а при наплывах посетителей эти операции вдобавок занимают кучу времени… И тут возникает идея использовать базу данных. Правда, у тех, кто с базами не работал, эта идея долго загоняется в дальний угол подсознания, поскольку они считают, что дело это исключительно сложное и непонятное…

На самом деле, если вы уже используете CGI на своем сервере, а хостер предоставляет доступ к базе, то никаких (почти) сложностей при ее использовании не возникает, а вот удобств она приносит массу. Все, что от вас потребуется — это изучить SQL (а его основы учатся за час) и посмотреть функции, работающие с базой в том языке, на котором вы пишете свои скрипты. По большому счету, вся работа строится по очень простому алгоритму: подключился к базе, отправил SQL-запрос, прочитал ответ, выдал данные пользователю и отключился.

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

Следующая безумная мысль, которая приходит в голову, это начать отдавать файлы по FTP, организовать real-audio или видео-вещание, организовать рассылку новостей своим подписчикам и т.д. и т.п. Для всех этих действий (за исключением рассылки) требуется, чтобы у хостера были установлены соответствующие серверы. С рассылками проще — доступ к Sendmail’у предоставляют все хостеры, но тут очень много своих «подводных камней», так что, наверное, более разумной альтернативой будет использование какой-то службы, специализирующейся на этом сервисе, например, Subscribe.ru.

И теперь, когда на вашей ново
й и динамической домашней страничке все скрипты написаны исключительно на языке C — для пущей скорости, — фотографии вашей поездки в деревню Гадюкино затолканы в базу, а крики вашего попугая тщательно цифруются и доступны для прослушивания, вас огорчает только одно — цифры на счетчике посещений упорно колеблются где-то в районе нуля. Но это — тема для отдельного материала.