Возникла идея принципиально нового способа ввода данных в устройства с сенсорным экраном, которая сочетала бы в себе достоинства экранной клавиатуры, T9 и Swype. Идея такая: пользователь набирает слово целиком непрерывным движением пальца, но при этом на экране отображается не вся клавиатура в целом (как в Swype), а только те буквы, у которых наиболее высокая вероятность оказаться следующими, и вариант "Еще" для случая, когда ни одна из предложенных букв не подходит. Кроме того, для ввода используется поверхность экрана целиком, а кнопки ввода рисуются полупрозрачными, чтобы сквозь них было видно введенный текст.

Рассмотрим процесс ввода данных по шагам.

Шаг 0. После переключения в режим ввода на экране появляются круглые кнопки с буквами, с которых в языке начинается больше всего слов, и кнопка с вариантом "Еще!", выделенная, например, цветом. Количество кнопок выбирается так, чтобы их можно было разместить по окружности вокруг центра экрана и при этом оставалось достаточно места, чтобы при необходимости легко можно было провести палец между ними. (Число с учетом кнопки "Еще" должно быть нечетным, скорее всего, наиболее распространенными вариантами будут 5, 7 и 9 кнопок в зависимости от размера экрана.) В углах экрана могут размещаться треугольные кнопки для служебных действий, например, переключение регистра, смена языка ввода, переключение в режим обычной клавиатуры, завершение ввода.

Шаг 1. Если буква, с которой начинается желаемое слово, есть на экране, нажимаем на нее и переходим к шагу 2. Иначе жмем "Еще" и переходим к шагу 4.

Шаг 2. Выбранная буква считается введенной. Кнопка с ней отъезжает в дальний угол экрана (так, чтобы остальные кнопки, которые были видны на шаге 1, оказались за его пределами) и становится перечеркнутой. В центре снова появляется кольцо из кнопок с буквами, причем кольцо по сравнению с предыдущим повернуто на определенный угол так, чтобы палец пользователя оказался между новыми кнопками, а не на одной из них. Кроме того, на этот раз предлагаются те буквы, которые статистически чаще всего встречаются после введенной, причем чем больше вероятность буквы оказаться следующей, тем ближе она оказывается к пальцу пользователя. В оставшихся трех углах экрана могут появляться варианты завершения слова целиком, если системе удалось его распознать.

Далее возможны варианты:
а) Хотим ввести следующую букву, перемещаем палец на нее без отрыва от экрана, и далее шаг 2 повторяется уже для третьей буквы.
б) Нужной буквы нет, выбираем вариат "Еще" и переходим к шагу 4.
в) На предыдущем шаге ошиблись и хотим стереть введенную букву, тогда перемещаем палец в тот дальний угол, где она нарисована с перечеркиванием, после чего происходит возврат к предыдущему шагу (при этом круг с буквами предыдущего шага как бы "въезжает" из-за края экрана).
г) Если система предложила то слово, которое мы хотим ввести, в одном из углов экрана, то ведем палец туда.
д) Если ввели (или выбрали из предложенных вариантов завершения) слово целиком, переходим к шагу 3.

Шаг 3. После того, как введено слово целиком, отрываем палец от экрана, после чего на экране появляется круг  с кнопками знаков препинания и пробелом, где выбираем нужный однократным нажатием. После этого возвращаемся к шагу 0 и вводим следующее слово.

Шаг 4. После нажатия кнопки "Еще" она отъезжает в дальний угол и становится перечеркнутой (как в шаге 1, но при этом никакой символ не считается введенным), и появляется новый круг из букв,  у которых вероятность оказаться на данной позиции меньше, чем у предыдущих, а так же еще одна кнопка "Еще", по которой будет новый набор букв с еще меньшей вероятностью (и так пока не переберем весь алфавит). Если вариант "Еще" выбран по ошибке, то возвращаемся по перечеркнуой кнопке в углу аналогично шагу 2в.

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

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

