「独習PHP」を元に、要約メモしておきたいと思います。
$_POST
POST形式のHTMLフォーム(
move_uploaded_file(対象となるファイルのパス, 移動先のパス)
対象となるファイルのパスは、スーパーグローバル変数を介して取得することができる。$_FILESは、$_POSTや$_GETとは異なり、2次元配列として与えられ、以下の表のような情報を保持している。‘file’は、HTMLフォームで指定された要素名。
要素名 | 概要 |
---|---|
$_FILES[‘file’][‘name’] | オリジナルのファイル名 |
$_FILES[‘file’][‘tmp_name’] | サーバ上で管理された一時的なファイル名 |
$_FILES[‘file’][‘size’] | アップロードファイルのサイズ(バイト) |
$_FILES[‘file’][‘type’] | アップロードファイルのMIMEタイプ(ファイルの種類) |
$_FILES[‘file’][‘error’] | エラーコード |
アップロードがうまくいかない場合の原因を知るためには、$_FILES[‘file’][‘error’]を介してエラーコードを取得する。$_FILESによって返されるエラーコードは以下。
定数 | 値 | 概要 |
---|---|---|
UPLOADED_ERR_OK | 0 | アップロード成功 |
UPLOADED_ERR_INI_SIZE | 1 | アップロードファイルのサイズがupload_max_filesizeパラメータ(php.ini)の指定値を超過 |
UPLOADED_ERR_FILE_SIZE | 2 | アップロードファイルのサイズがHTMLフォームのhiddenフィールド”MAX_FiLE_SIZE”で指定された値を超過 |
UPLOADED_ERR_PARTIAL | 3 | アップロードファイルの一部しかアップロードされていない |
UPLOADED_ERR_NO_FILE | 4 | アップロード失敗 |
UPLOAD_ERR_INI_SIZE、UPLOAD_ERR_NO_FILEが返された場合には、php.iniの以下のパラメータを見直す。
パラメータ | 概要 |
---|---|
upload_max_filesize | アップロードのサイズ制限 |
memory_limit | スクリプトが使用可能なメモリサイズ |
post_max_size | ポストデータのサイズ制限 |
max_execution_time | スクリプトのタイムアウト時間(秒) |
アップロードサイズの制限に引っかかっていなくてもポストデータのサイズ制限に引っかかっている場合もある。また、異動先のディレクトリに書き込み権限がない場合もエラーになるので、パーミッションを確認する。 UPLOAD_ERR_FILE_SIZEが返された場合には、HTMLフォーム内に以下の記述がないかを確認し、値を編集する。
<input type="hidden" name="MAX_FILE_SIZE" value="30000" />
$_SERVER
クライアントの種類や対応言語、サーバから送信されたコンテンツの種類やデータサイズなどの情報が、クライアント/サーバそれぞれで内部的に生成され、リクエスト/レスポンス時に送信されている。このような付随情報はヘッダ情報と呼ばれ、クライアント側から送信されるものはリクエストヘッダ、サーバ側から送信されるものはレスポンスヘッダと呼ばれる。スーパーグローバル変数$_SERVERで取得できるのは、このうちのリクエストヘッダ。
主なリクエストヘッダ
ヘッダ名 | 概要 |
---|---|
HTTP_ACCEPT | クライアントがサポートしているコンテンツの種類(優先順位) |
HTTP_ACCEPT_LANGUAGE | クライアントが対応している言語(優先順位) |
HTTP_AUTHORIZATION | 認証情報 |
HTTP_COKKIE | クライアントに保存されているクッキーデータを送信 |
HTTP_HOST | 要求先のホスト名 |
HTTP_IF_MODIFIED_SINCE | 指定された日時以降にコンテンツが更新されている場合にのみ、サーバからデータを受信 |
HTTP_PROXY_AUTHORIZATION | プロキシサーバ用の認証情報 |
HTTP_RANGE | 要求するリソースの範囲 |
HTTP_REFERER | リンク先のURI |
HTTP_USER_AGENT | クライアントの種類 |
たとえば、User-Agentヘッダを取得する場合は次のようになる
<?php
print ($_SERVER['HTTP_USER_AGENT']);
?>
Webサーバであらかじめ定義された定義済みサーバ変数を取得することも可能。Apacheを利用している場合は、次のような情報を取得することができる。
変数名 | 概要 | 戻り値(例) |
---|---|---|
DOCUMENT_ROOT | ドキュメントルート | C:/Program Files/htdocs |
GATEWAY_INTERFACE | CGIのリビジョン |
CGI/1.1 |
PHP_SELF | 実行中のスクリプト | /samples/server.php |
QUERY_STRING | クエリ文字列 | category=PHP |
REMOTE_ADDR | クライアントのIPアドレス | 127.0.0.1 |
REMOTE_PORT | クライアントのポート番号 | 2856 |
REQUEST_METHOD | HTTPメソッド | POST |
REQUEST_URI | 指定されたURI | /samples/server.php?category=PHP |
SCRIPT_FIMENAME | 実行中のスクリプト | C:/Program Files/htdocs/samples/server.php |
SCRIPT_NAME | 実行中のスクリプト | /samples/server.php |
SERVER_NAME | サーバ名 | localhost |
SERVER_PORT | サーバのポート | 80 |
SERVER_PROTOCOL | プロトコル名、リビジョン | HTTP/1.0 |
SERVER_SIGNATURE | サーバのバージョン | Apache/2.0.55(Win32)PHP/5.1.1 Server at localhost Port 80 |
SERVER_SOFTWARE | サーバのソフトウェア | Apache/2.0.55(Win32)PHP/5.1.1 |
$_ENV
サーバ側で設定された環境変数を取得するためのスーパーグローバル変数。環境変数とはサーバ固有のパラメータを表すもので、プログラム実行時に参照するパスやオプション値などを設定する。たとえば環境変数PATHはコマンドラインなどでプログラムを読み出す場合にデフォルトで検索するディレクトリを指定する。
$_ENVを利用したサーバ環境変数の取得例
env.php
<?php
print ($_ENV['Path']);
?>
C:¥WINDOWS¥system32;…
$_COOKIE
クライアントに保存されているクッキーの値を取得するためのスーパーグローバル変数。セキュリティ的な理由から、一般的にはサーバはクライアント上のファイルを勝手に読み書きできないが、クッキーだけは例外で、自由にテキストを読み書きすることができる。
cookie1.php
<form method="POST" action="cookie2.php">
E-Mailアドレス:
<input type="text" name="email" size="30" value="<?php print ($_COOKIE['email']); ?>" />
<input type="submit" value="送信" />
</form>
cookie2.php
<?php
setcookie ('email',$_POST['email'], time()+60*60*24*90);
print ('クッキー"email"を保存しました');
?>
cookie1.phpにアクセスしてE-Mailアドレスを入力すると「クッキー”email”を保存しました」が表示される。もう一度cookie1.phpにアクセスすると、初回アクセスで入力したE-Mailアドレスがデフォルト表示されている。
setcookie命令の一般的な構文は次のとおり
setcookie(クッキー名, 値 [,有効期限 [,対象のホスト [,対象のパス]]])
対象ホスト/パスを設定した場合には、該当のクッキーをどのホスト/パスから参照可能にするかを限定できる。デフォルトでは、現在のホスト配下のすべてのパスから読み込むことが可能。有効期限はタイムスタンプ値として指定する。タイムスタンプとは「1970年1月1日からの経過秒」を表す値。上記の例では、取得したタイムスタンプに「60秒×60秒×24時間×90日」の値を加算することで、クッキーの有効期限を90日に設定した。90日を経過したクッキーは自動的に破棄されるようになる。クッキーの有効期限を省略した場合には、ブラウザを閉じたタイミングで破棄され、有効期限を現在よりも前に設定した場合は、その場で破棄される。
$_SESSION
前項のクッキーにはいくつかの問題点がある。
- データがクライアント側で保存される クッキーで管理されたデータはクライアント側で自由に削除したり改ざんしたりすることが可能。そのため、クッキー情報をもとにアプリケーション全体の挙動を左右するような判定を行うのは危険。
- 実データがネットワーク上を流れる 通信経路上にリクエスト情報をロギングするような通信機器やソフトウェアがある場合には、クッキー情報が漏洩してしまう可能性がある。
そこで、ユーザがブラウザを開いている間だけ情報を維持したいという場合には、よりセキュアなセッションというしくみを利用する。
- 【クライアント】1回目のリクエスト→【サーバ】
- 【クライアント】←セッションIDの発行【サーバ】
- 【クライアント】2回目以降の要求→【サーバ】
- 【サーバ】セッションIDをキーにセッション情報を取得
- 【クライアント】←セッション情報を送信【サーバ】
クッキーと異なる点は以下
- データがサーバ側で保存される
- ネットワーク上を流れるのはセッションIDだけ
したがって、データがクライアント側で改ざん/削除される可能性が原則としてないし、実データがネットワーク上を行き来しないので、データを盗聴される危険性も相対的に低下する。
session1.php
<?php
session_start();
$_SESSION['sample']='セッション情報(テスト)';
print ('セッション情報"sample"が保存されました。');
?>
session2.php
<?php
session_start();
print ('セッション情報"sample"の値は「'$_SESSION['sample'].'」です。');
?>
最初にsession1.phpにアクセスした後、session2.phpにアクセスすると、sesion1.phpで登録したセッション情報がsession2.phpで参照される。
セッション情報”sample”の値は「セッション情報(テスト)」です。
もしページ毎にsession_start命令を実行するのが面倒な場合は、php.iniでsession.auto_startをOnにすることで省略することも可能。ただし、セッションを利用しないページでもセッションが有効になってしまう点に注意する。必要なページだけでセッションを有効にすれば、サーバリソースをいくらか節約することができる。