Edit report at https://bugs.php.net/bug.php?id=22108&edit=1
ID: 22108
Comment by: marc dot fauser+php at fauser dot ag
Reported by: bugzilla at jellycan dot com
Summary: php doesn't ignore the utf-8 BOM
Status: Wont fix
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: *
PHP Version: *
Assigned To: moriyoshi
Block user comment: N
Private report: N
New Comment:
I was looking why my site stopped working after I tried to add
declare(strict_types=1);
The error log told me that it must be the first command in the php file. It was. After an hour I
figured out that the UTF8 BOM caused the issue.
Previous Comments:
------------------------------------------------------------------------
[2015-09-25 22:50:47] vittorio dot zamparella at gmail dot com
BUMP!
Come on! it's almost a 13 years old bug, It deserves a good party!
I'm just about to overhaul a php software and it's very annoying that I'll have to
use only no-BOM utf8 files. Doesn't make look php very professional. Especially considering
that php outputs utf by default since forever.
Php misworkings with BOMs are subtles and very hard to detect.
On the other hand BOMs are very useful to sign utf8 files, to stay protected from casual notepad
edit, to allow for legacy 8bit encoded parts of a site or program and many other applications.
The defaulting to "on" of output buffering masked the "headers already sent"
problem; but that's a masking, not a solution: php still outputs a BOM when it's not
requested to (eg an image) and a simple ob_flush() reveals it.
UTF Encoding was smart enough to put the BOM in a point that means "zero width space", so
that mid-page BOMS don't distrupt much browser. But again the problem still exist: http://www.w3.org/International/questions/examples/phpbomtest.php
a character that's not supposed to be, a line that shouldn't be.
I don't understand the won't fix: at least half of the solution is clear to me:
include() and require() should simply strip the BOM, that's for sure.
While for the initial BOM, if present I would output it after the headers if the output encoding is
utf, ie the mimetype belongs to the text family (html, css and so on); instead php should strip the
BOM for -say- image/jpg and application/whatever.
It's a simple algorithm (a bunch of ifs) and lightweight (just examing first three bytes of
buffer). It may not cover ALL the possible situations, but it's not dangerous and it
doesn't risk to make things worse.
Want an even simpler algorithm? strip_bom=true option and strip it always!
Browsers won't ever receive the BOM and will have to manage with http headers and html meta
(has it has been for years).
That would even be an acceptable bridge to a smarter solution: webmasters could enable the BOM
stripping when the project needs it.
Please, remove the won't fix. Give this bug a chance to get fixed!
------------------------------------------------------------------------
[2013-07-04 21:50:19] mckeever at web dot de
I know this bug entry is old. But why is the BOM-problem set to "Wont fix"?
The last comment said the support will come with PHP 6. We all know PHP 6 is dead.
PHP 5.5.0 has been released a week ago. But the problem persists.
Since it can not be guaranteed to have no BOMs in all files which gets included
PHP should be able to recognize and ignore them. There is not only the problem of
the "Headers already sent" but also NameSpacing doesn't work with BOM-infected
files.
------------------------------------------------------------------------
[2005-08-22 18:35:06] derick@php.net
This will come with Unicode support in PHP 6.0
------------------------------------------------------------------------
[2005-08-22 18:32:38] jwagner at cc dot hut dot fi
PHP 5.0.4 for Windows /still/ does not seem to have it (enable-zend-multibyte) enabled by default.
For example session_start() is broken for UTF-8 encoded php files. I would strongly suggest to make
enable-zend-multibyte a default for the windows release!
------------------------------------------------------------------------
[2005-01-12 23:43:27] lapo at lapo dot it
> Is it possible to port this support for windows too?
Of course I quoted the wrong like, zend-multibyte support is POSSIBLE (not DEFAULT) in the Windows
version.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=22108
--
Edit this bug report at https://bugs.php.net/bug.php?id=22108&edit=1