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: Re-Opened
Type: Bug
Package: Unicode Engine related
Operating System: Win7
PHP Version: 7.0.17
Block user comment: N
Private report: N
New Comment:
(nikic)
a) A technical argument could be, it could cause other problems if you just strip the BOM, and not
process some UTF-8/encoding stuf. php must/should maybe then care some how what the BOM says about
the encoding. My question would be then, if php still does not care about file encoding, would it
break something/more then leaf BOMs in the files? I think if a BOM is there, php could presume
correct and indented encoding. For UTF/encoding handling then is definitely the code responsible and
not php, even UTF error corrections. (i use a script for this. Far back, wen some software switched
from ASCII to UTF8, i have seen some confused files, and i fixed them by script, instead to manually
correct all [?]-characters).
I miss there maybe something, but my suggestion would be to just delete/ignore the BOM, and keep the
file as it is. (Keep the present behavior in default configuration.)
(I never used zend.multibyte, i like if php gives all out exactly as it is. The only exception is
BOM and empty chars after ?>, where i see recurring problems.)
b) A other technical argument is backwards compatibility. My suggestion is, if a BOM output is
intentional, it could be done explicit in code. And it would be a other bug source if a file not
have, but should have a BOM for the output. Because the BOM is in the editor likely only visible in
the options and not in the text editor it self, so not visible in first view (NotePad++ for
example). Explicit BOM export would be more clean. And i would speculate, a intentional export of a
BOM is way less probable, then a buggy behavior with unintentional BOMs. And a developer is focused
on this specific behavior to export BOMs, other then unintentional BOMs.
(PHP could define constants for all important BOMs, for explicit output, if not done already.)
The discussion i searched here is the possible backwards compatibility break, and if problems are
probable and recurring as unintended BOMs.
My opinion is, intentional BOM is rare, and the PHP5 > PHP7 upgrade is the right time to the
change, in case it breaks existing code, wen all developers are busy with maintenance and
compatibility anyway.
If the BOM and maybe even ?> handling is done behind an ini setting, its even better, it gives
developers the choice. The question and discussion is then, should it be the default setting to
handle or not handle the BOM by php. I would vote with my present opinion, to strip BOM by default
in ini setting, in PHP-7, maybe not in PHP-5(?) if backwards compatibility is a big issue.
The big question is, is BOM and empty chars after ?> a recurring and potentially nasty issue?
In my opinion it is, which could be fixed pragmatically simply by changing some php roles. Correct
my if i am wrong there.
Previous Comments:
------------------------------------------------------------------------
[2017-04-01 17:04:32] spam2 at rhsoft dot net
> to reeducate the entire planet
yes, because such "education" is a prerequisite anyways - or where you born with knowing
programming languages and even if why that one piece was missing
> or to take the stone out of the way
there is no stone - frankly looking at 90% of PHP code out there (leading to prohibit as much as
possible 3rd party code on our sevrers for a decade now) there are way too less stones checking if
someone should prdocuece code running on sevrers for which he is most of the time not responsile at
his own and innocent sysadmins and attacked 3rd party sites have to chew the outcome later
------------------------------------------------------------------------
[2017-04-01 15:39:10] nikic@php.net
Lets not start calling people idiots...
Here is a semi-recent internals thread on the topic of BOM handling: http://markmail.org/message/besjw22hxlpwlvdh
My opinion here is essentially this:
a) First, a philosophical point. PHP, in a default configuration, does not care about file encoding.
As long as it's ASCII compatible, PHP does not care whether your file uses UTF-8, ISO-8859-1 or
Windows-1251. PHP does not perform any validation or conversion, it gives you everything back
exactly as it received it. There *is* a special mode in which PHP does all these things, and
that's zend.multibyte. If this mode is enabled, PHP can convert character encodings, strip
BOMs, etc. Of course, we know that in practice there is very little interest in this.
b) Second, a practical point. You are considering the case where the BOM was accidentally introduced
by bad tooling (say, people writing PHP code in MS Word). However, it may also be introduced
*intentionally*, to be produced as part of the output. (For the sake of an example, assume you have
template files including BOMs, because you want to deliver a response with BOMs, as tooling on the
consuming side requires it.) If nothing else, this is a backwards compatibility break and a rather
subtle one at that. As such, such a change could probably only be made behind an ini setting, which
would probably not help with your particular concern.
------------------------------------------------------------------------
[2017-04-01 15:02:21] furun at arcor dot de
(spam2) I understand you there, but what is the easier way to do, to reeducate the entire planet, or
to take the stone out of the way.
People use there favorite tools, and unexperienced developers are publishing there first
plugins/codes for other software, user using it without possibility to proof, and professionals make
mistakes or search bugs on the wrong end (they then just not need forum help).
My arguments are there to held the php community which has to deal with it, and passive users with
no coding background, and time spend and wait for bug fixes, wen it goes wrong, an it will go wrong.
You as a experiences developer will not feel any harm anyhow, if BOM and ?> is cleaned, or not.
My effort here is for the "wild real-life, all out there".
------------------------------------------------------------------------
[2017-04-01 14:08:06] spam2 at rhsoft dot net
and problems have to be fixed where they are
* idiotic editors which add BOM to non-UTF16 files
* idiotic php editors hich add newlines at the end of the file
period
------------------------------------------------------------------------
[2017-04-01 14:05:59] spam2 at rhsoft dot net
> This is rhetoric to protect a dogma, not a technical argument
franly, if you did not realize it - i am not a php upstream-developer and so don't need to
protect any dogma - i am just a userland php-script developer for 15 years now, have written some
hundret thousand lines of php-code and frankly tell you if that are real issues for a developer he
RELLAY should stop develop software at all
------------------------------------------------------------------------
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