На рисунке ниже показан пример ввода текста "Привет, мир!". Ярко-красным обозначен жест пользователя на данном этапе, более темным -- предыдущие жесты. Примечание: поскольку это пример, буквы выбраны без серьезного статистического исследования.

Недавно нашел способ, как с этим бороться: после сканирования в greyscale нужно сильно повысить контрастность изображения, либо в программе sane, либо после сканирования в каком-нибудь графическом редакторе, а так же выставить небольшую гамма-коррекцию. В частности, я использовал такие параметры: в sane гамма 1.30, затем открывал изображение в GIMP и выставлял там контрастность на +30—+50. В результате получалось качественное изображение с чисто белым фоном и гладкими линиями.

Сразу возникает мысль: а что если как-то определить, как подключен пользователь, и включать сжатие только в тех случаях, если соединение медленное. Измерить скорость подключения пользователя средствами PHP — задача непростая. Но есть и другой вариант: большинство провайдеров сейчас присваивает пользователям через обратный DNS имя хоста, в котором указан тип подключения. Например, broadband-*.nationalcablenetworks.ru или dialup-*.mtu-net.ru.

В PHP это имя хоста можо получить из переменной $_SERVER['REMOTE_HOST'] (для этого нужно, чтобы в настройках Web-сервера было включено определение обратного DNS, в Apache это делается директивой HostnameLookups On). Далее можно просто проверить наличие строк gprs и dialup в имени хоста и включить сжатие при их наличии. Вот пример функции, которая реализует такую проверку:

$userhost = $_SERVER['REMOTE_HOST'];
if (strpos($userhost,'dialup')!==false || strpos($userhost,'gprs')!==false) ob_start('ob_gzhandler');
else ob_start(); 

Конечно, этот вариант тоже не лишен недостатков: во-первых, он не является полностью надежным, а во-вторых, определение обратного DNS тоже создает небольшую дополнительную нагрузку на сервер, но все же он является более гибким решением, чем принудительное включение или выключение сжатия. Аналогичную проверку можно так же использовать при написании правил для mod_rewrite, для выбора, какой файл JavaScript отдать пользователю: упакованный средствами самого JavaScript (но из-за этого требующий больше времени на исполнение) или просто минифицированный.

session_name('MySessId'); // задаем имя cookie или параметра, в котором хранится идентификатор сессии
session_set_cookies_params(24*3600,'/','xpro.su'); //если нужно, задаем домен, путь и время хранения для cookie сессии
session_start(); // а теперь запускаем саму сессию

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

Чтобы разобраться, почему такое происходит, рассмотрим, как же работают сессии в PHP. При вызове session_start  в самый первый раз генерируется ее идентификатор сессии, который передается пользователю либо в виде cookie, либо в виде параметра URL, который добавляется ко всем локальным ссылкам на странице, выдаваемой пользователю. На сервере же создается файл, имя которого совпадает с этим идентификатором. В конце выполнения скрипта (или при вызове session_write_close()) данные, помещенные в $_SESSION, сериализуются и записываются в этот файл. Когда пользователь следующий раз обращается к скрипту, то от него либо в cookies, либо в параметрах запроса передается идентификатор сессии (в приведенном выше примере этот параметр будет называться MySessId), проверяется, существует ли файл сессии с таким именем, и если да, происходит его блокировка, считывание и десериализация, после чего данные, сохраненные при прошлом вызове, снова попадают в $_SESSION.

Поисковые роботы при индексации сайта не сохраняют установленные сайтом cookies или параметры с идентификатором сессии. В результате каждое обращение поискового робота к любой странице сайта будет приводить к создании новой сессии с новым идентификатором. То есть, если сайт содержит десять тысяч страниц, то будет создано десять тысяч файлов сессий! В результате даже простое открытие файла из каталога с таким количеством файлом становится весьма и весьма медленной операцией. Если проект работает на отдельном сервере, частично эту проблему можно решить, задав в настройках PHP хранение сессий не в файлах, а в СУБД или shared memory, но все равно нагрузка будет достаточно существенная из-за операций блокировки и сериализации. Также если разрешена передача идентификатора сессии через GET-запрос, поисковые системы запоминают URL с этим параметром, что тоже создает определенные проблемы (хотя Яндекс и Google вроде бы сейчас научились обнаруживать и отбрасывать идентификатор).

