Re: Unicode strings?

Hi all, Just FYI. http://www.w3.org/TR/encoding/ This would be the list of legacy encoding for HTML5. Regards -- Yasuo Ohgaki yohgaki@ohgaki.net On Tue, Mar 11, 2014 at 7:31 PM, Lester Caine <lester@lsces.co.uk> wrote: > I'm slowly working through a long list of things relating to unicode > strings trying to work out just where the main problems are. > > The very first problem I hit is ICU's limitation to 32bit string lengths. > How does the switch to 64bit string length on 64 bit platforms impinge on > this. While I can see the advantage of this particular change, would that > also now require our own version of ICU capable of also handling longer > strings? This probably falls out in the wash of my next point ... > > Currently strings are simply strings? I'm sure we have already had this > discussion, and it will be necessary to switch from simple strings to a > string object which can handle the intricacies of unicode? > > Pierre - I presume that it's this distinction that is where I'm crossing > over between variable and similar names which just remain as simple stings > while 'data' that is unicode is provided by sting objects. These then need > to work nicely with areas that expect a simple string? Where a string > object is returned an ASCII version will be created when a simple string is > necessary? > > The 'leak' of unicode currently into name strings is simply that there is > nothing currently stopping them from storing UTF-8? That this works is more > by luck than design, but results in subtle problems with case conversion > and the like which does not expect unicode strings? BUT people can > currently use any format data in a string even one using a 64 bit pointer > as long as it does not go through a path that does expect ASCII? > > If the simple string is isolated from UTF-8 and unicode is kept to it's > own data type such as an improved integrated mbstring package then this > make a suitable 'half way' house for PHP6? > > I don't NEED unicode variable names, but I can see that this would be a > nice to have in non-English speaking countries. In much the same way we > provide translated versions of web pages, I can even see the advantage of > function name aliases in different languages as having more relevance that > simply changing the current English names for picky reasons, but that is > not likely to happen in my lifetime! Perhaps PHP10 :) > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk > Rainbow Digital Media - http://rainbowdigitalmedia.co.uk > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >