ID: 22108 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Feature/Change Request Operating System: Any PHP Version: All (as of the current implementation) New Comment:
derick, assuming that you wanted to create a version of the the example at http://www.php.net/manual/en/introduction.php#intro-whatis which displayed the text "Hi, I'm a PHP script" in multiple languages, how would you propose doing it? The only way is to use a form of unicode encoding. The least intrusive of these ways is utf-8 because it encodes the text in such a way that ascii characters (7 bit characters) are still plain ascii characters, and all encoded characters are always >128 and will never be mistaken for ascii. I haven't seen any documentation which states that php can only handle ascii text, please direct me to it if it exists. If there is some known problem with PHP parsing UTF-8 scripts, I haven't found it yet in a multitude of different files with different languages which PHP is parsing happily. The only problem that I have had is that any files which have an UTF-8 BOM, PHP is mistakenly outputting the BOM as input. This is a bug of PHP. The solution is easy, on loading a file, strip the BOM if it exists. Make it optional processing via a php.ini config argument if necessary. Don't be US-centric in your thinking, there is far more world existing outside those borders. Regards, Brodie. Previous Comments: ------------------------------------------------------------------------ [2003-02-08 04:24:12] [EMAIL PROTECTED] PHP doesn't want UNICODE scripts, but just ASCII ones. Not a bug -> bogus. ------------------------------------------------------------------------ [2003-02-08 02:01:11] [EMAIL PROTECTED] And assigning this task to me. ------------------------------------------------------------------------ [2003-02-08 01:48:15] [EMAIL PROTECTED] Yes, I suppose this might be a bug, but most of developers involved in PHP are not just so aware of this issue as you expected (and I had expected). So I thought that changing the category is a better choice than bogusing. ------------------------------------------------------------------------ [2003-02-07 23:13:07] [EMAIL PROTECTED] 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 21:41:23] [EMAIL PROTECTED] Because BOM issue has been referenced repeatedly as a header output preventer and we should be more aware of this, I don't see any reason we have to mark this report as bogus. Changing category from "output control" to a kind of "feature request". ------------------------------------------------------------------------ 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
