Hi.
Could we set the --enable-zend-multibyte configure option to be
enabled by default for the trunk?
http://bugs.php.net/bug.php?id=22108
Tyrael
Hi,
Hi.
Could we set the --enable-zend-multibyte configure option to be
enabled by default for the trunk?
http://bugs.php.net/bug.php?id=22108
Ignoring the BOF might cause not expected behavior: Assume people are
using PHP as "templating" language and want the BOM to go out to the
client. So the fix for this might be to store the BOM, then wait till
the first other output is being made and then send BOM+output. This
would cost some little parsing time and maybe a bit more.
The Zend Multibyte mode has a few more effects, like changing the
encoding of parsed files in memory etc. which cost time and might have
other consequences, this should be kept as a feature for the ones
knowing what it does (they actually might document it better ;-))
johannes
2010/7/29 Johannes Schlüter johannes@schlueters.de:
Hi,
Hi.
Could we set the --enable-zend-multibyte configure option to be
enabled by default for the trunk?
http://bugs.php.net/bug.php?id=22108Ignoring the BOF might cause not expected behavior: Assume people are
using PHP as "templating" language and want the BOM to go out to the
client. So the fix for this might be to store the BOM, then wait till
the first other output is being made and then send BOM+output. This
would cost some little parsing time and maybe a bit more.The Zend Multibyte mode has a few more effects, like changing the
encoding of parsed files in memory etc. which cost time and might have
other consequences, this should be kept as a feature for the ones
knowing what it does (they actually might document it better ;-))johannes
Do you think that this is a common scenario?
Apart from a case, when I had to create utf-8 csv files for Microsoft
Excel, I never needed to send BOM from php, and for that particular
case, I sent it with an explicit echo, not with an "invisible" control
sequence in my code.
Tyrael
Tyrael
Tyrael
2010/7/30 Ferenc Kovacs info@tyrael.hu:
2010/7/29 Johannes Schlüter johannes@schlueters.de:
Hi,
Hi.
Could we set the --enable-zend-multibyte configure option to be
enabled by default for the trunk?
http://bugs.php.net/bug.php?id=22108Ignoring the BOF might cause not expected behavior: Assume people are
using PHP as "templating" language and want the BOM to go out to the
client. So the fix for this might be to store the BOM, then wait till
the first other output is being made and then send BOM+output. This
would cost some little parsing time and maybe a bit more.The Zend Multibyte mode has a few more effects, like changing the
encoding of parsed files in memory etc. which cost time and might have
other consequences, this should be kept as a feature for the ones
knowing what it does (they actually might document it better ;-))johannes
Do you think that this is a common scenario?
Apart from a case, when I had to create utf-8 csv files for Microsoft
Excel, I never needed to send BOM from php, and for that particular
case, I sent it with an explicit echo, not with an "invisible" control
sequence in my code.Tyrael
Tyrael
Tyrael
sorry, that was some crazy signature. :)
About your other notes abou the --enable-zend-multibyte : if it
changes more than this behavior, then I'm in favor leaving this as is,
but discarding the BOM from by default.
Tyrael
Hi,
Ignoring the BOF might cause not expected behavior: Assume people are
using PHP as "templating" language and want the BOM to go out to the
client.
Do you think that this is a common scenario?
Apart from a case, when I had to create utf-8 csv files for Microsoft
Excel, I never needed to send BOM from php, and for that particular
case, I sent it with an explicit echo, not with an "invisible" control
sequence in my code.
Well, PHP doesn't change what is written outside <?php ?> (*) so hiding
"random" bytes (PHP doesn't know what these bytes mean, PHP only knows
collections of bytes as strings with no further logic) might easily
break expectations and cause problems which are harder to trace down
than a "headers already sent" error which is relatively verbose.
johannes
*) Yes there is one behavior which might be seen as an exception: If ?>
is directly followed by a new line the new line is dropped, but then the
new line can be seen part of the ?>.
Example:
a<?php
?>
b
Prints
ab
without line break.
2010/7/30 Johannes Schlüter johannes@schlueters.de:
Hi,
Ignoring the BOF might cause not expected behavior: Assume people are
using PHP as "templating" language and want the BOM to go out to the
client.Do you think that this is a common scenario?
Apart from a case, when I had to create utf-8 csv files for Microsoft
Excel, I never needed to send BOM from php, and for that particular
case, I sent it with an explicit echo, not with an "invisible" control
sequence in my code.Well, PHP doesn't change what is written outside <?php ?> (*) so hiding
"random" bytes (PHP doesn't know what these bytes mean, PHP only knows
collections of bytes as strings with no further logic) might easily
break expectations and cause problems which are harder to trace down
than a "headers already sent" error which is relatively verbose.johannes
*) Yes there is one behavior which might be seen as an exception: If ?>
is directly followed by a new line the new line is dropped, but then the
new line can be seen part of the ?>.Example:
a<?php
?>
bPrints
ab
without line break.
I see your point.
I can not come up anything better than your first idea.
Tyrael