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 [email protected] to get a copy of this message
On Fri, Jan 17, 2014 at 10:34 PM, Yasuo Ohgaki <[email protected]> wrote:
> Hi all,
>
> On Sat, Jan 18, 2014 at 5:06 AM, Julien Pauli <[email protected]> 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
> [email protected]
>


Julien


Thread (31 messages)

« previous php.internals (#71214) next »