# --enable-zend-multibyte - Thread: https://externals.io/message/49175 - Original archive: https://news-web.php.net/php.internals/49175 - Started by Ferenc Kovacs on 2010-07-29T19:26:21+00:00 - Messages: 6 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #49175 — Ferenc Kovacs — 2010-07-29T19:26:21+00:00 URL: https://externals.io/message/49175#49175 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 --- ## #49177 — johannes@schlueters.de — 2010-07-29T21:58:01+00:00 URL: https://externals.io/message/49175#49177 · In reply to: #49175 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 --- ## #49178 — Ferenc Kovacs — 2010-07-29T22:33:43+00:00 URL: https://externals.io/message/49175#49178 · In reply to: #49177 2010/7/29 Johannes Schlüter : > 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. 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 --- ## #49179 — Ferenc Kovacs — 2010-07-29T22:36:14+00:00 URL: https://externals.io/message/49175#49179 · In reply to: #49178 2010/7/30 Ferenc Kovacs : > 2010/7/29 Johannes Schlüter : > > […] > > 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 --- ## #49180 — johannes@schlueters.de — 2010-07-29T22:49:28+00:00 URL: https://externals.io/message/49175#49180 · In reply to: #49178 Hi, > > […] > 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 (*) 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 b Prints ab without line break. --- ## #49181 — Ferenc Kovacs — 2010-07-29T22:54:31+00:00 URL: https://externals.io/message/49175#49181 · In reply to: #49180 2010/7/30 Johannes Schlüter : > Hi, > > > > […] > > > […] > > Well, PHP doesn't change what is written outside (*) 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 ?> > b > > Prints > > ab > > without line break. > > I see your point. I can not come up anything better than your first idea. Tyrael