Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71212
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAMUwpuRU3S3-BHGTAY5W1Jx+iTkT4QxQfV4ZoB6gMHk5EGXTrg@mail.gmail.com>
References: <CAGa2bXauxj6Sca8qYk2cxQ=TeG4bjWgcv-Aqy3cJe35ap72Yfw@mail.gmail.com>
 <CAF+90c-ZgsCczU71TJap1yeaNhKgQeoUR5oLKwwHHaoOD8z_ig@mail.gmail.com>
 <CAGa2bXb6jLX8HMN-rL7t5j5R_0SaeRkd5r4_MrmQFfsJxxaSxQ@mail.gmail.com>
 <1389976678.2057.8.camel@smugmug> <CAMUwpuRU3S3-BHGTAY5W1Jx+iTkT4QxQfV4ZoB6gMHk5EGXTrg@mail.gmail.com>
Date: Sat, 18 Jan 2014 06:34:43 +0900
Message-ID: <CAGa2bXZ_wjV-S98k5FeYKEAEPA_FMoZgxvWW8QB_QNh2s=1=ow@mail.gmail.com>
To: Julien Pauli <jpauli@php.net>
Cc: Mike <mike.php.net@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=089e01493f64d6972804f031512b
Subject: Re: [PHP-DEV] [RFC] Multibyte char handling
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--089e01493f64d6972804f031512b
Content-Type: text/plain; charset=UTF-8

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

--089e01493f64d6972804f031512b--