Req #22108 [Com]: php doesn't ignore the utf-8 BOM

Edit report at https://bugs.php.net/bug.php?id=22108&edit=1 ID: 22108 Comment by: manuel dot schmitz at liebherr dot com 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: In my view, the BOM is a meta information for the PHP parser and not part of the content. It should not be forwarded to the output. Please provide an reason for the "Wont fix" status. I am sure that there is a good reason, but I would like to know about it. Previous Comments: ------------------------------------------------------------------------ [2016-08-09 21:25:18] marc dot fauser+php at fauser dot ag 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. ------------------------------------------------------------------------ [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! ------------------------------------------------------------------------ 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