More about PHP
Predefined Variables
Since PHP 4.1.0, the preferred method for retrieving external variables is
with the superglobals mentioned below. Before this time, people relied on either
register_globals or the long predefined PHP arrays ($HTTP_*_VARS).
Начиная с PHP 5.0.0, длинные предопределенные переменные массивов PHP могут быть
отключены директивой register_long_arrays.
Server variables:
$_SERVER
NB: Introduced in 4.1.0. In earlier versions, use
$HTTP_SERVER_VARS.
$_SERVER is an array containing information such
as headers, paths, and script locations. The entries in this array are
created by the webserver. There is no guarantee that every webserver will
provide any of these; servers may omit some, or provide others not listed
here. That said, a large number of these variables are accounted for in the
CGI 1.1 specification, so you should be able to expect those. This is a 'superglobal', or automatic global, variable. This simply means
that it is available in all scopes throughout a script. You don't need to do
a global $_SERVER; to access it within functions or
methods, as you do with $HTTP_SERVER_VARS.
$HTTP_SERVER_VARS contains the same initial
information, but is not an autoglobal. (Note that
$HTTP_SERVER_VARS and $_SERVER are different
variables and that PHP handles them as such)
If the register_globals directive is set, then these variables will also
be made available in the global scope of the script; i.e., separate from the
$_SERVER and $HTTP_SERVER_VARS
arrays. For related information, see the security chapter titled Using
Register Globals. These individual globals are not autoglobals. You may or may not find any of the following elements in $_SERVER. Note
that few, if any, of these will be available (or indeed have any meaning) if
running PHP on the command line.
The filename of the currently executing script, relative to the
document root. For instance,
$_SERVER['PHP_SELF'] in a script at the address
http://example.com/test.php/foo.bar would
be /test.php/foo.bar.
If PHP is running as a command-line processor, this variable is
not available.
'argv'
Array of arguments passed to the script. When the script is run
on the command line, this gives C-style access to the command line
parameters. When called via the GET method, this will contain the
query string.
'argc'
Contains the number of command line parameters passed to the
script (if run on the command line).
'GATEWAY_INTERFACE'
What revision of the CGI specification the server is using; i.e.
'CGI/1.1'.
'SERVER_NAME'
The name of the server host under which the current script is
executing. If the script is running on a virtual host, this will be
the value defined for that virtual host.
'SERVER_SOFTWARE'
Server identification string, given in the headers when
responding to requests.
'SERVER_PROTOCOL'
Name and revision of the information protocol via which the page
was requested; i.e. 'HTTP/1.0';
'REQUEST_METHOD'
Which request method was used to access the page; i.e. 'GET',
'HEAD', 'POST', 'PUT'.
'QUERY_STRING'
The query string, if any, via which the page was accessed.
'DOCUMENT_ROOT'
The document root directory under which the current script is
executing, as defined in the server's configuration file.
'HTTP_ACCEPT'
Contents of the Accept: header from the
current request, if there is one.
'HTTP_ACCEPT_CHARSET'
Contents of the Accept-Charset: header
from the current request, if there is one. Example: 'iso-8859-1,*,utf-8'.
'HTTP_ACCEPT_ENCODING'
Contents of the Accept-Encoding: header
from the current request, if there is one. Example: 'gzip'.
'HTTP_ACCEPT_LANGUAGE'
Contents of the Accept-Language: header
from the current request, if there is one. Example: 'en'.
'HTTP_CONNECTION'
Contents of the Connection: header from
the current request, if there is one. Example: 'Keep-Alive'.
'HTTP_HOST'
Contents of the Host: header from the
current request, if there is one.
'HTTP_REFERER'
The address of the page (if any) which referred the user agent
to the current page. This is set by the user agent. Not all user
agents will set this, and some provide the ability to modify
HTTP_REFERER as a feature. In short, it
cannot really be trusted.
'HTTP_USER_AGENT'
Contents of the User-Agent: header from
the current request, if there is one. This is a string denoting the
user agent being which is accessing the page. A typical example is:
Mozilla/4.5 [en] (X11; U; Linux 2.2.9
i586). Among other things, you can use this value with
get_browser() to tailor your page's output
to the capabilities of the user agent.
'REMOTE_ADDR'
The IP address from which the user is viewing the current page.
'REMOTE_HOST'
The Host name from which the user is viewing the current page.
The reverse dns lookup is based off the
REMOTE_ADDR of the user.
NB: Your web server must be configured to create
this variable. For example in Apache you'll need
HostnameLookups On inside
httpd.conf for it to exist. See
also gethostbyaddr()
'REMOTE_PORT'
The port being used on the user's machine to communicate with
the web server.
'SCRIPT_FILENAME'
The absolute pathname of the currently executing script.
NB: If a script is executed with the CLI, as a
relative path, such as file.php or
../file.php,
$_SERVER['SCRIPT_FILENAME'] will contain the relative
path specified by the user.
'SERVER_ADMIN'
The value given to the SERVER_ADMIN (for Apache) directive in
the web server configuration file. If the script is running on a
virtual host, this will be the value defined for that virtual host.
'SERVER_PORT'
The port on the server machine being used by the web server for
communication. For default setups, this will be '80';
using SSL, for instance, will change this to whatever your defined
secure HTTP port is.
'SERVER_SIGNATURE'
String containing the server version and virtual host name which
are added to server-generated pages, if enabled.
'PATH_TRANSLATED'
Filesystem- (not document root-) based path to the current
script, after the server has done any virtual-to-real mapping.
'SCRIPT_NAME'
Contains the current script's path. This is useful for pages
which need to point to themselves.
'REQUEST_URI'
The URI which was given in order to access this page; for
instance, '/index.html'.
'PHP_AUTH_USER'
When running under Apache as module doing HTTP authentication
this variable is set to the username provided by the user.
'PHP_AUTH_PW'
When running under Apache as module doing HTTP authentication
this variable is set to the password provided by the user.
'AUTH_TYPE'
When running under Apache as module doing HTTP authenticated
this variable is set to the authentication type.
Environment variables:
$_ENV
NB: Introduced in 4.1.0. In earlier versions, use
$HTTP_ENV_VARS.
These variables are imported into PHP's global namespace from the
environment under which the PHP parser is running. Many are provided by the
shell under which PHP is running and different systems are likely running
different kinds of shells, a definitive list is impossible. Please see your
shell's documentation for a list of defined environment variables. Other environment variables include the CGI variables, placed there regardless of whether PHP is running as a server module or CGI processor. This is a 'superglobal', or automatic global, variable. This simply means
that it is available in all scopes throughout a script. You don't need to do
a global $_ENV; to access it within functions or
methods, as you do with $HTTP_ENV_VARS. $HTTP_ENV_VARS contains the same initial
information, but is not an autoglobal. (Note that HTTP_ENV_VARS and $_ENV are different
variables and that PHP handles them as such) If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the
$_ENV and $HTTP_ENV_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
HTTP Cookies:
$_COOKIE
NB: Introduced in 4.1.0. In earlier versions, use
$HTTP_COOKIE_VARS.
An associative array of variables passed to the current script via HTTP
cookies. Automatically global in any scope. This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do
a global $_COOKIE; to access it within functions or
methods, as you do with $HTTP_COOKIE_VARS. $HTTP_COOKIE_VARS contains the same initial information, but is not an autoglobal. (Note that HTTP_COOKIE_VARS and $_COOKIEare different variables and that PHP handles them as such) If the register_globals directive is set, then these variables will also be made available in the global scope of the script;i.e., separate from the $_COOKIE and $HTTP_COOKIE_VARS arrays. For relatedinformation, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
HTTP GET variables:
$_GET
NB: Introduced in 4.1.0. In earlier versions, use
$HTTP_GET_VARS.
An associative array of variables passed to the current script via the
HTTP GET method. Automatically global in any scope. This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_GET; to access it within functions or methods, as you do with $HTTP_GET_VARS. $HTTP_GET_VARS contains the same initial
information, but is not an autoglobal. (Note that
HTTP_GET_VARS and $_GET are different
variables and that PHP handles them as such) If the register_globals directive is set, then these variables will also
be made available in the global scope of the script; i.e., separate from the
$_GET and $HTTP_GET_VARS
arrays. For related information, see the security chapter titled Using
Register Globals. These individual globals are not autoglobals.
HTTP POST variables:
$_POST
An associative array of variables passed to the current script via theNB: Introduced in 4.1.0. In earlier versions, use
$HTTP_POST_VARS.
HTTP POST method. Automatically global in any scope. This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_POST; to access it within functions or methods, as you do with $HTTP_POST_VARS. $HTTP_POST_VARS contains the same initial
information, but is not an autoglobal. (Note that HTTP_POST_VARS and $_POST are different
variables and that PHP handles them as such) If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the
$_POST and $HTTP_POST_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
HTTP File upload variables:
$_FILES
An associative array of items uploaded to the current script via the HTTPNB: Introduced in 4.1.0. In earlier versions, use
$HTTP_POST_FILES.
POST method. Automatically global in any scope. This is a 'superglobal', or automatic global, variable. This simply means that it is available in all scopes throughout a script. You don't need to do a global $_FILES; to access it within functions or methods, as you do with $HTTP_POST_FILES. $HTTP_POST_FILES contains the same information, but is not an autoglobal. If the register_globals directive is set, then these variables will also
be made available in the global scope of the script; i.e., separate from the
$_FILES and $HTTP_POST_FILES arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
Request variables:
$_REQUEST
NB: Prior to PHP 4.3.0, $_FILESNB: Introduced in 4.1.0. There is no equivalent array in
earlier versions.
information was also included into $_REQUEST.
An associative array consisting of the contents of
$_GET, $_POST, and
$_COOKIE.
This is a 'superglobal', or automatic global, variable. This simply means
that it is available in all scopes throughout a script. You don't need to do
a global $_REQUEST; to access it within functions or
methods. If the register_globals directive is set, then these variables will also
be made available in the global scope of the script; i.e., separate from the
$_REQUEST array. For related information, see the
security chapter titled Using Register Globals. These individual globals are
not autoglobals.
Session variables:
$_SESSION
An associative array containing session variables available to theNB: Introduced in 4.1.0. In earlier versions, use
$HTTP_SESSION_VARS.
current script. See the Session functions documentation for more information
on how this is used. This is a 'superglobal', or automatic global, variable. This simply means
that it is available in all scopes throughout a script. You don't need to do
a global $_SESSION; to access it within functions or
methods, as you do with $HTTP_SESSION_VARS. $HTTP_SESSION_VARS contains the same
information, but is not an autoglobal. If the register_globals directive is set, then these variables will also be made available in the global scope of the script; i.e., separate from the $_SESSION and $HTTP_SESSION_VARS arrays. For related information, see the security chapter titled Using Register Globals. These individual globals are not autoglobals.
Global variables:
$GLOBALS
An associative array containing references to all variables which areNB: $GLOBALS has been available
since PHP 3.0.0.
currently defined in the global scope of the script. The variable names are
the keys of the array. This is a 'superglobal', or automatic global, variable. This simply means
that it is available in all scopes throughout a script. You don't need to do
a global $GLOBALS; to access it within functions or
methods.
The previous error message:
$php_errormsg
$php_errormsg is a variable containing the text
of the last error message generated by PHP. This variable will only be
available within the scope in which the error occurred, and only if the
track_errors configuration option is turned on (it defaults to off).
Post a Comment