注: 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.
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.
Contains the number of command line parameters
passed to the script (if run on the command
line).
What revision of the CGI specification the
server is using; i.e. 'CGI/1.1'.
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 identification string, given in the
headers when responding to requests.
Name and revision of the information protocol
via which the page was requested; i.e. 'HTTP/1.0';
Which request method was used to access the
page; i.e. 'GET', 'HEAD', 'POST', 'PUT'.
The query string, if any, via which the page was
accessed.
The document root directory under which the
current script is executing, as defined in the
server's configuration file.
Contents of the Accept:
header from the current request, if there is one.
Contents of the
Accept-Charset: header from the current request,
if there is one. Example: 'iso-8859-1,*,utf-8'.
Contents of the
Accept-Encoding: header from the current
request, if there is one. Example: 'gzip'.
Contents of the
Accept-Language: header from the current
request, if there is one. Example: 'en'.
Contents of the
Connection: header from the current request, if
there is one. Example: 'Keep-Alive'.
Contents of the Host:
header from the current request, if there is one.
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.
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.
The IP address from which the user is viewing
the current page.
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.
注: 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().
The port being used on the user's machine to
communicate with the web server.
The absolute pathname of the currently executing
script.
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.
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.
String containing the server version and virtual
host name which are added to server-generated pages,
if enabled.
Filesystem- (not document root-) based path to
the current script, after the server has done any
virtual-to-real mapping.
Contains the current script's path. This is
useful for pages which need to point to
themselves.
The URI which was given in order to access this
page; for instance, '/index.html'.
When running under Apache as module doing HTTP
authentication this variable is set to the username
provided by the user.
When running under Apache as module doing HTTP
authentication this variable is set to the password
provided by the user.
When running under Apache as module doing HTTP
authenticated this variable is set to the
authentication type.
注: 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.
注: 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
$_COOKIE 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
$_COOKIE and
$HTTP_COOKIE_VARS arrays. For related information, see
the security chapter titled Using Register Globals.
These individual globals are not autoglobals.
注: 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.
注: Introduced in 4.1.0. In earlier versions, use $HTTP_POST_VARS.
An associative array of variables passed to the
current script via the 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.
注: Introduced in 4.1.0. In earlier versions, use $HTTP_POST_FILES.
An associative array of items uploaded to the current
script via the 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 $_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.
注: Introduced in 4.1.0. There is no equivalent array in earlier versions.
An associative array consisting of the contents of $_GET,
$_POST, and $_COOKIE.
注: Prior to PHP 4.3.0, $_FILES information was also included into $_REQUEST.
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.
注: Introduced in 4.1.0. In earlier versions, use $HTTP_SESSION_VARS.
An associative array containing session variables
available to the 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.
注: $GLOBALS has been available since PHP 3.0.0.
An associative array containing references to all
variables which are 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.
$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).