FAQ
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

Search Discussions

  • Johannes Schlüter at Jul 29, 2010 at 9:58 pm
    Hi,
    On Thu, 2010-07-29 at 21:26 +0200, Ferenc Kovacs wrote:
    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
  • Ferenc Kovacs at Jul 29, 2010 at 10:33 pm

    2010/7/29 Johannes Schlüter <johannes@schlueters.de>:
    Hi,
    On Thu, 2010-07-29 at 21:26 +0200, Ferenc Kovacs wrote:
    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
    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
  • Ferenc Kovacs at Jul 29, 2010 at 10:36 pm

    2010/7/30 Ferenc Kovacs <info@tyrael.hu>:
    2010/7/29 Johannes Schlüter <johannes@schlueters.de>:
    Hi,
    On Thu, 2010-07-29 at 21:26 +0200, Ferenc Kovacs wrote:
    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
    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
  • Johannes Schlüter at Jul 29, 2010 at 10:49 pm
    Hi,
    On Fri, 2010-07-30 at 00:33 +0200, Ferenc Kovacs wrote:
    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.
  • Ferenc Kovacs at Jul 29, 2010 at 10:54 pm

    2010/7/30 Johannes Schlüter <johannes@schlueters.de>:
    Hi,
    On Fri, 2010-07-30 at 00:33 +0200, Ferenc Kovacs wrote:
    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.
    I see your point.

    I can not come up anything better than your first idea.

    Tyrael

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedJul 29, '10 at 7:26p
activeJul 29, '10 at 10:54p
posts6
users2
websitephp.net

People

Translate

site design / logo © 2022 Grokbase