Edit report at https://bugs.php.net/bug.php?id=74312&edit=1
ID: 74312
Comment by: furun at arcor dot de
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:
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
Previous Comments:
------------------------------------------------------------------------
[2017-03-27 17:51:05] cmb@php.net
> 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] nikic@php.net
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.)
------------------------------------------------------------------------
[2017-03-25 21:08:18] spam2 at rhsoft dot net
This is simply not possible because the BOM is not part of the php output at all - php don't
and must not care about anything outside of <?php ?>
------------------------------------------------------------------------
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