# PHP 6, part 2 ... Unicode

- Thread: https://externals.io/message/72649
- Original archive: https://news-web.php.net/php.internals/72649
- Started by Lester Caine on 2014-02-17T08:27:35+00:00
- Messages: 3
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #72649 — Lester Caine — 2014-02-17T08:27:35+00:00

URL: https://externals.io/message/72649#72649

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

---

## #72659 — Crypto Compress — 2014-02-17T17:58:30+00:00

URL: https://externals.io/message/72649#72659 · In reply to: #72649

Hi,

"C++ Usage" discussion is somewhat of a dependency for "Unicode" as it 
may add some more varieties of "awesome Unicode lib".

cryptocompress

---

## #72739 — Lester Caine — 2014-02-21T12:35:18+00:00

URL: https://externals.io/message/72649#72739 · In reply to: #72659

Crypto Compress wrote:
>
> "C++ Usage" discussion is somewhat of a dependency for "Unicode" as it may add
> some more varieties of "awesome Unicode lib".

I don't see that the two do go together, and I'm with Pierre that introducing 
C++ now would only delay progress. It would however be worth serious 
consideration on a longer timeline? I still see unicode as a stepping stone 
which has already been incorporated into PHP by the back door and now simply 
needs a few loose ends tying up. Making it a major version upgraded is more 
about setting the ground rules for other areas than unicode per say. Formalising 
say UTF-8 usage by introducing a few BC breaks opens the debate where trying to 
simply shoehorn the missing UTF-8 elements into PHP5 may not be so practical?

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