php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #48885 finfo returns mime type + charset when FILEINFO_MIME is used
Submitted: 2009-07-11 12:46 UTC Modified: 2009-11-15 20:47 UTC
Votes:3
Avg. Score:4.3 ± 0.5
Reproduced:3 of 3 (100.0%)
Same Version:3 (100.0%)
Same OS:2 (66.7%)
From: majkl578 at gmail dot com Assigned:
Status: Closed Package: Filesystem function related
PHP Version: 5.3.0 OS: Linux Debian
Private report: No CVE-ID: None
 [2009-07-11 12:46 UTC] majkl578 at gmail dot com
Description:
------------
When finfo is used with FILEINFO_MIME flag for a file, it returns mime type + charset (in this format: mime/type; charset=foo


Configure Command:
'./configure' '--with-apxs2=/usr/local/apache2/bin/apxs' '--with-mysql' '--with-mysqli' '--with-curl' '--with-sqlite' '--with-gd' '--enable-mbstring' '--with-openssl' '--disable-short-tags' '--with-mcrypt' '--with-bz2' '--with-zlib' '--enable-zip' 

Reproduce code:
---------------
$obj = new \finfo(FILEINFO_MIME);
echo $obj->file('/tmp/phpbug'); //in file is plain text

Expected result:
----------------
text/plain

Actual result:
--------------
text/plain; charset=us-ascii

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2009-07-11 20:44 UTC] scottmac@php.net
This is correct, rfc2045 requires the character set to be there for mime type.
 [2009-07-11 21:15 UTC] majkl578 at gmail dot com
ok sorry for this.

but if it is correct, informations here: http://php.net/manual/en/function.finfo-file.php are misleading (see Example #1), because there is not mentioned anything about this, just about mime type.
 [2009-07-11 22:45 UTC] pajoye@php.net
pls update this example
 [2009-07-12 12:32 UTC] majkl578 at gmail dot com
Look:
I tested the code mentioned in bug report on php 5.2.10, i used a JPEG image:
On php 5.3.0 returns 'image/jpeg; charset=binary'
On php 5.2.10 returns 'image/jpeg' only.
So, my question is: is it a bug or a feature in 5.3?

If it's a feature:
1. it is NOT backward compatible.
2. it does not have any meaning for files like images etc, only for text files.

So?
 [2009-07-12 13:33 UTC] pajoye@php.net
The fileinfo extension has been bundled in PHP (5.3 and later). The development takes place only in PHP, not anymore in PECL.

Old releases may have issues or may not be compliant with the RFC. Like it or not, that's a fact.

For the binary data, the charset will obviously be set to binary:

image/gif; charset=binary

It is a documentation, not a bug neither a BC break.


 [2009-07-12 23:16 UTC] scottmac@php.net
As Pierre has said already this is the way libmagic works and it matches the RFC for mime type.

The charset on non text documents is also valid, even if it just says binary.

So there isn't a BC break here unless you were using the mime type for something else.
 [2009-07-26 21:43 UTC] matthew at zend dot com
I beg to differ a bit here with the assertion that the change is not a BC break.

Consider this: in versions prior to 5.3.0, one could do a match like this:

$finfo = new finfo(FILEINFO_MIME);
$type = $finfo->file($filename);
if (!in_array($type, array('image/jpeg', 'image/jpg'))) {
    echo "Invalid image type.";
} else {
    echo "JPEG found."
}

Now, with 5.3.0, this changes; the same assertion no longer works. This is in fact exactly an issue we had with Zend_Validate_File_MimeType when testing against PHP 5.3.0 -- matching that worked in 5.2.x now no longer works in 5.3.0. We have altered our library to handle the strings returned by both versions, but that exactly disproves your point: if the new behavior were BC, we wouldn't *need* to update our code.

I feel at the very least, the fact that the MIME type returned also includes encoding information, and the format of this encoding information, needs to be documented in the manual, and likely the UPGRADING guide.
 [2009-07-26 21:48 UTC] pajoye@php.net
Matthew,

That's exactly why the status of this report is set to "to be documented".
 [2009-07-26 22:31 UTC] scottmac@php.net
Matthew, you can get the behavior with PHP 5.2 if you link against a newer version of libmagic. This wasn't a change to any of the PHP wrapper code in this case.

So yes it might be a BC break for you, but in reality its a bug fix.
 [2009-07-27 02:55 UTC] scottmac@php.net
Looked into this tonight again and from 5.3+ there are two new constants available, FILEINFO_MIME_TYPE provides the old behavior.

I'll add them both to the documentation tonight.
 [2009-07-27 03:16 UTC] svn@php.net
Automatic comment from SVN on behalf of scottmac
Revision: http://svn.php.net/viewvc/?view=revision&revision=286383
Log: Update documentation to reflect change with the internal libmagic updates. See bug #48885
 [2009-07-27 05:26 UTC] philip@php.net
Which version of libmagic changed this? It should be added to the docs. 

Also, the docs don't mention how to link to libmagic nor mention that a 
bundled version is used [by default]. What's the situation? The only 
option I see with './configure --help' is --disable-fileinfo ...
 [2009-08-04 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-10-24 07:08 UTC] mohdyusuf at gmail dot com
I used to do a direct comparison, for example
if($mimeInfo = 'image/jpeg') ...

But then, with this changes, the comparison broke. Fortunately I have a custom findStr() function that does the job.
if(findStr('image/jpeg',$mimeInfo)) ...

this solved my problem easily.
 [2009-11-15 20:47 UTC] majkl578 at gmail dot com
scottmac: Thank you, the constant you've added works like a charm.

philip: On my Debian server, libmagic1 library is in version 4.26-1.

mohdyusuf: try this:
------
$obj = new finfo(FILEINFO_MIME_TYPE);
echo $obj->file('/tmp/whatever');
------


Thank you.
 [2012-07-04 11:57 UTC] soccertux at gmail dot com
Found this issue because we're experiencing a problem while downloading an image 
from a PHP server using a java client.

[quote pajoye@php.net]
For the binary data, the charset will obviously be set to binary:
image/gif; charset=binary
[/quote]
First binary is not a charset! The official charsets can be found here 
http://www.iana.org/assignments/character-sets and binary is not in this list. 

From rfc http://www.ietf.org/rfc/rfc2046.txt
A critical parameter that may be specified in the Content-Type field for 
"text/plain" data is the character set.

Again not for binary blobs... Java is failing on this because binary is an  
unsupported set.
 
PHP Copyright © 2001-2019 The PHP Group
All rights reserved.
Last updated: Fri Feb 22 09:01:25 2019 UTC