If you are using PHP 5, make sure you are using $_FILES to collect your post files. I spent an entire day trying to figure out why my files were not uploading when using $HTTP_POST_FILES. Previous to upgrading to PHP 5, $HTTP_POST_FILES was compatible with PHP 4, but you should always use the new method of something in your code!
Gestion des chargements de fichiers
Sommaire
- Explication sur les messages d'erreurs de chargement de fichiers
- Erreurs classiques
- Télécharger plusieurs fichiers simultanément
- Chargement par méthode PUT
Chargements de fichiers par méthode POST
Cette fonctionnalité permet aux personnes de télécharger à la fois du texte et des fichiers binaires. Avec les fonctions d'identification et de manipulation de fichiers de PHP, vous avez le contrôle total pour définir qui a le droit de télécharger mais aussi ce qui sera fait du fichier une fois qu'il sera téléchargé.
PHP est capable de recevoir des fichiers émis par un navigateur conforme à la norme RFC-1867 (c'est-à -dire Netscape Navigator 3 ou supérieur, Microsoft Internet Explorer 3 avec un patch de Microsoft, ou supérieur sans le patch).
Note: Notes de configuration Voir aussi les directives file_uploads, upload_max_filesize, upload_tmp_dir, post_max_size et max_input_time dans php.ini
PHP supporte aussi le chargement par la méthode PUT comme dans le navigateur Netscape Composer et Amaya du W3C. Reportez-vous au chapitre sur le support de la méthode PUT.
Exemple #1 Formulaire de chargement de fichier
Un formulaire de téléchargement de fichiers peut être construit en créant un formulaire spécifique comme ceci :
<!-- Le type d'encodage des données, enctype, DOIT être spécifié comme ce qui suit --> <form enctype="multipart/form-data" action="_URL_" method="post"> <!-- MAX_FILE_SIZE doit précéder le champs input de type file --> <input type="hidden" name="MAX_FILE_SIZE" value="30000" /> <!-- Le nom de l'élément input détermine le nom dans le tableau $_FILES --> Envoyez ce fichier : <input name="userfile" type="file" /> <input type="submit" value="Envoyer le fichier" /> </form>
_URL_ dans l'exemple précédent doit être remplacé et pointé vers un fichier PHP.
Le champ caché MAX_FILE_SIZE (mesuré en octets) doit précéder le champ input de type file et sa valeur représente la taille maximale acceptée du fichier par PHP. Il est très facile de contourner cette restriction. Ne comptez pas sur le respect de cette configuration par le navigateur ! La configuration de PHP sur la taille maximale à respecter ne peut être contournée, elle. Vous devez ajouter la variable MAX_FILE_SIZE à votre formulaire dans tous les cas, car elle prévient le chargement de gros fichiers qui demanderaient un long délai d'attente au client et ainsi feraient échouer le script.
Note: Assurez-vous que votre formulaire de téléchargement de fichier contienne enctype="multipart/form-data", sinon, le fichier se sera pas téléchargé.
La variable globale $_FILES existe depuis PHP 4.1.0 (Utilisez $HTTP_POST_FILES si vous utilisez une version plus ancienne). Ce tableau devrait contenir toutes les informations du fichier téléchargé.
Le contenu du tableau $_FILES est détaillé dans notre exemple ci-dessous. Notez que l'on suppose que le nom de la variable du fichier téléchargé est userfile, tel que défini dans le formulaire ci-dessus, mais peut être n'importe quel nom.
- $_FILES['userfile']['name']
-
Le nom original du fichier, tel que sur la machine du client web.
- $_FILES['userfile']['type']
-
Le type MIME du fichier, si le navigateur a fourni cette information. Par exemple, cela pourra être "image/gif". Ce type mime n'est cependant pas vérifié du côté de PHP et, donc, ne prend pas sa valeur pour se synchroniser.
- $_FILES['userfile']['size']
-
La taille, en octets, du fichier téléchargé.
- $_FILES['userfile']['tmp_name']
-
Le nom temporaire du fichier qui sera chargé sur la machine serveur.
- $_FILES['userfile']['error']
-
Le code d'erreur error code associé au téléchargement de fichier. Cet élément a été introduit en PHP 4.2.0
Le fichier téléchargé sera stocké temporairement dans le dossier temporaire du système, à moins qu'un autre dossier soit fourni avec la directive upload_tmp_dir du php.ini. Le dossier par défaut du serveur peut être changé dans l'environnement via la variable TMPDIR. Modifier la valeur de cette variable avec la fonction putenv() dans un script PHP sera sans effet. Cette variable d'environnement peut aussi être utilisée pour s'assurer que d'autres opérations fonctionnent aussi sur les fichiers téléchargés.
Exemple #2 Validation de téléchargement de fichiers
Voyez aussi les fonctions is_uploaded_file() et move_uploaded_file() pour plus d'informations. L'exemple suivant va télécharger un fichier venant d'un formulaire.
<?php
// En PHP < 4.1.0, $HTTP_POST_FILES doit être utilisé
// Ã la place de $_FILES.
$uploaddir = '/var/www/uploads/';
$uploadfile = $uploaddir . basename($_FILES['userfile']['name']);
echo '<pre>';
if (move_uploaded_file($_FILES['userfile']['tmp_name'], $uploadfile)) {
echo "Le fichier est valide, et a été téléchargé
avec succès. Voici plus d'informations :\n";
} else {
echo "Attaque potentielle par téléchargement de fichiers.
Voici plus d'informations :\n";
}
echo 'Voici quelques informations de débogage :';
print_r($_FILES);
echo '</pre>';
?>
Le script PHP qui reçoit le fichier chargé doit pouvoir gérer le fichier de manière appropriée. Vous pouvez utiliser la variable $_FILES['userfile']['size'] pour recaler tous les fichiers qui sont trop gros ou trop petits. Vous pouvez utiliser la variable $_FILES['userfile']['type'] pour écarter les fichiers qui n'ont pas le bon type, mais l'utiliser uniquement pour une série de vérifications, car cette valeur est complètement sous le contrôle du client et n'est pas vérifiée du côté de PHP. Depuis PHP 4.2.0, vous pouvez utiliser l'information dans $_FILES['userfile']['error'] et adapter votre politique en fonction des codes d'erreur. Quelque soit votre politique, vous devriez soit effacer le fichier du dossier temporaire, soit le déplacer.
Si aucun fichier n'est sélectionné dans le formulaire, PHP retournera 0 dans $_FILES['userfile']['size'] et rien du tout dans $_FILES['userfile']['tmp_name'].
Le fichier sera automatiquement effacé du fichier temporaire à la fin du script, s'il n'a pas été déplacé ou renommé.
Exemple #3 Envoi d'un tableau de fichiers
PHP supporte les tableaux en HTML ainsi qu'avec les fichiers.
<form action="" method="post" enctype="multipart/form-data"> <p>Images: <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];
$name = $_FILES["pictures"]["name"][$key];
move_uploaded_file($tmp_name, "data/$name");
}
}
?>
Gestion des chargements de fichiers
06-Jun-2008 07:19
30-Apr-2008 01:27
hi , i was having difficulty with the upload_max_filesize , if u set the max file size lesser than the php setting then ur script to report error will only work till this difference between ur max set file size and the php set max size .Hence if the uploaded file exceeds the php max file size then php end abruptly without a trace of error that is it behaves like no file is uploaded and hence no error reported .Sure if uploading a file is optional for a form then a user who uploads larger file will get no error and still the form will be processed only without the file.
The method of using GET can't be used for optional uploads. Can't find help even in the bugs .Be careful with optional uploads.
jahajee
24-Apr-2008 10:07
You should not have any directories within your website root that has the permissions required for file upload. If you are going to do a file upload, I recommend you use the PHP FTP Functions in conjunction with your file field, that way the files are transferred to a remote FTP location separate from your server.
04-Apr-2008 05:57
You can also use strrchr() to get the file extension, it produces the same result as the post below mine...
i.e. file_ext = strrchr($filename, '.');
This gets the string after the last occurrence of a dot (including the dot)
02-Apr-2008 08:44
Here is a quick and easy way to get the base name and the extension of a file.
I noticed that many examples here use explode(...), however this doesn't handle filenames like foo-1.0.1.tar gracefully. This code does. (foo-1.0.1 is the base, and .tar is the extension).
<?php
$file_basename = substr($filename, 0, strripos($filename, '.')); // strip extention
$file_ext = substr($filename, strripos($filename, '.'));
?>
Notice the use of "strripos()" instead of "stripos()".
If you need to detect .tar.gz, etc. as the ext (starting at the first dot), substitute "stripos" for "strripos".
24-Jan-2008 03:17
Note that on Windows, EVERY file has execute permission. This means whenever you upload a file from a Windows host, it will have its execute bit set.
If you are moving uploaded files to a directory where they will be accessible via HTTP (necessary if e.g. you want to allow uploads of avatars), you *must* use chmod() to make them non-executable after moving them to their intended location. Otherwise, you run the risk that they could be treated by the web server as CGI scripts.
If you don't need uploaded files to be accessible directly via http, then use a .htaccess file containing the line "Deny from all" in the directory where you placed them; or, if your web server is set up with public_html directories, place uploaded files in a location *outside* public_html.
Note also that the uploaded files won't belong to you, but to the user in whose name httpd is running. And on most systems, only root can chown() files (even if they were your files to begin with). This will mean you can't do file management via FTP / SSH unless you make the files world-writable ..... and you probably don't really want that. (Workaround: put in a password protected script to chmod() files as required, and if for some reason you don't trust Apache's password protection, use your FTP client to make it non-world-readable when it is not needed.)
07-Jan-2008 08:51
An upploaded file ( $_FILES['userfile']['tmp_name'] ) has permission 600 and MySQL LOAD_FILE() function will not work!
Use chmod() to change permission.
27-Nov-2007 05:50
G'day, note that the name of the input field cannot contain spaces.
bad:
<input type="file" name="some descriptive name" />
good:
<input type="file" name="some_descriptive_name" />
26-Sep-2007 04:59
OK,... I got it... finally!
If some of you have also problems uploading large files but the usual sizes/times in php.ini are ok, please check
session.gc_maxlifetime
when you are using session management with your upload script!
The default value is 1440 which is just 24min... so with only 600kbit/s upload rate the session will be closed automatically after uploading
about 100MB. Actually you are able to upload more, but the file won't be copied from the temporary to the destination folder... ;-)
You can set the value also directly inside the php-script via
<? ini_set("session.gc_maxlifetime","10800"); ?>
24-Sep-2007 05:55
I don't believe the myth that 'memory_size' should be the size of the uploaded file. The files are definitely not kept in memory... instead uploaded chunks of 1MB each are stored under /var/tmp and later on rebuild under /tmp before moving to the web/user space.
I'm running a linux-box with only 64MB RAM, setting the memory_limit to 16MB and uploading files of sizes about 100MB is no problem at all! Nevertheless, some users reported a problem at a few 100MB, but that's not confirmed... ;-)
The other sizes in php.ini are set to 1GB and the times to 300... maybe the execution_time limits before, since the CPU is just a 233MHz one... :-)
12-Sep-2007 10:30
I rather check the imagetype with getimagesize. <4 and != 0 equals jpg, gif, png. Also it already gives you a chance to store other interesting data about the images.
php.ini vars that deal with size that need to be checked are
-max upload filesize
-max post data size
-memory limit (for script to use)
My suggestion is to keep the two latter greater then the upload file size limit to be able to give back some user errors.
When POST data size get exceeded it just doesn't run the script that is set to run at application of a form. So
21-Jul-2007 12:37
I try to set up file uploading under IIS 7 and PHP 5.
First problem was to set 2 variables in php.ini
file_uploads = On
upload_tmp_dir = "C:\Inetpub\wwwroot\uploads"
For some reasons such directory name works,
but "upload_tmp" won't work.
The second problem was to set correct user rigths for upload folders where you try to save your file. I set my upload folder rights for the "WORKGROUP/users" for the full access. You may experiment by yourselves if you not need execute access, for example.
10-Jul-2007 10:19
Hi there.
As far as I understand IE has his own MIME types based on the values stored in a registry. To locate this "feature" I spent a lot of time and was granted with a perfect headache. :)
In my case I tried to upload a CSV file on a server and abort a script in case if the corresponding file isn't of a desired type.
And it work fine with Opera and stuck with IE.
So the workaround is that you should add this values in your windows registry (I have windows xp box and it works fine for me)
[HKEY_CLASSES_ROOT\.csv]
"Content Type"="application/vnd.ms-excel"
@="Excel.CSV"
[HKEY_CLASSES_ROOT\.csv\Excel.CSV]
[HKEY_CLASSES_ROOT\.csv\Excel.CSV\ShellNew]
NB:
add the value "application/vnd.ms-excel" if you plan to open it with excel.
22-Jun-2007 02:05
Beware the mime-types! Given the GIF security issue that has been doing the rounds recently you may be inclined to validate an update based on its reported mime-type from the $_FILES array. However be careful with this - it is set by the *browser*, not by PHP or the web server, and browsers are not consistent (what's new?!)
For example IE6/7 will upload a progressive JPEG as image/pjpeg, while Firefox and Opera will upload it as image/jpeg. More importantly IE will try and determine the mime type of the file by actually inspecting its contents. For example if you rename a perfectly valid PNG file to end with .zip instead, IE will still send a mime type of image/x-png, where-as Firefox and Opera will send application/x-zip-compressed and application/zip respectively, even though the file is a valid PNG.
In short if you are going to validate an upload on the mime-type, be sure to do some careful research and testing first!
25-May-2007 03:24
To clarify a point made by Brian AW:
"Turns out php stores the uploaded file in memory until you do something with it"
this is not true. The file is written to the tmp directory as it is uploaded (just keep checking your tmp directory whilst uploading to confirm this for yourself). I just uploaded an 111M file with php restricted to 8M of memory.
24-Apr-2007 12:13
Clarification on the MAX_FILE_SIZE hidden form field:
PHP has the somewhat strange feature of checking multiple "maximum file sizes".
The two widely known limits are the php.ini settings "post_max_size" and "upload_max_size", which in combination impose a hard limit on the maximum amount of data that can be received.
In addition to this PHP somehow got implemented a soft limit feature. It checks the existance of a form field names "max_file_size" (upper case is also OK), which should contain an integer with the maximum number of bytes allowed. If the uploaded file is bigger than the integer in this field, PHP disallows this upload and presents an error code in the $_FILES-Array.
The PHP documentation also makes (or made - see bug #40387 - http://bugs.php.net/bug.php?id=40387) vague references to "allows browsers to check the file size before uploading". This, however, is not true and has never been. Up til today there has never been a RFC proposing the usage of such named form field, nor has there been a browser actually checking its existance or content, or preventing anything. The PHP documentation implies that a browser may alert the user that his upload is too big - this is simply wrong.
Please note that using this PHP feature is not a good idea. A form field can easily be changed by the client. If you have to check the size of a file, do it conventionally within your script, using a script-defined integer, not an arbitrary number you got from the HTTP client (which always must be mistrusted from a security standpoint).
09-Mar-2007 11:29
As said before if POST size exceeds server limit then $_POST and $_FILES arrays become empty. You can track this using $_SERVER['CONTENT_LENGTH'].
For example:
<?php
$POST_MAX_SIZE = ini_get('post_max_size');
$mul = substr($POST_MAX_SIZE, -1);
$mul = ($mul == 'M' ? 1048576 : ($mul == 'K' ? 1024 : ($mul == 'G' ? 1073741824 : 1)));
if ($_SERVER['CONTENT_LENGTH'] > $mul*(int)$POST_MAX_SIZE && $POST_MAX_SIZE) $error = true;
?>
31-Dec-2006 07:01
When uploading on a windows system and working with different partitions and different drive letters, uploading might not work correctly with the shown example.
The workaround is include the current operating directory in the target dir, as follows:
<?php
//you can delete the 'echo' commands and the '$temploc='-line
$currentdir=getcwd();
$target_path = $currentdir . "/2nddir/" . basename($_FILES['uploadedfile']['name']);
echo "Target: $target_path<br>";
$temploc=$_FILES['uploadedfile']['tmp_name'];
echo "Temploc: $temploc<br>";
if (move_uploaded_file($_FILES['uploadedfile']['tmp_name'], $target_path)) {
echo "The file ". basename( $_FILES['uploadedfile']['name']). " has been uploaded<br><br>";
} else {
echo "There was an error uploading the file, please try again!<br><br>";
}
?>
If the $currentdir is omitted and not used in $target_path:
Target: /2nddir/file.ext
Temploc: /ms4w/tmp/\php12C.tmp
Warning: move_uploaded_file(/ms4w/tmp/\php12C.tmp) [function.move-uploaded-file]: failed to open stream: No such file or directory in D:\Public\www\dir\test.php
Warning: move_uploaded_file() [function.move-uploaded-file]: Unable to move '/ms4w/tmp/\php12C.tmp' to '/2nddir/file.ext' in D:\Public\www\dir\test.php
There was an error uploading the file, please try again!
If it's written as the code shown above, it works perfectly:
Target: D:\Public\www\dir/2nddir/file.ext
Temploc: /ms4w/tmp/\php12C.tmp
The file file.ext has been uploaded
My initial thought the "\" in front of the temporary file was causing the problem. But don't bother about the "\", it does no harm!
06-Dec-2006 08:45
Now that PHP 5.2 supports a hook that can be used to handle upload progress, you can use a PECL extension (uploadprogress) to display an upload progress meter. Since documentation for this PECL extension is a bit thin on the ground, here are the basics:
1) Run "pecl install uploadprogress", and add "extension=uploadprogress.so" in your php.ini file.
2) Tell the extension where to temporarily store information about each upload. By default, this is in "/tmp/upt_%s.txt" (where %s is replaced with the UPLOAD_IDENTIFIER, see below). You can change it with the following config line:
uploadprogress.file.filename_template = /path/to/some_name_%s.txt
It must have a single '%s' in it, or it will fail!
3) Add a hidden element at the very beginning (this is important) of your upload form, called UPLOAD_IDENTIFIER. The value of this should be match the expression "^[A-Za-z0-9_.-=]{1,64}$" and be unique for every upload.
4) When the form is submitted, pop open a window to display the progress information and continue submitting the form. This window should refresh itself every few seconds, calling a PHP script that will retrieve the progress information and generate a display meter.
This script calls the function uploadprogress_get_info($id), where $id is the UPLOAD_IDENTIFIER value. This will return false if there is no progress information, or an array of values about that upload. The array contains:
time_start - The time that the upload began (same format as time()).
time_last - The time that the progress info was last updated.
speed_average - Average speed. (bytes / second)
speed_last - Last measured speed. (bytes / second)
bytes_uploaded - Number of bytes uploaded so far.
bytes_total - The value of the Content-Length header sent by the browser.
files_uploaded - Number of files uploaded so far.
est_sec - Estimated number of seconds remaining.
The speed_average is measured based on the number of bytes uploaded since the upload began, whereas the speed_last is based on the number of bytes uploaded since the progress information was last updated. The progress information is updated whenever PHP reads in some more data from the client, so speed_last may not be very accurate.
Note 1) The bytes_total figure is NOT a reflection of the file size, but of the POST's size, so don't expect them to match.
Note 2) This module really only detects how much data the POST form has sent, and keeps a running count of how many POST variables of type 'file' that it encounters along the way. It has no way of knowing how many files are in the POST, so it is not possible to have a progress bar for each file, just one for all files (and the ability to display how many files have been uploaded so far).
29-Nov-2006 06:11
Before you even bother doing anything, verify the filesystem your permanent upload directory will reside on. Use NTFS before you even start! (Assuming you're on Windows.)
Unfortunately, because I've been preparing to switch to Linux on this machine, I thought it would be a *great* idea to use FAT32 so I could access my websites from both Windows and Linux (this is not a production box, but where I am creating a CMS).
This was a *bad* idea...since the filesystem is not NTFS, now the only permissions I can set are *share* permissions.
I *guess* that *share* permissions are not used through the webserver, because even though the user Apache runs as is one of the users given permissions "Read" and "Modify" share permissions, the file cannot be permanently saved via neither move_uploaded_file() nor copy().
I verified this by using conditionals with !is_readable() and !is_writable() to echo specific messages.
So, now I have to back up everything I've done, reformat that partition as NTFS, copy everything over again, and set all the permissions, including on databases that I am using with other pages. *(sigh)*
23-Oct-2006 07:44
I have an application with a file upload page. I notice that if I enter garbage in the filename text box associated with the <input type="file"> element associated with my multipart upload form, the form does not get submitted when the submit button is clicked. There is no custom form validation JavaScript code associated with the form. Can anyone tell me if multipart forms do any kind of default validation of their own?
Robert
18-Oct-2006 09:12
For those of you trying to make the upload work with IIS on windows XP/2000/XP Media and alike here is a quick todo.
1) Once you have created subdirectories "uploads/" in the same directory wher you code is running use the code from oportocala above and to make absolutely sure sure that the file you are trying to right is written under that folder. ( I recomend printing it using echo $uploadfile; )
2) In windows explorer browse to the upload directory created above and share it. To do that execute the following substeps.
a) Right click the folder click "sharing and security..."
b) Check 'Share this folder on the network'
c) Check 'Allow network users to change my files' ( THIS STEP IS VERY IMPORTANT )
d) click 'ok' or 'apply'
3) you can then go in the IIS to set read and write permissions for it. To do that execute the followin substeps.
a) Open IIS (Start/Controp Panel (classic View)/ Admistrative tools/Internet Information Service
b) Browse to your folder (the one we created above)
c) right click and select properties.
d) in the Directory tab, make sure, READ, WRITE, AND DIRECTORY BROWSING are checked.
e) For the security freaks out there, You should also make sure that 'execute permissions:' are set to Script only or lower (DO NOT SET IT TO 'script and executable)'( that is because someone could upload a script to your directory and run it. And, boy, you do not want that to happen).
there U go.
Send me feed back it if worked for you or not so that I can update the todo.
jedi_aka@yahoo.com
PS: BIG thanks to oportocala
04-Sep-2006 03:02
I have been upgrading a web server. The current configuration is IIS 6.0 + PHP 5.2 build 3790 with SSL support.
File uploads failed with a blank screen if the file size exceeded ca. 49 Kb. I tried modifying different timeout parameters (PHP and IIS) and the POST_MAX_SIZE and UPLOAD_MAX_FILESIZE directives. Modifications had no effect.
After turning off SSL in IIS uploads were successful. Some experimenting showed that the "Accept client certificates" -setting was causing the problem. Now I am running IIS with SSL and "Ignore client certificates" -setting. Even large files can now be uploaded.
I didn't found anything about this feature on the web.
17-Aug-2006 05:16
Remember that upload sizes are also affected by the setting <i>post_max_size</i>. If the file size, or more accurately the post size (file size + header data) is exceeded, PHP seems to just die. From what I've found so far, there doesn't even seem to be any entries to the apache log regarding the failure! So basically if you exceed the post size, a user will have no idea that anything failed. If anyone can expand on this, please do so!
20-May-2006 02:47
There was a post earlier about not using the $_FILES['userfile']['type'] for verification and that a malicious PHP file could be hidden under the image/gif mime type.
That is correct, but it is not enough just to use getImageSize() or exif_imagetype() because php code can be hidden in the comment part of the picture.
The only way you can be sure it will not be executed is to make sure that the extension is not recognized by the server as a php script.
If you want a proof of concept, open The GIMP and create a 10x10px blank GIF image. When saving, just enter <? phpinfo() ?> as GIF comment. Rename the saved file from something.gif into the something.php and ask the server for it.
(And make sure that you NEVER call include() with a file that was uploaded)
12-May-2006 02:14
If you are experiencing problems posting files from Internet Explorer to a PHP script over an SSL connection, for instance "Page can not be displayed" or empty $_FILES and $_POST arrays (described by jason 10-Jan-2006 02:08), then check out this microsoft knowledgebase article:
http://support.microsoft.com/?kbid=889334
This knowledgebase article explains how since service pack 2 there may be problems posting from IE over SSL. It is worth checking whether your problem is IE specific since this is definitely not a PHP problem!
07-Apr-2006 09:34
I have the same problem with filename contains single quote. Currently, I am using web-hosting services, hence I am not able to switch magic_quotes_gpc on/off.
After some study, I have discovered that the cause of the problem is in function basename();
For example:
$windows_filename = "C:\tmpdir\ling's document.doc"
with magic_quotes_gpc on
it becames
$windows_filename = "C:\\tmpdir\\ling\'s document.doc"
if you do a
echo basename($windows_filename)
the result will be
"s document.doc"
which is not correct, but this is exactly what we get from $_FILES['userfile']['name'];
To work around with this problem, the following solution might work.
Step 1:
a) Include a hidden field "userfilename" in your form.
b) add a javascript to the "file" input. To objective is to dupilcate the full filename and post it to the host.
<form name="imgform" method="post" action="upload.php" enctype="multipart/form-data">
<input type="hidden" name="userfilename" id="userfilename">
<input type="file" name="userfile" id="userfile" size="64" maxlength="256" onChange="javascript:top.document.imgform.userfilename.value= top.imgform.userfile.value">
</form>
Step 2:
a) extract the filename from the "userfilename"
$fileName = $_FILES['userfile']['name'];
$tmpName = $_FILES['userfile']['tmp_name'];
$fileSize = $_FILES['userfile']['size'];
$fileType = $_FILES['userfile']['type'];
$fp = fopen($tmpName, 'r');
$content = fread($fp, $fileSize);
$content = addslashes($content);
fclose($fp);
if(!get_magic_quotes_gpc())
{
$fileName = addslashes($fileName);
} else {
$fileName = addslashes(basename(stripslashes($_POST['userfilename'])));
}
09-Mar-2006 07:09
As mentioned in this thread by mariodivece at bytedive dot com on 24-Aug-2005 12:33:
"when using base64_encode to store binary data in a database, you are increasing the size of the data by 1.33 times."
so, if you are receiving the dreaded "MySQL Server has gone away" error when uploading BLOB data encoded w/base64, remember that your MySQL "max_allowed_packet" configuration setting (default 1MB) needs to by 1.33 times the size of your PHP "upload_max_filesize" setting.
13-Jan-2006 12:01
In regards to geert dot php at myrosoft dot com about having the filenames cut off if single quotes are present in the filename, I had this same problem. The solution to this, is to set magic_quotes_gpc to off.
When magic_quotes_gpc is on, whenever a single quote is present in any _post data, a \ is inserted before any single quotes as an escape character. This comes in handy if you're storing the post data into mySQL, but causes problems, as you've had, when receiving an upload.
10-Jan-2006 02:08
Regarding empty $_FILES and $_POST arrays when uploading files larger than post_max_size:
Tucked away in http://us3.php.net/manual/en/ini.core.php#ini.post-max-size is this nugget:
"If the size of post data is greater than post_max_size, the $_POST and $_FILES superglobals are empty. This can be tracked in various ways, e.g. by passing the $_GET variable to the script processing the data, i.e. <form action="edit.php?processed=1">, and then checking if $_GET['processed'] is set."
This may seem like a bug. You'd expect something like UPLOAD_ERR_FORM_SIZE to be set. But you just two empty superglobals.
I've seen it submitted to bugs.php.net twice and it's been marked as bogus both times.
04-Jan-2006 04:11
Many ppl uses a java applet for uploading files instead of a forms post. This way you can get a progress bar etc.
If you for some reason cannot upload very large files you can use the java applet to upload it in chunks. I made a small change to the free JUpload applet hosted at sourceforge to do this.
If you in the url you're posting to add the argument
juchunksize=integervalue
the upload will be done as several posts where max-size of one part is integervalue. So you can keep track of where you are, two more parameters are added:
jupart, which is 0..
jufinal, which is 0 when there is more left or 1 if finished.
address to project:
http://sourceforge.net/projects/jupload
link to this JUpload version is here:
http://tinyurl.com/a2j7t
23-Dec-2005 09:16
When file names do contain single quote parts of the filename are being lost.
eg.: uploading a filename
startName 'middlepart' endName.txt
will be uploaded (and hence stored in the _Files ['userfile'] variable as
endName.txt
skipping everything before the second single quote.
27-Nov-2005 11:02
-
Be carefull with setting max_file_size via
ini_get('upload_max_filesize');
ini_get might return values like "2M" which will result in non working uploads.
This was the "no no" in my case:
$form = '<input type="hidden" name="MAX_FILE_SIZE" value=".ini_get('upload_max_filesize')." />';
Files were uploaded to the server, but than there was not any upload information, not even an error message. $_FILES was completly empty.
djot
-
04-Oct-2005 11:03
Generally, if you use
CharsetDisable on
or
CharsetSourceEnc off
in (russian) apache config file, and if your script which receives upload still have some html, use <meta http-equiv ...> tags so browser can correctly display the pages.
03-Sep-2005 06:27
I have been having issues with putting data in to an MSSQL database from an uploaded file. Trying to INSERT a file in excess of 25MB caused "Insufficient memory" errors from the SQL server
I decided to chunk the data into the database rather than trying to spurt it all in at once. The memory management is much better and from Submit to in the DB takes about 1 second per MB. The machine has dual Pentium 3 933MHz and 2GB RAM.
First things first I had to write a stored procedure. I saw no point in attempting to return a TEXTPTR(), which is required for the UPDATETEXT function to work, back to PHP so I didn't even bother. This is my very first stored procedure since this is really the first time I've developed solely for MSSQL. The important thing is that it's functional.
Here's the code I used for my stored procedure. After writing this I need to execute it in a loop to get all the data in, in the correct order. I leave that bit to PHP of course. Please don't tell me I could have just written it all in the stored procedure using another language, this is PHP and MSSQL we're talking about. :)
The zipfile column data type is TEXT, I tried IMAGE but it was problematic dealing with HEX data.
///////////// SP//////////////////////
CREATE PROCEDURE dbo.dds_writeBlob @dataChunk AS TEXT, @refCode AS VARCHAR(50), @offSet AS INT
AS
DECLARE @dataPtr AS BINARY(16)
SELECT @dataPtr=TEXTPTR(zipfile)
FROM [dbo].[file] (UPDLOCK)
WHERE [dbo].[file].ref = @refCode
UPDATETEXT [dbo].[file].zipfile @dataPtr @offSet 0 @dataChunk
GO
//////////////////END SP/////////////////
Then of course comes the PHP code to do the chunking. Firstly I have to convert the binary data to a type that can be accepted by TEXT data type. base64_encode() comes in handy for this purpose but of course I need it in chunks so I used chunk_split() and split it in to chunks of 256000 bytes by declaring the optional [chunklen]. I then explode() it in to a numerically indexed array using the newlines ("\r\n") that are inserted every [chunklen] by chunk_split. I can then loop through with a for(), passing the data chunks, in order, one at a time to the stored procedure. Here's the code:
<?
$data = chunk_split(base64_encode(fread(fopen($file, "rb"), filesize($file))), 256000);
$arrData = explode("\r\n", $data);
unset($data); // Clear memory space
$num = count($arrData);
$offset = 0;
for ($i=0;$i<$num;$i++) {
$buffer = $arrData[$i];
$query = "EXEC [dds_writeBlob] '".$buffer."', '$reference', $offset";
@mssql_query($query) or die(mssql_get_last_message());
$offset = ($offset + strlen($buffer));
}
?>
Of course we then need to extract the data from the database. This, thankfully, is a lot easier! Simply base64_decode() the data before outputting to a browser.
<?
$query = "SELECT zipfile, job_code FROM [file] WHERE ref = '$ref'";
@$result = mssql_query($query) or die('File Download: Failed to get file from the database.');
$file = mssql_fetch_assoc($result);
header('Content-type: application/zip');
header('Content-Disposition: attachment; filename="job-'.trim($file['job_code']).'.zip"');
echo base64_decode($file['zipfile']);
?>
The benefit of storing in base64_encoded format is the simplicity with which you can now send mime emails with the data attached as an alternative to having people download it. A simple chunk_split() on the SELECTed data will have it in the right format for mime mails.
The draw back is the extra size required! Expect the base64_encoded data to be 1.33 times the size of the original data!
24-Aug-2005 08:33
Just wanted to point out a detail that might be of interest to some:
when using base64_encode to store binary data in a database, you are increasing the size of the data by 1.33 times. There is a nicer way of storing the data directly. Try the following:
<?php $data = mysql_real_escape_string($data); ?>
This will leave the data untouched and formatted in the correct way and ready to be inserted right into a MySQL statement without wasting space.
By the way, I'd like to thank therebechips for his excellent advice on data chunks.
19-Aug-2005 01:58
You may come across the following problem using PHP on Microsoft IIS: getting permission denied errors from the move_uploaded_file function even when all the folder permissions seem correct. I had to set the following to get it to work:
1. Write permissions on the the folder through the IIS management console.
2. Write permissions to IUSR_'server' in the folder's security settings.
3. Write permissions to "Domain Users" in the folder's security settings.
The third setting was required because my application itself lives in a secure folder - using authentication (either Basic or Windows Integrated) to identify the users. When the uploads happen IIS seems to be checking that these users have write access to the folder, not just whether the web server (IUSR_'server') has access.
Also, remember to set "Execute Permissions" to "None" in the IIS management console, so that people can't upload a script file and then run it. (Other checks of the uploaded file are recommended as well but 'Execute None' is a good start.)
16-Aug-2005 06:13
Just a quick note that there's an issue with Apache, the MAX_FILE_SIZE hidden form field, and zlib.output_compression = On. Seems that the browser continues to post up the entire file, even though PHP throws the MAX_FILE_SIZE error properly. Turning zlib compression to OFF seems to solve the issue. Don't have time to dig in and see who's at fault, but wanted to save others the hassle of banging their head on this one.
21-Jun-2005 06:52
Internet Explorer has problems with submitting forms with enctype="multipart/form-data" (e.g. uploading files) when combined with text fields containing non-standard ASCII characters (e.g. smart quotes or em-dashes) and a non-Windows-1255 character encoding.
Many Apache 2.0 default configs (e.g. Fedora 3) ship with "AddDefaultCharset UTF-8" in the httpd.conf. Commenting out this line will resolve the problem (assuming no charset is defined using <meta> tags in the page as well).
The problem manifests when submitting the form; the input field containing characters like ©, —, “, ” (common in text copied from MS Word) will appear blank to the receiving page.
24-May-2005 01:14
Caution: *DO NOT* trust $_FILES['userfile']['type'] to verify the uploaded filetype; if you do so your server could be compromised. I'll show you why below:
The manual (if you scroll above) states: $_FILES['userfile']['type'] - The mime type of the file, if the browser provided this information. An example would be "image/gif".
Be reminded that this mime type can easily be faked as PHP doesn't go very far in verifying whether it really is what the end user reported!
So, someone could upload a nasty .php script as an "image/gif" and execute the url to the "image".
My best bet would be for you to check the extension of the file and using exif_imagetype() to check for valid images. Many people have suggested the use of getimagesize() which returns an array if the file is indeed an image and false otherwise, but exif_imagetype() is much faster. (the manual says it so)
20-May-2005 05:25
Using /var/www/uploads in the example code is just criminal, imnsho.
One should *NOT* upload untrusted files into your web tree, on any server.
Nor should any directory within your web tree have permissions sufficient for an upload to succeed, on a shared server. Any other user on that shared server could write a PHP script to dump anything they want in there!
The $_FILES['userfile']['type'] is essentially USELESS.
A. Browsers aren't consistent in their mime-types, so you'll never catch all the possible combinations of types for any given file format.
B. It can be forged, so it's crappy security anyway.
One's code should INSPECT the actual file to see if it looks kosher.
For example, images can quickly and easily be run through imagegetsize and you at least know the first N bytes LOOK like an image. That doesn't guarantee it's a valid image, but it makes it much less likely to be a workable security breaching file.
For Un*x based servers, one could use exec and 'file' command to see if the Operating System thinks the internal contents seem consistent with the data type you expect.
I've had trouble in the past with reading the '/tmp' file in a file upload. It would be nice if PHP let me read that file BEFORE I tried to move_uploaded_file on it, but PHP won't, presumably under the assumption that I'd be doing something dangerous to read an untrusted file. Fine. One should move the uploaded file to some staging directory. Then you check out its contents as thoroughly as you can. THEN, if it seems kosher, move it into a directory outside your web tree. Any access to that file should be through a PHP script which reads the file. Putting it into your web tree, even with all the checks you can think of, is just too dangerous, imnsho.
There are more than a few User Contributed notes here with naive (bad) advice. Be wary.
30-Apr-2005 06:47
I want to share a really easy way of uploading files to your web host from a form!
Someone suggested it way down in these notes. I tried it and it's working!!
Go to http://pear.php.net/index.php
Then go to:
http://pear.php.net/HTTP_Upload
You download the main pear.php files and then the HTTP_Upload file. Upload it to your web host and within minutes, the example will be working!
I'm going to look further on that pear.php.net site too - it looks like they have a lot of good addition for complex PHP functions!
Yahoo!
29-Apr-2005 01:30
Need to get around your PHP.ini file upload limit?
Use a bit of clever JavaScript to get the value of your <input type="file"> (the location of the file on the client's machine), copy it to a hidden text box then try and upload traditionally, if you get a PHP error UPLOAD_ERR_INI_SIZE, then use the value of your hidden text box to initiate a PHP-FTP connection and upload to your heart's content.
No more limits :)
26-Apr-2005 08:00
I needed a file uploader for a client a little while ago, then the client didn't want it, so I'll share with all of you. I know I hated coding it, it was confusing (for me anyway), but I made it fairly simple to use:
<?
function uploader($num_of_uploads=1, $file_types_array=array("txt"), $max_file_size=1048576, $upload_dir=""){
if(!is_numeric($max_file_size)){
$max_file_size = 1048576;
}
if(!isset($_POST["submitted"])){
$form = "<form action='".$PHP_SELF."' method='post' enctype='multipart/form-data'>Upload files:<br /><input type='hidden' name='submitted' value='TRUE' id='".time()."'><input type='hidden' name='MAX_FILE_SIZE' value='".$max_file_size."'>";
for($x=0;$x<$num_of_uploads;$x++){
$form .= "<input type='file' name='file[]'><font color='red'>*</font><br />";
}
$form .= "<input type='submit' value='Upload'><br /><font color='red'>*</font>Maximum file length (minus extension) is 15 characters. Anything over that will be cut to only 15 characters. Valid file type(s): ";
for($x=0;$x<count($file_types_array);$x++){
if($x<count($file_types_array)-1){
$form .= $file_types_array[$x].", ";
}else{
$form .= $file_types_array[$x].".";
}
}
$form .= "</form>";
echo($form);
}else{
foreach($_FILES["file"]["error"] as $key => $value){
if($_FILES["file"]["name"][$key]!=""){
if($value==UPLOAD_ERR_OK){
$origfilename = $_FILES["file"]["name"][$key];
$filename = explode(".", $_FILES["file"]["name"][$key]);
$filenameext = $filename[count($filename)-1];
unset($filename[count($filename)-1]);
$filename = implode(".", $filename);
$filename = substr($filename, 0, 15).".".$filenameext;
$file_ext_allow = FALSE;
for($x=0;$x<count($file_types_array);$x++){
if($filenameext==$file_types_array[$x]){
$file_ext_allow = TRUE;
}
}
if($file_ext_allow){
if($_FILES["file"]["size"][$key]<$max_file_size){
if(move_uploaded_file($_FILES["file"]["tmp_name"][$key], $upload_dir.$filename)){
echo("File uploaded successfully. - <a href='".$upload_dir.$filename."' target='_blank'>".$filename."</a><br />");
}else{
echo($origfilename." was not successfully uploaded<br />");
}
}else{
echo($origfilename." was too big, not uploaded<br />");
}
}else{
echo($origfilename." had an invalid file extension, not uploaded<br />");
}
}else{
echo($origfilename." was not successfully uploaded<br />");
}
}
}
}
}
?>
uploader([int num_uploads [, arr file_types [, int file_size [, str upload_dir ]]]]);
num_uploads = Number of uploads to handle at once.
file_types = An array of all the file types you wish to use. The default is txt only.
file_size = The maximum file size of EACH file. A non-number will results in using the default 1mb filesize.
upload_dir = The directory to upload to, make sure this ends with a /
This functions echo()'s the whole uploader, and submits to itself, you need not do a thing but put uploader(); to have a simple 1 file upload with all defaults.
22-Apr-2005 03:59
I had some problems with uploading files because of the path .So to save you some problems. if you get an error like "failed to open stream: No such file or directory in ..." it's likely because your not specifing the full path of the directory you want to upload.In other words you need to specify the full path and not the relative path in the second parameter.
Here is a small function to upload stuff. The files get their new name via last index from a database.
<?php
$name_tmp = $HTTP_POST_FILES['file']['tmp_name'];
//read temporay filename
$name = $HTTP_POST_FILES['file']['name'];
//read initial filename
if(is_uploaded_file($name_tmp)){
$ext =explode('.', $name);
$ext = $ext[count($ext)-1];
//get extension of uploaded file
$index=getLastIndex();//costum function
$path_parts = pathinfo(__file__);//get path info of curent php script
$dir = $path_parts['dirname']."\\uploads"; //full path of upload directory
$new = $dir."\\".$index.".".$ext;
if(move_uploaded_file($name_tmp,$new))
echo "File transfer succesfull.";
}
?>
03-Apr-2005 08:35
People have remarked that incorrect permissions on the upload directory may prevent photos or other files from uploading. Setting the Apache owner of the directory incorrectly will also prevent files from uploading -- I use a PHP script that creates a directory (if it doesn't exist already) before placing an uploaded file into it. When the script creates the directory and then copies the uploaded file into the directory there is no problem because the owner of the file is whatever Apache is running as, typically "nobody". However, lets say that I've moved the site to a new server and have copied over existing file directories using FTP. In this case the owner will have a different name from the Apache owner and files will not upload. The solution is to TelNet into the site and reset the owner to "nobody" or whatever Apache is running as using the CHOWN command.
31-Mar-2005 12:34
On windows XP, SP2, Explorer at times fails to upload files without extensions.
$_FILES array is null in that case. Microsoft says its a security feature(!)
The only solution we could comeup is to enforce uploaded file to have an extention.
24-Mar-2005 09:21
Well let me ask you this? Why would you compromise security doing this? Might as well just turn off IP tables, you're basically allowing any connections to any port on your server, bad move. I don't have those and have no problem uploading files.
"The iptables rules for this are as follows:
# allow all fragments
-A INPUT -f -j ACCEPT
# allow icmp traffic
-A INPUT -p icmp -j ACCEPT" <-- From guy below me...
On the bright side, this will also fix some issues with ssh and NFS =)
On another note, a smart programmer would also do checking on the files that are uploaded, making sure that they are the correct file, it is another breach in security not by checking the files you are uploading are in a web viewable area. Just my two cents...
14-Mar-2005 04:33
If you're having problems uploading large files but small files go through fine, here are some things to try:
- In the HTML form, make sure you've set MAX_FILE_SIZE to an acceptable value.
- In php.ini, be sure you've set the the upload_max_filesize and post_max_size to be large enough to handle your upload.
- In your httpd.conf (if you're using apache), check that the LimitRequestBody directive isn't set too low (it's optional, so it may not be there at all).
If those settings don't work, you can check your firewall configuration. When uploading large files, packets have to be split into fragments of varying size depending on your systems MTU (maximum transmission unit), which is typically 1500 bytes.
Because some systems send the packets with the headers last (or the header packet may be received after some of the data packets), firewalls can't filter this traffic based on destination port and address. Many firewalls (including iptables) have to be configured to allow fragments separately from standard traffic. Unfortunately, it's an all-or-nothing thing in these cases, and exploits based on packet fragmentation have been a problem in the past (teardrop, boink, etc.). Note that ICMP may be used to notify the host (your server) of oncoming fragmentation, so you may need to allow ICMP traffic as well.
The iptables rules for this are as follows:
# allow all fragments
-A INPUT -f -j ACCEPT
# allow icmp traffic
-A INPUT -p icmp -j ACCEPT
On the bright side, this will also fix some issues with ssh and NFS =)
Just to remind everyone, if you are wanting to upload larger files, you will need to change the value of both upload_max_filesize and post_max_size to the largest filesize you would like to allow. Then restart apache and everything should work.
27-Feb-2005 05:52
Regarding the post by therebechips below about saving attachments to a MySQL database. Here are some items that he forgot to mention:
Make sure your datafield is type text for storing the chunks in. base64_encode translates binary into text (in a nutshell).
Also, the max size for a text field is 65535. In his example he used 50,000 for the MAX_SQL chunks to put into the database. If you do this, the encoded data is too large to fit in the field and is truncated. Use 40,000 instead to be safe. It took me a few hours to realize why my images were coming back out of the database corrupted.
Other than that, his example worked very well.
If you want to email me, flip the two parts of my email address around and remove .nospam
David Hamilton
09-Feb-2005 07:52
This may help a newbie to file uploads.. it took advice from a friend to fix it..
If you are using
-windows xp
-iis 5
-php 5
If you keep getting permission errors on file uploads... and you have sworn you set the permissions to write to the directory in iis...
double check that
a) in windows explorer under tools > folder options
click the view tab
scroll down all the way to "use simple file sharing (recommended)"
uncheck this box
b) find the folder you wish to upload to on your server
c) click properties and then the security tab
d) make sure the appropriate write settings are checked.
you may want to test by setting "everyone" to have full permission....
BEWARE doing this will open up big security holes on your server....
hope this helps
Leevi Graham
09-Feb-2005 02:57
Just thought I'd add this since I had to search forever to find an answer.
When I used the enctype attribute on a form to process a file upload I had a problem redirecting back to an anchor point on the original page my code looked like this on the upload page:
header("Location: original_page.php#image_gal");
and the resulting url looked like this:
http://www.url.com/original_page.php
note the missing anchor reference. So my work around was to pass the anchor point as a variable and then redirect again when I got to the original page. A little bit chunky but it worked. Hope this helps someone.
07-Jan-2005 05:44
It's important to note that when using the move_uploaded_file() command, that some configurations (Especially IIS) will fail if you prefix the destination path with a leading "/". Try the following:
move_uploaded_file($tmpFileName,'uploads/'.$fileName);
Setting up permissions is also a must. Make sure all accounts have write access to your upload directory, and read access if you wish to view these files later. You might have to chmod() the directory or file afterwards as well if you're still getting access errors.
04-Jan-2005 11:48
Be sure to be careful with the $_FILES['userfile']['name'] array element. If the client uploads a file that has an apostrophe in the filename it WILL NOT get set to the full name of the file from the client's machine.
For example, if the client uploads a file named george's car.jpg the $_FILES['userfile']['name'] element will be set to s car.jpg because PHP appears to cut off everything before the apostrophe as well as the apostrophe itself.
This did not happen in some of the previous versions of PHP but I know that it happens in version 4.3.10 so watch out for this.
I thought this was a bug so I submitted it but it turns out that it is a "security measure"
15-Dec-2004 08:15
Hello everyone. I want to share to you that uploading will never work out of the box if you didn't set the upload_tmp_dir directive in your php.ini file in the first place. If you just compiled the source files as is and tried to upload, you're in for a big mess. I don't know the flags to pass to the configure script to tell php about the default temporary directory to place the uploaded files.
In case your php upload code won't do as expected, open up the php.ini file and set the upload_tmp_dir. Then restart the Apache server and you're set.
By the way, I'm using Linux Mandrake 10.1 Official and PHP 4.3.9 on Apache 2.0.49.
08-Nov-2004 07:37
mime_content_type() is better to use if you want to find if a file sent is really a jpeg or a plain text file. :)
27-Aug-2004 10:20
If your upload script is meant only for uploading images, you can use the image function getimagesize() (does not require the GD image library) to make sure you're really getting an image and also filter image types.
<?php getimagesize($file); ?>
...will return false if the file is not an image or is not accessable, otherwise it will return an array...
<?php
$file = 'somefile.jpg';
# assuming you've already taken some other
# preventive measures such as checking file
# extensions...
$result_array = getimagesize($file);
if ($result_array !== false) {
$mime_type = $result_array['mime'];
switch($mime_type) {
case "image/jpeg":
echo "file is jpeg type";
break;
case "image/gif":
echo "file is gif type";
break;
default:
echo "file is an image, but not of gif or jpeg type";
}
} else {
echo "file is not a valid image file";
}
?>
using this function along with others mentioned on this page, image ploading can be made pretty much fool-proof.
See http://php.net/manual/en/function.getimagesize.php for supported image types and more info.
19-Jun-2004 05:24
When uploading large images, I got a "Document contains no data" error when using Netscape and an error page when using Explorer. My server setup is RH Linux 9, Apache 2 and PHP 4.3.
I found out that the following entry in the httpd.conf file was missing:
<Files *.php>
SetOutputFilter PHP
SetInputFilter PHP
LimitRequestBody 524288 (max size in bytes)
</Files>
When this had been added, everything worked smoothly.
- Oli Jon, Iceland
11-May-2004 03:08
Note that with magic_quotes_gpc on, the uploaded filename has backslashes added *but the tmp_name does not*. On Windows where the tmp_name path includes backslashes, you *must not* run stripslashes() on the tmp_name, so keep that in mind when de-magic_quotes-izing your input.
16-Apr-2004 08:43
IE on the Mac is a bit troublesome. If you are uploading a file with an unknown file suffix, IE uploads the file with a mime type of "application/x-macbinary". The resulting file includes the resource fork wrapped around the file. Not terribly useful.
The following code assumes that the mime type is in $type, and that you have loaded the file's contents into $content. If the file is in MacBinary format, it delves into the resource fork header, gets the length of the data fork (bytes 83-86) and uses that to get rid of the resource fork.
(There is probably a better way to do it, but this solved my problem):
<?php
if ($type == 'application/x-macbinary') {
if (strlen($content) < 128) die('File too small');
$length = 0;
for ($i=83; $i<=86; $i++) {
$length = ($length * 256) + ord(substr($content,$i,1));
}
$content = substr($content,128,$length);
}
?>
02-Mar-2004 07:54
On a similar note to jim dot dam at sympatico dot ca 27-Feb-2002 09:13
Browsers intepret png upload type differently too eg.
print_r() output from Mozilla 1.6
Array ( [name] => eg1.png [type] => image/png [tmp_name] => /var/tmp/phpIJd4FL [error] => 0 [size] => 66614 )
print_r() output from IE 6
Array ( [name] => eg1.png [type] => image/x-png [tmp_name] => /var/tmp/phpHJ04Dh [error] => 0 [size] => 66614 )
Note the difference of image/png and image/x-png type intepretation of the same image file.
Further note:
http://www.cti.ecp.fr/documents/tests/png.html
11-Feb-2004 05:37
From the manual:
If no file is selected for upload in your form, PHP will return $_FILES['userfile']['size'] as 0, and $_FILES['userfile']['tmp_name'] as none.
As of PHP 4.2.0, the "none" is no longer a reliable determinant of no file uploaded. It's documented if you click on the "error codes" link, but you need to look at the $_FILES['your_file']['error']. If it's 4, then no file was selected.
06-Feb-2004 02:20
when you upload the file, $_FILES['file']['name'] contains its original name converted into server's default charset.
if a name contain characters that aren't present in default charset, the conversion fails and the $_FILES['file']['name'] remains in original charset.
i've got this behavior when uploading from a windows-1251 environment into koi8-r. if a filename has the number sign "¹" (0xb9), it DOES NOT GET CONVERTED as soon as there is no such character in koi8-r.
Workaround i use:
<?php
if (strstr ($_FILES['file']['name'], chr(0xb9)) != "")
{
$_FILES['file']['name'] = iconv (
"windows-1251",
"koi8-r",
str_replace (chr(0xb9), "N.", $_FILES['file']['name']));
};
?>
06-Sep-2003 11:02
Re: Handling uploads and downloads of large files and storing in MySQL.
Use two tables to store data about the file and the file data itself. ***Important: to preserve the integrity of the data use base64_encode() NOT addslashes().
<?php
// Max packet size
define("MAX_SQL",50000);
$filehandle = fopen($tmp, "rb") or die( "Can't open file!" );
$query= "INSERT INTO files (name, type, size) VALUES(".
$DB->quote($name).", ".
$DB->quote($type).", ".
$DB->quote($size).
")";
// Execute Query
$result = $DB->query($query);
$file_id = mysql_insert_id();
// Copy the binary file data to the filedata table in sequential rows each containing MAX_SQL bytes
// Your table should have an index set to auto_increment
// Store the file_id to identify the data fragments
while (!feof ($filehandle)) {
$data = base64_encode(fread($filehandle,MAX_SQL));
$query = "INSERT INTO filedata (file_id, data) VALUES($file_id,\"".$data."\")";
$result = $DB->query($query);
}
fclose ($filehandle);
?>
Decode the data fragments and recombine them:
<?php
$file_id =$_GET ['file_id'];
$query ="select file_id, name, type, size from files where file_id='$file_id'";
$result = $DB->query($query);
$row= mysql_fetch_array ($result);
$type = $row ["type"];
$name = $row ["name"];
$size = $row ["size"];
$file_id = $row ["file_id"];
// get the file data
$query = "select id, data from filedata where file_id='$file_id' ORDER by id";
$result = $DB->query($query);
// decode the fragments and recombine the file
$data = "";
while ($row = mysql_fetch_array($result)) {
$data .= base64_decode($row ["data"]);
}
// output the file
header ("Content-type: $type");
header ("Content-length: $size");
header ("Content-Disposition: attachment; filename=$name");
header ("Content-Description: PHP Generated Data");
echo $data;
?>
12-Aug-2003 11:22
Progress bar support has been a recurring theme in many a PHP mailing list over the years. You can find a free progress monitor component for PHP file uploads at http://sourceforge.net/projects/megaupload/
The advantage of this system is that you do not have to apply any patches to PHP to make use of it.
25-Mar-2003 09:22
SECURITY CONSIDERATION: If you are saving all uploaded files to a directory accesible with an URL, remember to filter files not only by mi