ID: 22108 Comment by: trunghongnguyen at yahoo dot com Reported By: bugzilla at jellycan dot com Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: * Assigned To: moriyoshi New Comment:
ertre Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2003-02-07 23:13:07] bugzilla at jellycan dot com The BOM (byte order mark) is a few bytes at the very front of a file that act as a signature denoting what type of encoding has been used, and in UTF16/32 it also makes the byte order (LE or BE). Although utf-8 is byte order independent, it has become popular on windows (perhaps not so on unix) to make use of the BOM encoded in UTF-8 to flag the file as being in UTF-8 format. This allows editors to determine the type of the file from the first few characters instead of trying to guess what type the file is. Ref: Textpad 4.6 (http://textpad.com) See the Unicode FAQ for details of the utf-8 BOM... http://www.unicode.org/unicode/faq/utf_bom.html#25 The use of this should be obvious, you have to leave the my-language-only mindset that afflicts too many programmers (myself included before this job) and think about the growing multiplicity of languages on the web. I am writing web applications in Japan, with European language and CJK (Chinese/Japanese/Korean) language processing and interfaces. Thus I have php files where variable values are strings of all sorts of languages - hence utf-8 encoding. I feel that this is definitely a bug in php. Considering that: * php is slowly growing into a language-neutral (i18n/l10n possible) language * php is designed such that php commands can be liberally sprinkled through html, and html is increasing encoded in utf-8 these days * the utf-8 bom is becoming increasingly popular for reasons of indentifying the file character format * if the utf-8 bom exists php actually outputs it incorrectly and in doing so prevents header output I request that you don't see this as a feature request, but as a bug in the handling of utf-8 files. Whether the output generator is the correct characterization of this bug or not I leave up to you. Regards, Brodie. ------------------------------------------------------------------------ [2003-02-07 08:46:36] bugzilla at jellycan dot com Problem: When a php file is saved in utf-8 format with the UTF-8 BOM as the first three bytes of the file (EF BB BF), PHP doesn't ignore these bytes when loading and compiling the file, but instead considers them output coming prior to the <?php. This causes incorrect display of the page and failure of any http header output. It does this even when the internal character format is set in php.ini to be utf-8. Desired outcome: PHP recognizes the utf-8 bom and disregards it. ------------------------------------------------------------------------ -- Edit this bug report at http://bugs.php.net/?id=22108&edit=1