Но всегда ли нужно создавать сессию прямо при первом же обращении пользователя к странице? Для большинства проектов это не так. Например, на форуме необходимость сессии возникает тогда, когда пользователь решает войти под своим именем, а в Интернет-магазине  — при добавлении товара в корзину. До этого для показа тем в гостевом режиме или описаний товаров сессия совершено не требуется. Отсюда вывод: сессию пользователя нужно создавать только тогда, когда в ней возникает реальная необходимость. Но с другой стороны, если пользователь вошел на сайт или добавил что-то в корзину, то нужно на каждой странице показывать ему, что форум его узнал или что в корзине у него что-то есть. Таким образом алгоритм действий получается такой: не создаем сессию, пока она нам не потребовалась, но если уж создали, то возобновляем ее (т.е. читаем ее данные в $_SESSION) при каждом обращении к скрипту. Для его реализации подойдет следующая функция:

function session($force=false) {
 $s_name='MySessId'; // имя сессии
 static $started;
 session_name($s_name);
 session_set_cookie_params(24*60*60,'/','xpro.su'); // параметры cookies
/* Если от пользователя пришел параметр или cookie с идентификатором  сессии, значит, сессию уже создали и нужно ее возобновить, если же  $force==true, то это явное указание на необходимость создания сессии */
 if (isset($_REQUEST[$s_name]) || isset($_COOKIE[$_name])  || $force) { 
/* Переменная $started нужна для избежания повторого вызова session_start (например, если добавляем в корзину еще один товар при уже созданной сессии), чтобы не генерировалось лишнее предупреждение. */
   if (!$started) { session_start(); $started=1; } 
 }
}

В скрипте эту функцию нужно вызывать дважды: с параметром false в начале скрипта для восстановления сессии, если она уже была создана, и с параметром true при выполнении тех действий, которые требуют обязательного создания сессии (вход пользователя на форум, добавление товара в корзину и т.п.).

Знание таких особенностей и использование предложенной функции позволит не только снизить нагрузку при прохождении по сайту поисковых роботов, но и сэкономить при этом по несколько сотен байтов на каждый запрос, так как без необходимости не будет передаваться заголовок Set-cookie или параметры с идентификатором сессии.

Оказывается, все достаточно просто. В PHP существует специальная функция set_error_handler(), которая позволяет задать свой собственный обработчик ошибок.Единственный ее параметр -- это имя функции-обработчика, которая вызывается в случае возникновения ошибки. Функция-обработчик имеет 4 параметра: номер ошибки, текст ошибки, имя файла, в котором ошибка произошла и номер строки в этом файле.

Но этих данных может быть недостаточно. Часто требуется вывести и весь стек вызовов, чтобы понять, где именно произошла ошибка. Получить стек вызвов можно с помощью функции debug_backtrace, которая возвращает массив обратных вызовов. Каждый элемент этого массива является хешем со следующими полями: function -- имя функции, args -- аргументы функции, file -- имя файла скрипта, в котором она была вызвана. line -- номер строки, где был выполнен вызов функции.

Внимание: в ряде случаев file и line бывают не заданы, всегда проверяйте их (да и вообще любые индексы массива) с помощью isset, а константы -- с помощью defined, иначе возникнет рекурсивный вызов обработчика ошибок. Кроме того, если сделать вывод аргументов функций, нужно принять меры, чтобы не выдавался пароль от базы данных в том случае, если ошибка возникнет на этапе подключения к СУБД (т.е. при вызове функции mysql_connect или ей подобной). Самый простой вариант -- заменять его с помощью str_replace на звездочки или иные спецсимволы перед выводом.

