ID:               22108
 Comment by:       lapo at lapo dot it
 Reported By:      bugzilla at jellycan dot com
 Status:           Assigned
 Bug Type:         Feature/Change Request
 Operating System: *
 PHP Version:      *
 Assigned To:      moriyoshi
 New Comment:

> How about making this --enable-zend-multibyte default option?

It is already available on Windows. In fact, I'm using it on a
production server since june 2003, with no problems and with many
satisfactions.

Any reason this is still not in by default?
Someone else is encountering bugs with it?


Previous Comments:
------------------------------------------------------------------------

[2005-01-06 21:08:05] [EMAIL PROTECTED]

How about making this --enable-zend-multibyte default option?
Is it possible to port this support for windows too?
And for 4.3.x branch?
Should it be marked open again?


------------------------------------------------------------------------

[2004-05-25 12:33:30] lapo at lapo dot it

Adding '--enable-zend-multibyte' to latest PHP5 port for FreeBSD for
sure solves the problem:

All files contain:
<?
header("Content-Language: it");
echo "������\n";
?>

cyberx [~] $ php /usr/tmp/utf8-bom.php 
� èéìòù
cyberx [~] $ php /usr/tmp/utf8Y-bom.php 
������
cyberx [~] $ php /usr/tmp/utf16-bom.php 
������
cyberx [~] $ php /usr/tmp/utf16BE-bom.php 
������
cyberx [~] $ php /usr/tmp/utf16LE-bom.php 
������

Except for "UTF8 without BOM" that is, of course, not distinguishable
from ISO8859-15 (default here), all theother formats are correctly
interpreted and outputted.
(notice that the 'header' instruction prior of the 'echo' one would
stutter with a non-BOM-aware PHP compile).

I wonder if and when this great multibyte support would be available by
default in Win32 compiles, I would really use it for work and am not
willing to but VisualC just to compile that ;-)
(though I'm trying compiling it with cygwin's gcc using '-mno-cygwin'
option, we'll see...)

------------------------------------------------------------------------

[2003-11-09 16:12:50] a9c83cd8bb41db324db5b449352f183 at arcor dot de

Thought about it... Now I think it's better when the BOM isn't part of
the output because that would cause trouble if you want to output
images or PDF or something like that...

------------------------------------------------------------------------

[2003-11-08 06:45:22] a9c83cd8bb41db324db5b449352f183 at arcor dot de

I think the best would be that PHP recognizes the BOM and outputs it
before it outputs the document (but after the HTTP headers, of course)
so that the document can still be recognized as UTF-8 when it's saved
to disk (where no Content-Type headers with a charset specification are
available).

------------------------------------------------------------------------

[2003-10-31 11:12:06] [EMAIL PROTECTED]

I added i18n support to Zend Engine 2 (though it's still partial
one...), and one of its features contain awareness of BOM. So now you
can gracefully parse scripts with BOM if you use PHP 5.0.0b2 and
configure it with the option '--enable-zend-multibyte'.

These features are still experimental and under testing, so that I have
not been documented these but I'll add the entry to the manual,
ZEND_CHANGES and so on if I feel certain of the stability and
robustness of my patch, though I do not know when it is:)

Anyway, I'll close this bug if '--enable-zend-multibyte' option in PHP
5.0.0b2 is assured to work well for this problem. Comments are welcome.

------------------------------------------------------------------------

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
    http://bugs.php.net/22108

-- 
Edit this bug report at http://bugs.php.net/?id=22108&edit=1

Reply via email to