Vlákno názorů k článku
Vývoj PHP 6

Ale to je prece spravne, ze pri kodovani UTF-16 se pouzivaji znaky s sirkou dva i ctyri byte, viz napriklad http://en.wikipedia.org/wiki/UTF-16 a http://en.wikipedia.org/wiki/Comparison_of_unicode_encodings

Jsem zvedavy, jak to bude PHP zvladat, napriklad Java (resp. knihovny nad ni) s tim ma dost problemy.

Pravda vsak je, ze pouziti UTF-8 by bylo (alespon v nasem jazykovem regionu) pametove vyhodnejsi.

No, ona si totiž spousta lidí plete UTF-16 a UCS-2. Vypadá to, že autor článku mezi ně patří…

Nejenom lidí, ale i aplikací :-( [=klamavá reklama]. Typicky to bývají aplikace psané v C++ (wchary apod.), ale i v Javě, kde se při některých převodech s 32 bity jaksi nepočítá.

Se surrogate pairs (to jsou ty 4bajtové UTF-16 sekvence) by snad problém být neměl, protože PHP bude pro Unicode využívat služby knihovny ICU.

UTF-8 je sice pro určitě texty úspornější, ale je pomalejší na zpracování, protože se musí pracně hledat hranice znaků. UTF-16 je v tomhle přeci jen lepší, protože v mnoha řetězcích se znaky s kódem nad U+FFFF nevyskytují, a lze tak pracovat v režimu 1 znak = 16 bitů. Pouze pokud je v řetězci nějaký znak, který musí být zapsaný jako surrogate pair, přene se na pomalejšé mód, který to umí ošetřit.

Z dlouhodobějšího hlediska bych se nedivil, kdyby jazyky a operační systémy začaly používat pro interní reprezentaci UTF-32/UCS-4. Na zpracování je to nejjednodušší a pamět je levná.

Mnohem zajímavější jsou v Unicode operace jako porovnání řetězců, protože před porovnáním se musí text znormalizovat, aby se eliminovaly alternativní zápisy stejného textu ("á", versus "a" + "akcent čárka nad písmenem").

No pocitat s necim jako "znaky nad 0xffff se nevyskytuji" jaksi v knihovnach nejde ... pak takovy znak prijde a muzem se jit klouzat ... takze s takovymi znaky pak musi pocitat naprosta vetsina funkci pro praci s retezci -> zpomaleni

a utf-32/ucs-4 .... pamet je sice levna, ale ve chvili kdy mam obrovsky kusy textu tak uz muze byt rozdil jestli zaberou 500mb, 1gb nebo 2 gb .... zase pristup "dame uplne vsude ucs-4" asi nepujde ... nehlede na to ze diakritika (nebo jine "podivne" znaky) ve jmenech souboru je prasarna a mela by se vymytit a ne podporovat.

No pocitat s necim jako "znaky nad 0xffff se nevyskytuji" jaksi v knihovnach nejde ... pak takovy znak prijde a muzem se jit klouzat ... takze s takovymi znaky pak musi pocitat naprosta vetsina funkci pro praci s retezci -> zpomaleni Nikde jsem neřekl, že se znaky nad U+FFFF neobsluhují. Jen jsem řekl, že v tom případě se může použít rychlejší implementace řetězcových operací. Prostá a jednoduchá programátorská optimalizace.

No to vaše řešení skutečně moc inteligentní není. Inteligentnější by bylo držet u každého stringu příznak, zda se vejde do BMP, nebo jestli používá surrogate pairs. Něco takového jsem měl na mysli.

TAK levna ta pamet zase neni. Krome toho, stejne tak by jste mohl rict ze je levny vypocetni vykon. Myslim, ze neustala snaha o tom, aby uplne vsechno bylo v tom samem kodovani, je nesmyslna. Stejne programovaci jazyky musi podporovat i binarni stringy (pro praci s binarnimi daty). Holt se k retezci prida krome delky jeste priznak, je-li v 7bit ASCII, UTF-8, UCT-2 nebo UTF-16 a pri spojovani stringu se bude konvertovat ...