Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:67495
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain adamharvey.name designates 209.85.223.169 as permitted sender)
MIME-Version: 1.0
Sender: adam@adamharvey.name
In-Reply-To: <CAH-PCH4w2YTwvHdPFFC-TygSBQpssv6woQJaoa3JVks1egq44g@mail.gmail.com>
References: <61BC4F17-86D9-4CBD-B185-58A2D4AFAE5F@rouvenwessling.de>
 <CAF+90c__m2zsi9ag32TAP+2yCFOj8gf_z4oNUxEoNCsJi-K1OQ@mail.gmail.com> <CAH-PCH4w2YTwvHdPFFC-TygSBQpssv6woQJaoa3JVks1egq44g@mail.gmail.com>
Date: Fri, 24 May 2013 08:34:31 -0700
Message-ID: <CADajX4BR_YA6y7UB-nqr=c9dJo-nprw2pYfOh+UmeT-kr1nRCA@mail.gmail.com>
To: Ferenc Kovacs <tyra3l@gmail.com>
Cc: Nikita Popov <nikita.ppv@gmail.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Proposal for better UTF-8 handling
From: aharvey@php.net (Adam Harvey)

On 24 May 2013 08:26, Ferenc Kovacs <tyra3l@gmail.com> wrote:
> On Fri, May 24, 2013 at 3:09 PM, Nikita Popov <nikita.ppv@gmail.com> wrot=
e:
>> We already have a lot of functions for multibyte string handling. Let me
>> list a few:
>>
>>  * The str* functions. Most of them are safe for usage with UTF8.
>> Exceptions are basically everything where you manually provide an offset=
,
>> e.g. writing substr($str, 0, 100) is not safe. substr($str, 0, strpos($s=
tr,
>> 'xyz')) on the other hand is.
>>  * The mb* functions. They work with various encodings and usually make =
of
>> of character offsets and lengths rather than byte offsets and lengths. T=
hey
>> are not necessary most of the time, but useful for the aforementioned
>> substr call with hardcoded offsets.
>>  * The Intl extension. This give you *real* unicode support, as in
>> collations, locales, transliteration, etc.
>>  * The grapheme* functions which are also part of intl. The work with
>> grapheme cluster offsets and lengths.
>>
>> Anyway, my point is that just adding *yet another* set of string functio=
ns
>> won't solve anything, just make things even more complicated than they
>> already are. I'm not strictly opposed to adding more functions if they a=
re
>> necessary, but one has to be aware of what there already is and how the =
new
>> functions will integrate.
>>
>> Nikita
>>
>
> did you just forgot the pcre functions with the /u modifier?!?!
> :P

And that's without even touching PECL. :)

I agree with Nikita =E2=80=94 I'm not against adding more Unicode/charset
handling functions if they make sense (and I haven't looked at the
code for this particular proposal yet), particularly if they'd be part
of a default build, but enough water has hopefully passed under the
bridge since the PHP 6 days that it might be time to canvass ideas on
a less piecemeal approach to character set handling and
internationalisation for PHP 5.5+1 or PHP 5.5+2.

Adam