View Issue Details

IDProjectCategoryView StatusLast Update
0008819mantisbtbugtrackerpublic2010-05-11 11:52
ReporterStalker Assigned To 
Status newResolutionopen 
OSWindows XPOS VersionSP2 
Product Version1.1.1 
Summary0008819: Invalid filename when downloading file with non-US character set

When a file attached to an issue has a filename with a non_US characters in it's name (ex. Russian), file_download.php' produces an invalid file name (in IE, Firefox, etc.). This happens becauseurlencode' in file_download.php' doesn't behave as expected. Fixed this by replacingContent-disposition' with the following:
if (ereg('msie',strtolower($_SERVER['HTTP_USER_AGENT']))) {
header( 'Content-Disposition:' . $t_disposition . ' filename="'. utf8urlencode($t_filename) . '"' );
} else {
header( 'Content-Disposition:' . $t_disposition . ' filename="' . $t_filename . '"' );

Where `utf8urlencode' defined as:
function utf8urlencode($st) {
for ($i=0;$i<strlen($st);$i++) {
if ($k==32) {
} else if (($k<46) || ($k>126)) {
} else {
return $rc;

Please note that the header must be different for mozilla based browsers and for IE.

Additional Information

urlencode' also works for IE, but produces+' instead of spaces

TagsNo tags attached.




2008-04-16 09:30

reporter   ~0017610

Last edited: 2008-04-16 09:36

Thanks a lot, Stalker!
In addition i've discovered that function <b>file_get_extension</b> in core\file_api.php does not work correctly with unicode (e.g. Russian) file names because of using string variable as an array of chars.
To fix this you have to replace "$p_filename[$i]" by " mb_substr($p_filename,$i,1)" (keep in mind that mbstring library should be enabled in your php.ini).

Just replace whole function <b>file_get_extension</b> in core\file_api.php with following:


# Get extension given the filename or its full path.
function file_get_extension( $p_filename ) {
    $ext        = '';
    $dot_found  = false;
    $i          = mb_strlen( $p_filename ) - 1;
    while ( $i >= 0 ) {
        if ( '.' == mb_substr($p_filename,$i,1) ) {
            $dot_found = true;

        # foung a directoryarker before a period.
        if ( (  mb_substr($p_filename,$i,1) == &quot;/&quot; ) || (  mb_substr($p_filename,$i,1) == &quot;\\&quot; ) ) {
            return '';

        $ext =  mb_substr($p_filename,$i,1) . $ext;

    if ( $dot_found ) {
        return $ext;
    } else {
        return '';




2008-04-17 03:59

reporter   ~0017614

Last edited: 2008-04-17 04:11

One more remark about encodings.
We know that some attached files could be displayed in bug page in [show content/hide content] block (e.g. php, txt and so on).
When such file is attached to issue it's content will be downloaded and written inside span class ant then it will be shown in page.
The problem is that most text files in russia saved in windows-1251 encoding and mantis now works in utf8. In this case text in cp1251 shown in utf8 page without any conversion.
To correct this, go to core\file_api.php an look throu <b>file_list_attachments</b> function.
Find string <pre>echo htmlspecialchars( $v_content);</pre>
and insert following code before it:
<pre>if (mb_check_encoding($v_content,"cp1251")){
This should fix text encoding.
Also this may be useful for other non-latin users.



2008-09-15 06:58

reporter   ~0019397

Last edited: 2008-09-15 07:06

Thank you very much.

I believe mantis code should be rewrited so that every php non-utf-aware function is eliminated (or its arguments is preprocessed if possible) or replaced with mb_* equivalent.

But mbstring is not enabled on most non-russian configurations. That is why using mb_* stuff should be conditional, if mbstring lib is available.

IMHO the best solution is to implement a layer with equivalents to all non-utf-aware php stuff, which internally checks mbstring presence.



2010-05-11 11:52

reporter   ~0025471

I think it's fixed in 1.3.