я, какое хранилище связано с текущим идентификатором пользовате- 
ля. 
r Если в хранилище имеются какие-то переменные, их значения восстанавливают- 
ся. Точнее, создаются глобальные переменные, которые были сохранены в сессии 
при предыдущем завершении сценария. 
Вообще говоря, рассмотренный механизм, как всегда, не совсем точно соот- 
ветствует истинному положению вещей. А именно, все зависит от того, какое 
значение присвоено настроечному параметру register_globals. Если 
register_globals=0, то в сессии можно будет сохранять (а потом и восста- 
навливать) только величины, содержащиеся в глобальном ассоциативном мас- 
сиве $HTTP_SESSION_VARS. Если же этот параметр содержит значение "исти- 
на" (как обычно и происходит по умолчанию), то в сессии можно 
регистрировать глобальные переменные. 

Часть IV. Стандартные функции PHP 348 
Регистрация переменных 
bool session_register(mixed $name [, mixed $name1, ...]) 
PHP узнает о том, что ту или иную переменную нужно сохранить в сессии, если ее 
предварительно зарегистрировать. Для этого и предназначена функция 
session_register(). Она принимает в параметрах одно или несколько имен пере- 
менных (имена задаются в строках, без знака $ слева), регистрирует их в текущей 

запущенной сессии и возвращает значение "истина", если все прошло корректно. 
Почему же тогда я описал типы параметров как mixed, а не как string? Да 
потому, что на самом деле в функцию можно передавать не одну строку в ка- 
ждом параметре, а сразу список строк. Каждая такая строка будет регистриро- 
вать отдельную переменную с соответствующим именем. Более того — эле- 
ментом списка может опять же быть список строк, и т. д. 
Нет ничего страшного, если мы дважды зарегистрируем одну и ту же переменную в 
сессии. На самом деле, чаще всего как раз так и происходит — при повторном 
запус- 
ке сценария. Вот пример: 
Листинг 25.1. Пример работы с сессиями 
 
 
Счетчик
 
В текущей сессии работы с браузером Вы открыли эту страницу 
 раз(а). Закройте браузер, чтобы обнулить счетчик. 
 
Как видим, все предельно просто. 
Идентификатор сессии 
и имя группы 
Что же, теперь мы уже можем начать писать кое-какие сценарии. Но вскоре возник- 

нет небольшая проблема. Дело в том, что на одном и том же сайте могут 
сосущество-

Глава 25. Управление сессиями 349 
вать сразу несколько сценариев, которые нуждаются в услугах поддержки сессий 
PHP. Они "ничего не знают" друг о друге, поэтому временные хранилища для сессий 

должны выбираться не только на основе идентификатора пользователя, но и на 
осно- 
ве того, какой из сценариев запросил обслуживание сессии. 
Имя группы сессий 
Что, не совсем понятно? Хорошо, тогда рассмотрим пример. Пусть разработчик A 
написал сценарий счетчика, приведенный в листинге 25.1. Он использует перемен- 
ную $count, и не имеет никаких проблем. До тех пор, пока разработчик B, ничего 
не 
знающий о сценарии A, не создал систему статистики, которая тоже использует 
сес- 
сии. Самое ужасное, что он также регистрирует переменную $count, не зная о том, 

что она уже "занята". В результате, как всегда, страдает пользователь: запустив 
сна- 
чала сценарий разработчика B, а потом — A, он видит, что данные счетчиков пере- 

мешались. Непорядок! 
Нам нужно как-то разграничить сессии, принадлежащие одному сценарию, от сессий, 

принадлежащих другому. К счастью, разработчики PHP предусмотрели такое поло- 
жение вещей. Мы можем давать группам сессий непересекающиеся имена, и сцена- 
рий, знающий имя своей группы сессии, сможет получить к ней доступ. Вот 
теперь-то 
разработчики A и B могут оградить свои сценарии от проблем с пересечениями имен 

переменных. Достаточно в первой программе указать PHP, что мы хотим использо- 
вать группу с именем, скажем, sesA, а во второй — sesB. 
string session_nam