This is correct, rfc2045 requires the character set to be there for mime type.

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.

pls update this example

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?

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.

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.

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.

Matthew,

That's exactly why the status of this report is set to "to be documented".

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.

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.

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 ...

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".

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.

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.

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.