PHP 6, part 2 ... Unicode

From: Date: Mon, 17 Feb 2014 08:27:35 +0000
Subject: PHP 6, part 2 ... Unicode
Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
1/ Use of a fast and lite UTF-8 procession libraries for all core string operations
When you start looking at the ICU UTF-8 handling then it does provide a stable base. It is conversion to UTF-8 which seems to get in the way. But now that I have had time to dig deeper, UCONFIG_NO_CONVERSION is the key. How many people today only ACTUALLY handle UTF-8 in their content? Conversion is only required when one finds material that is not already UTF-8 ...

2/ Use of intl for any advanced operations, localization or conversion?
Simply follows on from 1/
Certainly localizations like currency, timezone and calendar management should use a common base, but I get the impression that 'locale' is still somewhat messy when it comes to 'collations'? This is one of those areas where the language returned in a browser header may or may not give the right information, just as currently we can't guarantee to correctly guess the timezone? But in a way I view this as secondary to the UTF-8 debate? Even just fulldefault support for UTF-8 in the core is better than the current piecemeal support?

3/ Support of UTF-8 for the language itself, as PHP currently allows non ascii encoding in scripts, I would recommend to stop supporting it, except in comments.
Million dollar question?
If ALL one is processing in UTF-8 is the content, then we are already there? Just use mbstring to manage the content and as Pierre says - stop using UTF-8 in identifiers and the like? While that would not affect me one bit as I don't need anything other than ASCII for my own identifiers, I think it is just this area that other users are looking to upgrade so that they can make scripts more readable in their own languages?

I really am getting fed up with the website structure ... having to manually change domain in the address line so you can search documentation when working through the wiki or bugs is hopeless. There should be one search engine covering the whole site - and NOT Google since that does not work at all when you want results in one language! Another example of 'locale' simply not working?

-- 
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


Thread (3 messages)

« previous php.internals (#72649) next »