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

Utf8 je pekny bastl, napriklad neexistuje rychly algoritmus pro substring, strreplace a podobne veci. Utf16 bude sice pametove narocnejsi, ale pri string operacich daleko rychlejsi.

Můžete to trochu rozvést? Jaký existuje rychlý algoritmus pro substr z UTF-16, ve kterém může být jeden znak uložen ve 2 nebo 4 bajtech? Napadá mě jedině ukládat si kromě samotného řetězce také tabulku pozic znaků zabírajících 4 bajty (což v PHP pravděpodobně bude), ale totéž by přeci šlo udělat i s UTF-8. str_replace nedělá problém ani v jednom kódování, v UTF-8 naopak bude většinou kvůli menší paměťové náročnosti rychlejší.

str_replace nedela problem? No, porad musim hlidat abych nahodou nenasel zacatek toho retezce k nahrazeni uprostred sekvence bajtu tvoricich jeden znak, takze to bude o neco pomalejsi nez klasicke bytove retezce. U latinky to asi nehrozi ze bych se takhle blbe trefil (i kdyz s retezcem opeprenym diakritikou by to mohlo jit), u cinstiny by uz celkem mohlo.

Připomenu, jak kódování UTF-8 vypadá. Každý znak je buď tvořen jediným bajtem < 128 nebo začíná bajtem >= 192 a pokračuje bajty 128..191. Z toho plyne, že k žádné kolizi dojít nemůže, hlídání, jestli nejsem uprostřed znaku, se děje samo od sebe a v důsledku jde použít normální bajtová operace.

Ale UTF-16 je na tom skoro stejne blbe jako UTF-8, protoze se take musi rozlisovat bytova delka znaku. Jedine reseni je pouziti "dlouhych" znaku na 32 bitu.

Mohli taky pouzit Unicode16 jako java ... sice se tam nevejdou nektery znaky, otazkou ale je ktery vlastne a jak casto je nekdo pouziva. Ale to ani java neresi :O) Ale kdyz uz utf tak tam mohli dat utf-8 ... ma stejny nevyhody jako utf-16 (narocny operace) ale pro jazykyn zalozene na latince zabira znatelne min mista. Jak je to s cinstinou a podobnymi obrazkovymi jakyky tak to uz nevim, ale tipuju ze ve vetsine pouziti bude utf8 uspornejsi.

No, on je to pruser i v Jave, protoze nektere novejsi knihovny plne podporuji UTF-16, coz ale odporuje tomu, ze kazdy znak z retezce je mozne nacist jako (sestnactibitovy) char. Prakticky to moc nevadi, protoze podle http://mindprod.com/jgloss/unicode.html v tech "hornich" castech nic moc duleziteho neni, ale porad se jedna o polovicate reseni, stejne jako tomu je s ASCII+kodovymi strankami pro osmy bit.

UTF-16 je naprosto geniální kódování. Zcela unikátním způsobem totiž sjednocuje většinu nevýhod, které mají jednotlivá unicode kódování: zabírá více místa, je endian dependent, má proměnnou délku znaku… Snad jen skutečnost, že pokrývá celý rozsah Unicode, mu trochu kazí pověst…

Ano, velmi pěkně a výstižně jste shrnul vlastnosti UTF-16 do pouhých tří vět :-) - vytesat do kamene. Jedna z věcí, které mě na celém slavném Unicode vadí, je právě těch několik způsobů kódování, které se ještě dosti pletou mezi sebou (a jak jsem psal o několik odpovědí výše, i tvůrci aplikací si mnohdy nejsou jistí, co vlastně implementují). O prohazování bytů podle platforem (a chybách v knihovnách při zpracování BOM) ani nemluvě.

Pro mě to prozatím pro komunikaci s okolním světem vyhrálo dosti pěkně navržené UTF-8, interně (na úrovni jazyka a knihoven) ovšem bojuji s UTF-16.

No obzvlaste kdyz BOM prileti v pulce stranky, to pak vetsina broweru vychrli par paznaku ... (bohuzel nektere editory to cpou na zacatek kazdeho editovaneho souboru a je jim jedno ze z toho bude include nekde uprostred stranky)

Na svych strankach pouzivam utf-8 (krome tech starych, kde pouzivam to kodovani ve kterem kdysi vznikly), interne pokud mozno taky :o)

Hloupost, Utf16 je to samé co Utf8 a má ty samé potíže, nepleť si to s UCS2.

Ano, jak jsem napsal, UTF-16 má všechny nevýhody UTF-8 (tj. především proměnnou délku znaku) a navíc přidává ještě dvě: zabírá více místa a je endian dependent. Co se vám na tom nezdálo? Nebo jste jen nepochopil ironii?

Omlouvám se, špatně jsem odhadl indentaci a myslel jsem si, že odpovídáte na můj příspěvek.