Mid-Atlantic Developer Conference - Call for Speakers

フォームの処理

PHP の最も強力な機能の一つは、HTML フォームを処理する手段です。 理解するべき重要な基本概念は、あるフォームの中の全てのフォーム要素が、 自動的に PHP スクリプトで利用可能になるということです。 詳細は、マニュアルのセクション 外部から来る変数 および PHP でフォームを使用する例を参照してください。以下に HTML フォームの例を示します。

例1 簡単な HTML フォーム

<form action="action.php" method="post">
 名前: <input type="text" name="name" />
 年齢: <input type="text" name="age" />
 <input type="submit" />
</form>

このフォームに関して特別なところはありません。これは通常の HTML フォームで特殊なタグは全く使用していません。 ユーザーがこのフォームを記入し、投稿ボタンを押した時、 action.php ページがコールされます。 このファイルには、以下のようなコードを記述します。

例2 フォームからのデータを出力する

こんにちは、<?php echo htmlspecialchars($_POST['name']); ?>さん。
あなたは、<?php echo (int)$_POST['age']; ?> 歳です。

このスクリプトの出力例は次のようになります。

こんにちは、Joe さん。あなたは、22 歳です。

htmlspecialchars() および (int) の部分以外は、何を行っているかは明らかでしょう。 htmlspecialchars() は、html での特殊な文字を適切にエンコードし、 HTML タグや Javascript をページ内に仕込めないようにします。 また、age フィールドには数値が入ることがわかっているので、これを integer 型に 変換 します。これにより、おかしな文字が入力されることを防ぎます。 これらの処理を PHP に自動的に行わせるためには、 filter 拡張モジュールを使用します。 変数 $_POST['name']$_POST['age'] は PHP により自動的に設定されます。 前の部分では、スーパーグローバル$_SERVER を使用しましたが、 ここでは、全ての POST データを保持するスーパーグローバル $_POST を導入しています。 フォームのメソッドが POST であることに注意してください。 GET メソッドを使用している場合、 フォームの情報は代わりにスーパーグローバル $_GET に代入されます。リクエストデータの発信源に留意しない場合には、 スーパーグローバル変数 $_REQUEST を使用することもできます。この変数は、GET, POST, COOKIE, FILE データの混ざったものが含まれます。

XForms の入力を PHP で扱うことも可能ですが、たいていの場合は HTML フォームのほうが快適に使用できるでしょう。 XForms は初心者向けのものではありませんが、気になる人もいるかもしれません。 機能概要の節にある XForm から受信したデータの処理方法 を参照ください。

add a note add a note

User Contributed Notes 4 notes

up
177
sethg at ropine dot com
14 years ago
According to the HTTP specification, you should use the POST method when you're using the form to change the state of something on the server end. For example, if a page has a form to allow users to add their own comments, like this page here, the form should use POST. If you click "Reload" or "Refresh" on a page that you reached through a POST, it's almost always an error -- you shouldn't be posting the same comment twice -- which is why these pages aren't bookmarked or cached.

You should use the GET method when your form is, well, getting something off the server and not actually changing anything.  For example, the form for a search engine should use GET, since searching a Web site should not be changing anything that the client might care about, and bookmarking or caching the results of a search-engine query is just as useful as bookmarking or caching a static HTML page.
up
79
Johann Gomes (johanngomes at gmail dot com)
7 years ago
Also, don't ever use GET method in a form that capture passwords and other things that are meant to be hidden.
up
12
nucc1
8 months ago
worth clarifying:

POST is not more secure than GET.

The reasons for choosing GET vs POST involve various factors such as intent of the request (are you "submitting" information?), the size of the request (there are limits to how long a URL can be, and GET parameters are sent in the URL), and how easily you want the Action to be shareable -- Example, Google Searches are GET because it makes it easy to copy and share the search query with someone else simply by sharing the URL.

Security is only a consideration here due to the fact that a GET is easier to share than a POST. Example: you don't want a password to be sent by GET, because the user might share the resulting URL and inadvertently expose their password.

However, a GET and a POST are equally easy to intercept by a well-placed malicious person if you don't deploy TLS/SSL to protect the network connection itself.

All Forms sent over HTTP (usually port 80) are insecure, and today (2017), there aren't many good reasons for a public website to not be using HTTPS (which is basically HTTP + Transport Layer Security).

As a bonus, if you use TLS  you minimise the risk of your users getting code (ADs) injected into your traffic that wasn't put there by you.
up
-10
Toasty_Pallate
3 months ago
It is worth noting that GET request parameters can be cached while POST request parameters are not. Meaning that if a password is GETted it is stored at various points on the way to the server (Your browser and anyone it's sharing info with, the people manning the firewall at the Org that is receiving the GET, the server logs, etc.)

While it is true that HTTPS encrypts the URL and GET request parameters, nothing guarantees that there is not a Web Application Firewall (that decrypts all traffic going into the Org for inspection) and is logging user info or that one will be implemented in the future at your org. Logs in plain-text are (hopefully) a LOT easier to compromise than a database of hashed passwords.

So if you're managing sensitive information, it's best to use POST.
To Top