POST メソッドによるアップロード
この機能により、テキスト、バイナリファイルの両方をアップロードできるように なります。 PHP の認証機構およびファイル操作関数を用いて、アップロードを許可する ユーザーとアップロード後にそのファイルを使用して行う動作を完全に制御する ことが可能です。
PHP は、全ての RFC-1867 対応ブラウザからファイルのアップロードを 受けることができます。
注意: 関係する設定に関する注記
php.iniの file_uploads, upload_max_filesize, upload_tmp_dir, post_max_size, max_input_time ディレクティブも参照ください。
PHP は Netscape Composer および W3C の Amaya クライアントにより使用される PUT メソッドによるファイルアップロードもサポートしています。詳細は、PUT メソッドのサポート を参照ください。
例1 ファイルアップロード用のフォーム
ファイルアップロード画面は、次のような特別なフォームを作成すること により、作成することができます。
<!-- データのエンコード方式である enctype は、必ず以下のようにしなければなりません -->
<form enctype="multipart/form-data" action="__URL__" method="POST">
<!-- MAX_FILE_SIZE は、必ず "file" input フィールドより前になければなりません -->
<input type="hidden" name="MAX_FILE_SIZE" value="30000" />
<!-- input 要素の name 属性の値が、$_FILES 配列のキーになります -->
このファイルをアップロード: <input name="userfile" type="file" />
<input type="submit" value="ファイルを送信" />
</form>
上の例の __URL__ は、PHP ファイルを指すよう置換される
必要があります。
"MAX_FILE_SIZE" hidden フィールドは、
"file" input フィールドの前に置く必要があります。
この値は、PHP で取得可能なファイルの最大サイズを規定します。この値はバイト数で指定します。
MAX_FILE_SIZE は常に指定しておくべきです。
巨大なファイルを転送しようとして長時間待ち続け、
結局ファイルが大きすぎて転送できなかったなどといった羽目に陥るのを防げるからです。
注意: ブラウザ側でこの最大値を出し抜くのは簡単なことなので、この機能を信頼して、
これより大きなサイズのファイルがブロックされることを前提にしてはいけません。
しかし、PHP 側の最大サイズの設定を欺くことはできません。
注意:
アップロード用のフォームが
enctype="multipart/form-data"属性を有しているかを 確認してください。さもないと、ファイルのアップロードは動作しません。
グローバルの $_FILES には、アップロードされたファイルの情報が含まれます。 サンプルのフォームからの内容は次のようになります。ここでは、上の例のスクリプトで使われたように、 アップロードファイルの名前として userfile を 使用することを仮定していることに注意してください。 実際にはどんな名前にすることもできます。
- $_FILES['userfile']['name']
-
クライアントマシンの元のファイル名。
- $_FILES['userfile']['type']
-
ファイルの MIME 型。ただし、ブラウザがこの情報を提供する場合。 例えば、
"image/gif"のようになります。 この MIME 型は PHP 側ではチェックされません。そのため、 この値は信用できません。 - $_FILES['userfile']['size']
-
アップロードされたファイルのバイト単位のサイズ。
- $_FILES['userfile']['tmp_name']
-
アップロードされたファイルがサーバー上で保存されているテンポラ リファイルの名前。
- $_FILES['userfile']['error']
-
このファイルアップロードに関する エラーコード
- $_FILES['userfile']['full_path']
-
ブラウザからアップロードされたファイルのフルパス。 この値は実際のディレクトリ構造を反映しているとは必ずしも言えないため、 信用できません。 PHP 8.1.0 以降で利用可能です。
php.ini の upload_tmp_dir ディレクティブで 他の場所を指定しない限り、ファイルはサーバーにおけるデフォルトの テンポラリディレクトリに保存されます。サーバーのデフォルトディレクトリは、 PHP を実行する環境において環境変数 TMPDIR を設定する ことにより変更することができます。しかし、PHP スクリプトの内部から putenv() 関数により設定しても上手くいきません。 この環境変数は、アップロードされたファイルに他の処理を行う際にも 同様に使用することが可能です。
例2 ファイルのアップロードを検証する
詳細については、is_uploaded_file() および move_uploaded_file() の関数のエントリも 参照ください。以下はフォームからファイルをアップロードするプロセスの例です。
<?php
$uploaddir = '/var/www/uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
echo '<pre>';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "File is valid, and was successfully uploaded.\n";
} else {
echo "Possible file upload attack!\n";
}
echo 'Here is some more debugging info:';
print_r($_FILES);
print "</pre>";
?>アップロードされたファイルを受け取る PHP スクリプトは、アップロード されたファイルを用いて何をするべきかを決めるために必要なロジックを 全て実装する必要があります。例えば、変数 $_FILES['userfile']['size'] を使用して、小さすぎたり 大きすぎたりするファイルを捨てることができます。指定した型以外の ファイルを全て捨てるために変数 $_FILES['userfile']['type'] を用いることができますが、 これはあくまでいくつかのチェックの中のひとつとしてのみ実行するように してください。なぜなら、この値を設定するのはあくまでもクライアントであり、 PHP 側では何もチェックしていないからです。 また、 $_FILES['userfile']['error'] を使用することができ、 エラーコード に基づき、ロジックを構成することができます。 何らかの方法により、テンポラリディレクトリからファイルを削除したり 他の場所に移動したりする必要があります。
フォームでアップロードされるファイルが選択されていない場合、PHP は $_FILES['userfile']['size'] として 0 を返し、 $_FILES['userfile']['tmp_name'] には値を 設定しません。
移動または名前の変更が行われていない場合、リクエストの終了時に そのファイルはテンポラリディレクトリから削除されます。
例3 ファイルの配列をアップロードする
PHP はファイルについても HTML フォームで配列を使用すること をサポートしています。
<form action="" method="post" enctype="multipart/form-data"> <p>Pictures: <input type="file" name="pictures[]" /> <input type="file" name="pictures[]" /> <input type="file" name="pictures[]" /> <input type="submit" value="Send" /> </p> </form>
<?php
foreach ($_FILES["pictures"]["error"] as $key => $error) {
if ($error == UPLOAD_ERR_OK) {
$tmp_name = $_FILES["pictures"]["tmp_name"][$key];
// basename() で、ひとまずファイルシステムトラバーサル攻撃は防げるでしょう。
// ファイル名についてのその他のバリデーションも、適切に行いましょう。
$name = basename($_FILES["pictures"]["name"][$key]);
move_uploaded_file($tmp_name, "data/$name");
}
}
?>ファイルアップロードのプログレスバーは、セッションのアップロードの進捗 で実装することができます。
User Contributed Notes 8 notes
I think the way an array of attachments works is kind of cumbersome. Usually the PHP guys are right on the money, but this is just counter-intuitive. It should have been more like:
Array
(
[0] => Array
(
[name] => facepalm.jpg
[type] => image/jpeg
[tmp_name] => /tmp/phpn3FmFr
[error] => 0
[size] => 15476
)
[1] => Array
(
[name] =>
[type] =>
[tmp_name] =>
[error] => 4
[size] =>
)
)
and not this
Array
(
[name] => Array
(
[0] => facepalm.jpg
[1] =>
)
[type] => Array
(
[0] => image/jpeg
[1] =>
)
[tmp_name] => Array
(
[0] => /tmp/phpn3FmFr
[1] =>
)
[error] => Array
(
[0] => 0
[1] => 4
)
[size] => Array
(
[0] => 15476
[1] => 0
)
)
Anyways, here is a fuller example than the sparce one in the documentation above:
<?php
foreach ($_FILES["attachment"]["error"] as $key => $error)
{
$tmp_name = $_FILES["attachment"]["tmp_name"][$key];
if (!$tmp_name) continue;
$name = basename($_FILES["attachment"]["name"][$key]);
if ($error == UPLOAD_ERR_OK)
{
if ( move_uploaded_file($tmp_name, "/tmp/".$name) )
$uploaded_array[] .= "Uploaded file '".$name."'.<br/>\n";
else
$errormsg .= "Could not move uploaded file '".$tmp_name."' to '".$name."'<br/>\n";
}
else $errormsg .= "Upload error. [".$error."] on file '".$name."'<br/>\n";
}
?>Do not use Coreywelch or Daevid's way, because their methods can handle only within two-dimensional structure. $_FILES can consist of any hierarchy, such as 3d or 4d structure.
The following example form breaks their codes:
<form action="" method="post" enctype="multipart/form-data">
<input type="file" name="files[x][y][z]">
<input type="submit">
</form>
As the solution, you should use PSR-7 based zendframework/zend-diactoros.
GitHub:
https://github.com/zendframework/zend-diactoros
Example:
<?php
use Psr\Http\Message\UploadedFileInterface;
use Zend\Diactoros\ServerRequestFactory;
$request = ServerRequestFactory::fromGlobals();
if ($request->getMethod() !== 'POST') {
http_response_code(405);
exit('Use POST method.');
}
$uploaded_files = $request->getUploadedFiles();
if (
!isset($uploaded_files['files']['x']['y']['z']) ||
!$uploaded_files['files']['x']['y']['z'] instanceof UploadedFileInterface
) {
http_response_code(400);
exit('Invalid request body.');
}
$file = $uploaded_files['files']['x']['y']['z'];
if ($file->getError() !== UPLOAD_ERR_OK) {
http_response_code(400);
exit('File uploading failed.');
}
$file->moveTo('/path/to/new/file');
?>The documentation doesn't have any details about how the HTML array feature formats the $_FILES array.
Example $_FILES array:
For single file -
Array
(
[document] => Array
(
[name] => sample-file.doc
[type] => application/msword
[tmp_name] => /tmp/path/phpVGCDAJ
[error] => 0
[size] => 0
)
)
Multi-files with HTML array feature -
Array
(
[documents] => Array
(
[name] => Array
(
[0] => sample-file.doc
[1] => sample-file.doc
)
[type] => Array
(
[0] => application/msword
[1] => application/msword
)
[tmp_name] => Array
(
[0] => /tmp/path/phpVGCDAJ
[1] => /tmp/path/phpVGCDAJ
)
[error] => Array
(
[0] => 0
[1] => 0
)
[size] => Array
(
[0] => 0
[1] => 0
)
)
)
The problem occurs when you have a form that uses both single file and HTML array feature. The array isn't normalized and tends to make coding for it really sloppy. I have included a nice method to normalize the $_FILES array.
<?php
function normalize_files_array($files = []) {
$normalized_array = [];
foreach($files as $index => $file) {
if (!is_array($file['name'])) {
$normalized_array[$index][] = $file;
continue;
}
foreach($file['name'] as $idx => $name) {
$normalized_array[$index][$idx] = [
'name' => $name,
'type' => $file['type'][$idx],
'tmp_name' => $file['tmp_name'][$idx],
'error' => $file['error'][$idx],
'size' => $file['size'][$idx]
];
}
}
return $normalized_array;
}
?>
The following is the output from the above method.
Array
(
[document] => Array
(
[0] => Array
(
[name] => sample-file.doc
[type] => application/msword
[tmp_name] => /tmp/path/phpVGCDAJ
[error] => 0
[size] => 0
)
)
[documents] => Array
(
[0] => Array
(
[name] => sample-file.doc
[type] => application/msword
[tmp_name] => /tmp/path/phpVGCDAJ
[error] => 0
[size] => 0
)
[1] => Array
(
[name] => sample-file.doc
[type] => application/msword
[tmp_name] => /tmp/path/phpVGCDAJ
[error] => 0
[size] => 0
)
)
)mpyw is right, PSR-7 is awesome but a little overkill for simple projects (in my opinion).
Here's an example of function that returns the file upload metadata in a (PSR-7 *like*) normalized tree. This function deals with whatever dimension of upload metadata.
I kept the code extremely simple, it doesn't validate anything in $_FILES, etc... AND MOST IMPORTANTLY, it calls array_walk_recursive in an *undefined behaviour* way!!!
You can test it against the examples of the PSR-7 spec ( https://www.php-fig.org/psr/psr-7/#16-uploaded-files ) and try to add your own checks that will detect the error in the last example ^^
<?php
/**
* THIS CODE IS ABSOLUTELY NOT MEANT FOR PRODUCTION !!! MAY ITS INSIGHTS HELP YOU !!!
*/
function getNormalizedFiles()
{
$normalized = array();
if ( isset($_FILES) ) {
foreach ( $_FILES as $field => $metadata ) {
$normalized[$field] = array(); // needs initialization for array_replace_recursive
foreach ( $metadata as $meta => $data ) { // $meta is 'tmp_name', 'error', etc...
if ( is_array($data) ) {
// insert the current meta just before each leaf !!! WRONG USE OF ARRAY_WALK_RECURSIVE !!!
array_walk_recursive($data, function (&$v,$k) use ($meta) { $v = array( $meta => $v ); });
// fuse the current metadata with the previous ones
$normalized[$field] = array_replace_recursive($normalized[$field], $data);
} else {
$normalized[$field][$meta] = $data;
}
}
}
}
return $normalized;
}
?>For clarity; the reason you would NOT want to replace the example script with
$uploaddir = './';
is because if you have no coded file constraints a nerd could upload a php script with the same name of one of your scripts in the scripts directory.
Given the right settings and permissions php-cgi is capable of replacing even php files.
Imagine if it replaced the upload post processor file itself. The next "upload" could lead to some easy exploits.
Even when replacements are not possible; uploading an .htaccess file could cause some problems, especially if it is sent after the nerd throws in a devious script to use htaccess to redirect to his upload.
There are probably more ways of exploiting it. Don't let the nerds get you.
More sensible to use a fresh directory for uploads with some form of unique naming algorithm; maybe even a cron job for sanitizing the directory so older files do not linger for too long.Also note that since MAX_FILE_SIZE hidden field is supplied by the browser doing the submitting, it is easily overridden from the clients' side. You should always perform your own examination and error checking of the file after it reaches you, instead of relying on information submitted by the client. This includes checks for file size (always check the length of the actual data versus the reported file size) as well as file type (the MIME type submitted by the browser can be inaccurate at best, and intentionally set to an incorrect value at worst).$_FILES will be empty if a user attempts to upload a file greater than post_max_size in your php.ini
post_max_size should be >= upload_max_filesize in your php.ini.Note that the MAX_FILE_SIZE hidden field is only used by the PHP script which receives the request, as an instruction to reject files larger than the given bound. This field has no significance for the browser, it does not provide a client-side check of the file-size, and it has nothing to do with web standards or browser features.