Рассмотрим пример функции-обработчика:

 function error_handler($errno, $errstr, $errfile, $errline) {
 $dbg_on = defined('CONFIG_debug') ? CONFIG_debug : false;     
 $debug=debug_backtrace();     
 $errmsg='<p>'.$errstr.' (строка '.$errline.', '.$errfile.', ошибка: '.$errno.')'.'</p><ul style="font-size: 0.9em; color: #600">';     
 $count=count($debug);     
 for ($i=1; $i<$count; $i++) { // обрабатываем с единицы, так как нулевой элемент -- это вызов самого обработчика error_handler       
 $errmsg.='<li>'.$debug[$i]['function'].'()'.
               ' — '.((isset($debug[$i]['file'])) ? $debug[$i]['file'] : 'неизвестный файл').', '.
               'строка '.((isset($debug[$i]['line'])) ? $debug[$i]['line'] : 'неизвестна').'</li>'; //.var_dump($debug[$i]['args'])     
 }       $errmsg.='</ul>';      
 if (($errno & E_ERROR) || ($errno & E_USER_ERROR)) { // если ошибка фатальная и требует прекращения работы скрипта       
 if (!headers_sent()) { // если заголовок страницы еще не был отправлен
 header($_SERVER['SERVER_PROTOCOL'].' 500 Internal Server Error');         
 header('Content-Type: text/html; charset=utf-8');         
 echo '<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 				"http://www.w3.org/TR/html4/loose.dtd">
 <head>
 <title>Ошибка сайта</title>
 <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head><body>';       
 }        
 $email = defined('CONFIG_email') ? CONFIG_email : ''; 
 echo '<div style="font-size: 1em; padding: 4px; font-weight: bold; color: #C44; border: #C00 1px solid; margin: 4px">На сайте произошла ошибка. Попробуйте обновить страницу через несколько минут. Если ошибка не исчезнет, пожалуйста, сообщите о ней администратору сайта по адресу <a href="mailto:'.$email.'">'.$email.'</a> ';       
 if ($dbg_on) {         
 echo '<p>'.$errmsg.'</p>';         
}       
 echo '</div></body></html>';     
 }     
 else {
 // здесь можно вставить обработку предупреждений (warning) и примечаний (notice), например, с помощью функции _dbg, о которой см. ниже
 }
}

Эта функция получает стек вызова и проверяет, включен ли отладочный режим (он определяется константой CONFIG_debug, которая задается, например, в файле конфигурации вместе с настройками подключения к БД). Дальше идет проверка, отправлены ли заголовки (т.е. делал ли скрипт до этого какой-то вывод). Если нет, то выдается статус 500 (внутренняя ошибка сервера), чтобы поисковые системы не воспринимали сообщение об ошибке как контент, который нужно индексировать, и формируется страница с сообщением об ошибке и предложением написать администратору, адрес которого задан в константе CONFIG_email. Если отладочный режим включен, то выдается и полный стек вызовов функций перед ошибкой. При необходимости в эту же функцию можно добавить сохранение отладочной информации в лог-файл.

Также часто при отладке скриптов требуется вывести значение какой-либо переменной, чтобы понять, на каком этапе берутся неправильные данные. Использование для этого print_r — не самое лучшее решение (особенно при отладке на живом сайте), так как значение может вывестись в неподходящем месте (например, если используется шаблонизатор, то еще до HTML-заголовка). Кроме того, Более корректное решение — запомнить значение в отладочную переменную, которую вывести потом там, где ее появление не будет мешать (например, в подвале сайта).

Я для этих целей использую такую функцию:

