Re: What "Unicode support" really means

From: 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/

« previous php.internals (#72929) next »