Bug #74312 [Com]: Filter BOMs out of PHP output
[email protected] ("spam2 at rhsoft dot net")
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=74312&edit=1 ID: 74312 Comment by: spam2 at rhsoft dot net Reported by: furun at arcor dot de Summary: Filter BOMs out of PHP output Status: Not a bug Type: Bug Package: Unicode Engine related Operating System: Win7 PHP Version: 7.0.17 Assigned To: cmb Block user comment: N Private report: N New Comment: > If there is a technical reason i miss, it was not written here IT WAS written here - anything outside <?php ?> is NOT part of the php script - where will you start here and where will you stop? the next step when open taht candle of worms is "Uhm if i have linebreaks after ?> in include files output-buffering, headers and sessins are broken, why does PHP not a implicit trim()" Previous Comments: ------------------------------------------------------------------------ [2017-03-31 13:10:43] furun at arcor dot de OK, like to summ up the points, and then i leave the discussion here. Principally it is never a good idea to put a warning shield in front of a stone in the way, "be careful about the stone", instead of just take him out of the way. Every work-around advice is a "shield in front of the stone" for maybe long "detour", and should only be used temporally in development time. In most of the cases is possible and better to take stones away, even if you have to use "dynamite". (To delete mysql and replace it with mysqli is "dynamite" for this example, because massive development on php site, and coding maintenance on the other. But its done now to get "stones" out of the way.) - You get me wrong if you think i want a fix for me, i fix it already in definite with a maintenance script, because i don't like to waste me life time for such things. I argue here for a reduction of wasted developers and users life time. For the fix of a really nasty bug-source, which could be easy fixed in php, with no compatibility pain. It needs maybe only 1 or few code lines. I write here a improvement request or bug report, not a help request in a forum. (Thanks anyway to the writers, for the work around help.) - "zend.multibyte + zend.detect_unicode", is a "shield in front of the stone". - "output_buffering", is a "shield in front of the stone". - "adjust tooling", is a "shield in front of the stone". People use there favorite tools. It is not a real-life advice, otherwise you can write something like "don't code bugs", and this bug report would become useless. Obviously real-life don't work like this. - "BOMs are meaningless for UTF-8", This is not really true, it tells a editor that he have to use UTF-8. I had scripts, again from 3. party, with mixed coding (ASCII and UTF8), and destroyed characters, because the editor was confused. Users use ugly and insecure things like this "<?php //äöü" to tell the tools to use UTF, and tools this "//Setup VIM: enc=utf-8 :". File headers are there to tell the software the data type and encoding, the UTF8 BOM is such a header. - "PHP didn't invent the BOM", is irrelevant, it exists and causes trouble. Browser developers have understand this and ignore BOMs since long time. (I had in the far past a typical problem with a JS file, again have to waste hours, and found the BOM-bug in a 3. party code far away from the buggy behavior. Same as php, and browsers now fix this bug source.) - "bug reports against third-part", is exactly the waste of time i argue here to stop, as close as possible to the source, instead of multiplying it to the outside to countless developers and users, and countless wasted life time hours, and bug reports, and forum workaround helps... It look for me only like a dev-dogma, without any real-life technical reasons. If there is a technical reason i miss, it was not written here. Why PHP should not delete [BoF]BOM<?php, AND even ?>\s+[EoF] issues, (because "?>\s+" it is the same problem type from the other end of the script). Specially now where many developers switch from php5 to php7 this could be done, if in some very rare cases it causes problems. thanks for reading (if you feel pain of reading this long text... you maybe see the problem ;-), by ------------------------------------------------------------------------ [2017-03-27 17:51:05] [email protected] > So countless developers have to care about this, instead of php > in central point... PHP didn't invent the BOM in the first place, and AFAIK a BOM was never intended for UTF-8 (but rather for UTF-16 were it is important). Anyhow, as nikic already said: adjust your tooling to not insert a BOM into UTF-8 encoded documents, and file bug reports against third-party libraries which ship UTF-8 encoded files containing a BOM. As *last* *resort* you can use output_buffering to mitigate BOM issues. [1] <http://php.net/manual/en/outcontrol.configuration.php#ini.output-buffering> ------------------------------------------------------------------------ [2017-03-25 22:06:24] furun at arcor dot de So countless developers have to care about this, instead of php in central point... In my case, the error came form a automatic update of a plugin form a third party. ------------------------------------------------------------------------ [2017-03-25 21:48:35] [email protected] IIRC it is possible to strip BOMs by using zend.multibyte together with zend.detect_unicode. However, I would strongly recommend against doing this. Instead, you should adjust whatever tooling you use to not insert BOMs for UTF-8 files. BOMs are meaningless for UTF-8 and Unicode recommends against their use. ------------------------------------------------------------------------ [2017-03-25 21:29:53] furun at arcor dot de I understand, but should this be a dogma in this case? In practice, a file has to be opened to process it, or in other words, php care about opening a source file to check if there is <?php code. The file handler could make a exception if a php-file is processed? I can not think of any practical use of this behafior, if a BOM must be send to output, it can be done in code... So it would be real-live solution. And dependent of the editor software behavior, no BOM can cause issues too. So would be nice if a BOM can be present in a PHP file, and be ignored in the output. I speculate it is a common and often appearing issue, so maybe deserves a exceptional treatment. (Thanks for your VERY quick response, this was the fastest ever ;-) (And sorry if a ask more, i am not a deep PHP-Dev insider.) ------------------------------------------------------------------------ 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=74312 -- Edit this bug report at https://bugs.php.net/bug.php?id=74312&edit=1