Bug #74312 [Com]: Filter BOMs out of PHP output
[email protected] ("furun at arcor dot de")
| Newsgroups | php.bugs |
|---|---|
| Message-ID | <[email protected]> |
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: This is rhetoric to protect a dogma, not a technical argument. If a syntax definition is acting like a pitfall, it should be changed. Bug prevention is the contrary of randomness. Human errors are random, and bug prevention takes them out of the way. The write development strategies is to see, how many time is a ending newline/empty-char intended, and how many time coders are stumble over it unintended. And then take unwanted randomness out of the no-game, if indented newlines/empty-chars are very rare and can be done more explicit. In the middle of a PHP and HTML mixed script, precision for <?php ?> delimitations makes sense, and should not be faded. Tanks that there is no enforcement to use ending ?>, they are useless anyway, specially in near 100% php code scripts. Smart coders don't write any ending ?> to safe there time. But i see the empty-char after last ?> as not so buggy like the BOM, but i miss the good infos and experiences to decide what is best. A very active php community forum helper maybe can tell, how often this becomes a pitfall, and if it makes sense to chance definitions. (Just frequenting forums sometime, i seen it many time, ?>.. seems to be a pitfall for me.) Previous Comments: ------------------------------------------------------------------------ [2017-04-01 02:40:31] spam2 at rhsoft dot net > And yes, why not do a implicit trim() because when i want a gambling machine i use a gambling machine and not a programming language ------------------------------------------------------------------------ [2017-03-31 20:02:20] [email protected] Okay, re-opening and bailing out of this discussion. Thanks! ------------------------------------------------------------------------ [2017-03-31 19:51:45] furun at arcor dot de > IT WAS written here - anything outside <?php ?> is NOT part of the php script This is the dev-dogma in question. It is not a technical reason, but a dogma. php-scripts are written from humans in text files, not from machines in binary files. And yes, why not do a implicit trim(). There is no technical reason why not. In most cases the extra empty chars after last "?>" are not indented, a trim() prevents human imperfectness. (My maintenance script deletes the last ?> and all empty chars after. regex = "?>\s+$") Explicit newlines can be done in code, in the rare cases where this is indented. PHP does implicit ignorer 1 newline after ?> > where will you start here and where will you stop? The candle of worms is not so deep, i start by deleting the BOM at [BoF] before <?php, and stop by trim after ?> [EoF]. Otherwise the PHP community will bug-hunt and work-around and forum-help this even in decades from now. Or stop simply by deleting the BOM, in case there are technical reasons not to trim. ------------------------------------------------------------------------ [2017-03-31 13:24:47] spam2 at rhsoft dot net > 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()" ------------------------------------------------------------------------ [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 ------------------------------------------------------------------------ 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