function _dbg() {

  $dbg_on = defined('CONFIG_debug') ? CONFIG_debug : false;

  if ($dbg_on) {

    if (!isset($GLOBALS['IntBF_debug'])) $GLOBALS['IntBF_debug']='';

    $GLOBALS['IntBF_debug'].='<p>';

    foreach (func_get_args() as $name=>$value) {

      if (is_array($value) || is_object($value)) $GLOBALS['IntBF_debug'].=$name.': '.nl2br(str_replace('  ','&nbsp;',htmlspecialchars(print_r($value,true))));

      else $GLOBALS['IntBF_debug'].=$name.': '.htmlspecialchars($value).' ';

    }

    $GLOBALS['IntBF_debug'].="</p>\n";

  }

}

Эта функция экранирует все переданные в нее параметры и запоминает в глобальную переменную $GLOBALS['IntBF_debug'], из которой ее можно вывести в любом подходящем месте с помощью обычного echo.

Если требуется прервать выполнение скрипта с ошибкой по инициативе разработчика (например, после ошибочного SQL-запроса), следует использовать функцию trigger_error. У этой функции два параметра: первый -- строка с сообщением об ошибке, которая будет передана в параметр $errstr обработчика, а второй -- код ошибки, который может быть одной из трех констант: E_USER_ERROR (приведет к завершению выполнения), E_USER_WARNING, E_USER_NOTICE.

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

Как известно, в HTTP-протоколе есть три способа сообщить клиенту о том, что передача завершена. Первый, самый старый, -- разорвать соединение после того, как весь контент передан. Он же самый медленный, так как при этом не работает механизм Keep-Alive, и для следующего запроса клиент должен установить новое соединение. Второй -- это передача в заголовке Content-Length длины (в байтах) передаваемого контента. И наконец, третий -- передача контента блоками, перед каждым из которых передается его длина в шестнадцатеричном виде, а завершение передачи обозначается передачей блока с нулевой длиной (так наказываемый chunked transfer, возможно, о нем я напишу со временем отдельную запись).

По каким-то причинам я считал, что в случае использования PHP используется chunked transfer, причем длину chunks определяет и выдает либо сам Apache, либо модуль PHP. Увы, это оказалось не так, и на моем сайте использовался самый медленный первый способ -- закрытие соединения (причем не сразу, а после какого-то тайматуа, что и вызывало задержки).

Возник вопрос, как выводить Content-Length. На первый взгляд, все просто: собрать весь выводимый HTML-код в строку-буфер, посчитать ее длину и выдать. Но во-первых, в некоторых скриптах выдача делалась сразу, а не через буфер, а во-вторых, если включено сжатие GZip, реальная длина отдаваемого контента меньше переданной в Content-Length, и клиент ждет оставшейся части до тех пор, пока не истечет таймаут соединения. (Особенно плохо к этому относятся поисковики, от такого сайт может даже выпасть из выдачи.)

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

<?php
ob_start('ob_gzhandler');
ob_implicit_flush(0); // отключаем неявную отправку буфера
/* Здесь идет код скрипта, в нем не должно быть ob_flush, так как потом нельзя будет выдавать заголовки */
if (!header_sent()) header('Content-Length: '.ob_get_length()); // если заголовки еще можно отправить, выдаем загловок Content-Length, иначе придется завершать передачу по закрытию

ob_end_flush();
exit(0);

Первая и самая очевидная — это имена файлов. Их обязательно нужно проверять на спецсимволы, так как пользователь может подделать HTTP-запрос, в результате чего загружаемый файл будет иметь имя, например, ../index.php.  и при попытке его сохранения затрет корневой индекс. Кроме того, название может содержать русские буквы в кодировке windows-1251 или koi-8, которые некорректно сохранятся в файловой системе. Вывод: нужно сохранять файл не под тем именем, под которым его загрузил пользователь, а под случайным, например MD5-хешем от имени файла, времени загрузки и IP пользователя. Имя же этого файла где-нибудь в базе, а потом отдавать файл скритом, который предварительно будет выдавать заголовок Content-disposition: attachment; filename="имя_файла".

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

