Re: [RFC] Multibyte char handling

From: Date: Fri, 17 Jan 2014 21:50:04 +0000
Subject: Re: [RFC] Multibyte char handling
References: 1 2 3 4 5 6  Groups: php.internals 
Request: Send a blank email to internals+get-71214@lists.php.net to get a copy of this message
On Fri, Jan 17, 2014 at 10:34 PM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > 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. Why is that an issue ? We just leave it as-is , or ? > > > 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 > Julien

« previous php.internals (#71214) next »