Re: What "Unicode support" really means
| From: | Andrea Faulds | Date: | Wed, 05 Mar 2014 20:02:31 +0000 |
| Subject: | Re: What "Unicode support" really means | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72929@lists.php.net to get a copy of this message | ||
On 5 Mar 2014, at 19:50, Pierre Joye <pierre.php@gmail.com> wrote:
> On Wed, Mar 5, 2014 at 8:33 PM, Andrea Faulds <ajf@ajf.me> wrote:
>>
>> On 5 Mar 2014, at 08:29, Lester Caine <lester@lsces.co.uk> wrote:
>>> The first question that still has not been answered is whether there is a general
>>> consensus that the whole core should cleanly support UTF-8 or be restricted to a single byte subset?
>>> Don't mix 'locale' up with this! We need an acceptable 'global' set of
>>> rules which the core works to, for which a 'single byte locale' MAY be the preferred
>>> option for everyone?
>>
>> Yes, the entire core should and must support Unicode. Whether that be UTF-8 is a different
>> question, since we could also use UTF-32, for example.
>
> I do not think UTF-32 is even remotely an option. And both UTF-16 and
> UTF-32 bring us back to the initial issue we had with the previous
> unicode support attempt. UTF-16 is faster to process but the huge of
> conversions (to and from) kill any performance gains, even worst, it
> made php slower.
Right, UTF-8 is the only practical solution.
I worry slightly about UTF-8 due to it requiring an O(n) seek to a code point, unlike UTF-32’s O1
seek. But I suppose that can’t be helped, and most applications presumably won’t need to jump to
arbitrary points in a string very often.
--
Andrea Faulds
http://ajf.me/