И наконец, третья, самая главная проблема — загрузка исполняемых скриптов. Тут есть несколько решений. Первое — если предполагается загрузка только определенных видов файлов (например, автар может быть только картинкой в PNG, JPG, GIF) и отвергать все, что не подходит. Но иногда требуется разрешить загружать файлы любых типов. Тогда возникает второй вариант: проверять расширение загруженного файла и, если оно небезопасно, переименовывать его (например, замена расширения с .php на .phps приведет к тому, что скрипт не будет выполняться, а будет показан его код с подсветкой синтаксиса). Главный недостаток этого решения -- может оказаться, что на каком-то сервере настроено исполнение скриптов с необычном расширением, например, .php3, и отфильтровать это не получится. И наконец, третий вариант -- это отключить обработку скриптов, например через .htaccess:

RemoveHandler .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp .htm .html .wml
AddType application/x-httpd-php-source .phtml .php .php3 .php4 .php5 .php6 .phps .cgi .exe .pl .asp .aspx .shtml .shtm .fcgi .fpl .jsp

Однако следует учесть, что файл .htaccess влияет только на Apache (да и то его использование нужно включить в настройках), а на других серверах он будет проигнорирован. (Особенно важно это для скриптов, которые выкладываются в публичный доступ: рано или поздно найдется пользователь с каким-нибудь IIS, который не примет должных мер, поэтому лучше сочетать этот способ с предыдущим.)

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

Понравилось вот что:

1. Минималистичный интерфейс, теперь почти такой же, как у Google Chrome.
2. Быстрая загрузка и отрисовка страниц. Сайт (если только не тормозит сервер) отрисовывается буквально сразу, а по мере догрузки идут незначительные изменения во внешнем виде.
3. Ускорена работа с JavaScript. В частности, GMail открывается теперь так же, как в Google Chrome, если даже не быстрее. Так же быстрее грузятся визуальные редакторы типа TinyMCE.
4. Управление группами вкладок! Совершенно необходимая для меня возможность, так как если у меня открыто более 6 вкладок, я начинаю путаться и вместо работы бессмысленно переключаться между ними. Теперь же можно все ненужные вкладки вынести в отдельные группы, и мешать работать они не будут.
5. В Windows 7 — показ previews всех вкладок при наведении мышкой на значок в Панель задач. Очень удобно для того, чтобы переключиться сразу в нужную вкладку.
6. Встроенные средства Web-разработки, в частности, отслеживание запросов сразу, без дополнительных расширений. Тоже весьма полезно.
7. Так же возникло впечатление, что улучшено сглаживание шрифтов, по крайней мере, они выглядят лучше, чем в Chrome.

Ну и кроме того, под Firefox есть такие полезные дополнения, как It's all text (редактирование текста во внешнем редакторе) и Вебмастер SAPE, аналогов которым для других броузеров я так и не нашел.

Из недостатков можно отметить только два традиционных: большой объем потребляемой памяти (при 4 открытых вкладках после часа использования -- 360 Mb на 64-битной системе) и необходимость рестарта после установки/удаления дополнения.

При запуске из командной строки функция возвращает значение "cli", при запуске в качестве CGI-модуля "cgi" или "fast-cgi", а если как модуль сервера -- то имя этого сервера.

Важно отметить, что если из командной строки скрипт запускается не с помощью php, а с помощью php-cgi, то и функция будет возвращать cgi, а так же будут применены ограничения по времени и памяти, заданные в php.ini (memory_limit и max_execution_time).

Пример кода для проверки:

$sapi = php_sapi_name();
if ($sapi=='cli') echo 'Запуск из командной строки';
elseif (substr($sapi,0,3)=='cgi') echo 'Запуск в режиме CGI';
elseif (substr($sapi,0,6)=='apache') echo 'Запуск в режиме модуля Apache';
else echo 'Запуск в режиме модуля сервера '.$sapi;