Vlákno názorů k článku Vývoj PHP 6 od Pavel Tišnovský - Ale to je prece spravne, ze pri kodovani...
-
Pavel TišnovskýZlatý podporovatelAle 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. -
Jirka Kosek (neregistrovaný)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"). -
Bilbo (neregistrovaný)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. -
Jirka Kosek (neregistrovaný)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.
-
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 ...
