Re: [RFC] Multibyte char handling

Hi all, On Sat, Jan 18, 2014 at 5:06 AM, Julien Pauli <jpauli@php.net> wrote: > Like everybody, I' absolutely against adding an "encoding" parameter > to ext/standard functions or relying on unreliable system locale. > Like Nikita says, every multibyte function should go to ext/mbstring , > and nowhere else, please , do not turn PHP into something even more > dirty as it is nowadays :-p > > I'm +1 to embed and activate mbstring by default in future PHP releases. > However, this has already been discussed (from what I remember) and I > dont remember why we ended with a "no" end-word, could we be refreshed > about this ? > > I'm not in favor of magic things. Magically replacing PHP strings by > mb_ implementation is a really bad idea. We should keep the INI > parameter about this alive though (mbstring.func_overload), so that > people that explicitely want to activate such a magic can do it if > they want to. > > I'm +1 also to start a "serious" (hum) discussion about multibyte/PHP6 > , we've been saying this for years : we need native support of unicode > in PHP :-p The actual problem we are facing once again shows this. > It seem this is the majority excluding INI usage. I updated the RFC to reflect this. https://wiki.php.net/rfc/multibyte_char_handling - Compile mbstring by default from 5.6 - Add mb_*() functions for 5.3 and up - Keep ext/standard function as it is now Open Issue - Use of INI for overriding single byte string functions by mbstring functions. I would like to consolidate code location 5.6 and up because of the history of mbstring function remain insecure. e.g. When parse_str()/mail() security issue was fixed, mb_parse_str()/mb_send_mail() didn't fixed. However, refactoring isn't mandatory. We could have 2 different codes that are mostly the same. We may postpone refactoring until PHP6. Please don't forget to update mbstring code when anyone update ext/standard. If there are opinions/open issues/questions, please reply. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net