Great to see you listened to our suggestions! Thanks
Attention: you have left PHP tags in ’FileDownload2.0.php’!
What has left unimplemented from my original post:
Quote from: grad at Sep 26, 2006, 03:15 AM
1. Filenames with non-ASCII characters do not display properly and are can not be downloaded (en error occurs). Seems like endcoding of filenames should be used.
It is a real problem with languages using non-ASCII characters. The files should be served with descriptive names and I can’t require editors to change the file names to ASCII-compatible.
I was playing a little with your code and thought of a possible solution. The problem with non-ASCII characters in filenames is not in reading them by script but in serving them to the browser. Resolving this would require to provide a name the file it should be listed and served with which would replace the filename read by the script. In short - the script should serve the ’title’ of the file (of course only when it has been provided) instead of its real filename. I modified a piece of your code and came to a working prototype:
<?php
$folder = '/files';
$folder = trim($folder," \t\\/");
$file = 'file.ext'; // the real file name as in the filesystem
$fileTitle = 'The file title.ext'; // the 'title' of the file
/* End parameters. Do not change the code below!
----------------------------------------------- */
# Send the user their download
$fp = fopen($file,"r");
$filedata=fread($fp,filesize($file));
fclose($fp);
header('Pragma: private');
header('Cache-control: private, must-revalidate');
header('Content-type: ' . mime_content_type($file)); // check it!
header ('Content-Length: ' . filesize($file));
if (preg_match('#MSIE ([0-9].[0-9]{1,2})#', getenv('HTTP_USER_AGENT')))
{
header('Content-Disposition: attachment; filename="' . rawurlencode($fileTitle) . '"');
}
else // Opera, Gecko family and others
{
header('Content-Disposition: attachment; filename="' . $fileTitle . '"');
}
print($filedata);
?>
Because the snippet uses the filesystem it assumes that files will be added through it, ie. FTP, network share or similar. Following that logic it would be the most natural for the user to provide the ’titles’ (if needed) also by that way, that is in a file specific for a given folder. I thought of using a single text file with uniform name that would serve as a library that contains:
- filename,
- a file exclusion marker (ie. by default all files of specified type should be listed, but if the user wants to exclude a specific file he should mark it with, say, ’0’; this should also allow to include a file which is excluded by the filter by marking it with ’1’),
- a title for the file (if empty, then the filename should be used),
- a description for the file
- a count download marker (ie. to count it or not with logic analogous to the inclusion marker)
- a count number (updated by the snippet).
All fields (except filename) could be empty. A record of the library file might look like (assuming double pipe as a field separator):
file.txt||1||title to display and serve on downloading.txt||A description.||1||1234
Keeping the library file within the filesystem has an advantage of using any way of generating it and resolves a problem of access permissions. Keeping it in the is not so flexible.
It is up to you to decide if you wish to use my idea or not. I think it would add to usability.
Quote from: grad4. File size is displayed with incorrect (non-standard) abbreviations. For bytes it should be ’B’, for kilobytes - KB’, and for megabytes - ’MB’, and for gigabytes - ’GB’. See byte in Wiki.
Notice: Because the binary meaning differs from the physical defined with SI prefixes it is advised to use their uppercase variation. Thus instead of the SI kB for kilobytes one should use KB.
This one is not a big issue. However it would be nice to use standardized abbreviations.