Názory k článku
Změna plánu ve vývoji PHP 6

utf-8, nebo plnych 32bitu.
Vsichni jiz pouzivaji utf-8, takze nevim proc vymyslet s necim jinym.
(krome pripadu kdy je potreba konstantni pocet bitu na znak, pak je tu 32b unicode)

Právě od toho existují normální formy Unicodových stringů.

U UCS4/UTF-32 platí, že jeden Unicode znak je na stále stejných 32 bitech.

U UTF-8/UTF-16 a dalších platí, že navíc k tomu přistupuje bordel, že jeden znak má proměnný počet bitů, navíc obě tato kódování se umějí i rozesrat. Tedy obsahovat bitové sequence, které jsou chybné, či neplatné s nejednoznačným zotavením se z chyby, což v případě UCS4/UTF-32 nezažijete.

Navíc, ukažme si prstem, UTF-16 také Unicode škodí. Jen a jen díky tomuto kódování jsou Unicode znaky omezeny na 21 bitový prostor. Kdybychom UTF-16 zavrhli, pak bez problémů máme 32bitový prostor. Jako důsledek bychom mohli Asiatům přestat prznit jejich znaky han unifikací, protože by najednou byl dostatek prostoru pro všechny jejich obrázky, a Asie by konečně mohla přestat odmítat používat Unicode. Zatím má vážné důvody si držet svá znaková kódování a na Unicode se dívat jako na zrádce.

Bohužel odstřelení brání Microsoft Windows a Java, jakožto dva reprezentanti, kteří skočili na špek 16bitovému Unicode. Bylo by potřeba zlikvidovat Windows a Javu, aby se to podařilo. Jen kvůli nim totiž UTF-16 existuje. I když primární příčina je Unicode consortium samo, protože „16bitů bude v Unicode stačit každému“. Šetření bitíkama přineslo Y2K a UTF-16 a problémy v nedostatku IPv4 adres. A ještě mnoho problémů přinese.

UTF-8 ani UTF-16 se neumí rozesrat. Jejich formát je přesně specifikován. To, že určité bitové sekvence nejsou platným UTF-8 kódem, platí stejně tak i pro UTF-32.

UTF-8 i UTF-16 se umí rozesrat. Doporučuji si to nastudovat.

V UTF-8 je možnost vytvoření neplatných sekvencí, ze kterých ani není jasné, jak vůbec vytvořit kód znaku. V UTF-32 se Vám žádná sekvence nerosere, max. se trefíte do momentálně nedefinovaného znaku, ale špatnou sekvenci položek prostě v UTF-32 nevyrobíte, protože to není možné. V UTF-8 a UTF-16 je možností špatných sekvencí mnoho.

Jejich formát je totiž přesně definován, ale připouští neplatné sekvence.

Doporučuji příště nastudovat, než začnete reagovat.

(Jakmile někdo v komentářích používá obraty jako „doporučuji si nastudovat“, je s argumenty na štíru, což je samozřejmě i tento případ)

Co znamená „V UTF-8 je možnost vytvoření neplatných sekvencí?“ Nic takového UTF-8 „neumožňuje“. To, že záměrně poškodím data vložením neplatných binárních znaků, není něco, co by mi formát „umožňoval“, a že tím data poškodím, je zcela přirozené. Stejně tak poškodím i data v jakémkoliv jiném kódování včetně UTF-32 nebo CP1250.

UTF-8 naopak umožňuje se z takové chyby hned u následujícího znaku zotavit. Tedy nic se nerozesere, ba právě naopak!

V UTF-32 samozřejmě lze vyrobit také špatnou sekvenci bitů (dokonce i v ISO-8859–2). A není to v případě UTF-32 o tom, že bych se trefil do momentálně nedefinovaného znaku, ale že se trefím do znaku mimo povolený rozsah.

Mize „momentálně nedefinovaný znak“ a „znak mimo rozsah“ je zcela zásadní rozdíl.

pod čarou: z prvního komentáře se zdálo, že jste netušíte, že UTF-16 adresuje plný Unicode prostor, viz zmínky o problémech s japonštinou nebo nedostatkem znaků. Skutečně tomu tak bylo nebo jste se jen nešťastně vyjádřil?

„Co znamená „V UTF-8 je možnost vytvoření neplatných sekvencí?“ Nic takového UTF-8 „neumožňuje“. To, že záměrně poškodím data vložením neplatných binárních znaků, není něco, co by mi formát „umožňoval““

K poškození dat nedochází zásadně záměrně.

“UTF-8 naopak umožňuje se z takové chyby hned u následujícího znaku zotavit. Tedy nic se nerozesere, ba právě naopak!“

To sice umožňuje, nicméně není definován code point, ani způsob jak naložit s vadným kusem sekvence. Jediné, co UTF-8 definuje je poznat, který bajt je začátkem copdepoint a kolik by mělo následovat bajtů. Pokud nenásleduje, pak zotavení je dle libosti toho kdo to programuje. Tedy NENÍ JEDNOZNAČNÉ.

„pod čarou: z prvního komentáře se zdálo, že jste netušíte, že UTF-16 adresuje plný Unicode prostor, viz zmínky o problémech s japonštinou nebo nedostatkem znaků. Skutečně tomu tak bylo nebo jste se jen nešťastně vyjádřil?“

UTF-16 adresuje plný 21bitový prostor, což je normativně stanovený limit pro ISO. Kdysi ovšem ISO stanovilo vícebitový prostor (například UTF-8 je, přesněji bylo definováno pro plných 32 bitů, ve skutečnosti zvládne mapovat bitů ještě více). Původně ovšem omezení na 21bitový prostor nebylo, a to z toho důvodu, že omezení na 21bitů bylo nutné zavést z důvodu UTF-16, které namapuje jen omezenou množinu znaků.

Následkem toho bylo zavedeno (ale později, ne ze začátku) omezení na 21bitů z důvodů nedostatečné schopnosti mapovat dostatečný počet znaků v UTF-16. Tedy ano, dnes UTF-16 mapuje celou množinu Unicode, ovšem proto, že Unicode byla oříznuta na omezené schopnosti UTF-16.

Takže pokud se vrátím k vašemu původnímu tvrzení, že nevýhodou UTF-8/UTF-16 je, že se obě tato kódování umějí rozesrat, mám to chápat tak, že ostatní kódování a) mají definován způsob, jak naložit s vadným kusem sekvence b) a nemohou se (dle vašeho slovníku) rozesrat?

To asi nikoliv, že? Poškodit se mohou data v jakémkoliv kódování, v UTF-8 je pouze největší šance takové poškození odhalit.

ad rozsah mapování: výborně, začínáte tomu vcelku rozumět. Snad jen drobnost, Unicode nebylo oříznuto na 21b, ale rozšířeno na 21b ze 16b. (tj. nikdy víc než 21b nemělo a není po tom ani poptávka).

Tak to zkusíme na úplně jednoduchém příkladu: Je DE B1 7E platná UTF-32 sekvence?

Vy jste nepochopil význam spojení „32 bitů“.

Ty usetrene bitiky meli ve sve dobe urcitou cenu a vyznam, takze bych to nevidel tak cernobile.

Kazdopadne doba je ted jinde, a podle mne utf-8 + ucs4 aktualne pokryje vsechny potreby vyvojare, alespon na nekolik pristich let. A v podstate vsechny rozumne vyvojove nastroje to jiz pochopili a respektuji to, jediny kdo zamrz nekde v praveku je MS a dle teto diskuze i Java. A ruku na srdce, koho z vyvojaru dnes zajima MS? Stejne veskery novy kod je cross platform nebo na mobilni platformy, nebo cloud computing, ciste win api je mrtva vec, ktera se pouzije jenom ve (utf8) frameworku ktery to zapouzdri, ukryje a pak uz to nesmi nikde vybublat na povrch.

„Ty usetrene bitiky meli ve sve dobe urcitou cenu a vyznam, takze bych to nevidel tak cernobile.“

Bohužel ty ušetřené bitíky s námi asi zůstanou navždy. Protože se stav už reálně nedá změnit.

„A ruku na srdce, koho z vyvojaru dnes zajima MS?“

Asi tak přes 90% vývojářů?

„ciste win api je mrtva vec“

A myslíte, že UTF-16 je ve Windows omezeno jenom na Win API?

Jinak UTF-16 používají i další věci. Napříkald v poměrně široce používané unicodové knihovně ICU od IBM se používá jako základ a vnitřně také třeba UTF-16.

Právě ICU je důvod, proč mělo i PHP 6 pracovat s UTF-16. Autoři chtěli využít nějakou knihovnu a ICU se jevilo jako nejlepší.

Osobně UTF-32 za žádnou velkou výhru nepovažuji. Pro angličtinu zabírá čtyřikrát víc místa než UTF-8 (pro češtinu skoro taky) a na to, že 4 bajty = 1 znak, se stejně nedá spolehnout kvůli kombinačním znakům. To by šlo až po normalizaci, což by zase znamenalo, že by kombinační znaky byly neplatné (jak říkáte – rozesralo by se to).

Pokud mám srovnat UCS4 (často tu hovoříme o UTF-32, ale vnitřně v programech se to stejně realizuje jako pole 32bitových hodnot) a UTF-16, pak je UCS4 obrovská výhra.

Manipulace s UTF-8 a UTF-16 je komplikovaná a složitá, a v zásadě stejně se převádí při všech algoritmech vnitřně na 32bitový znak. To se nedá popřít.

Jinak Vaší filozofií (nic proti ní, nekritizuji) je šetřit každým bajtíkem i za cenu, že nad tím strávíte tisíc hodin práce navíc. Nicméně úspora, kterou uděláte ve velikosti paměti při zavedení UTF-8, nebo UTF-16 namísto UCS4 je zanedbatelná, zato poměrně dosti zvednete zátěž cpu. V běžném PHP skriptu určitě neušetříte více, než pár desítek kilobajtů tím, že nahradíte UCS4 něčím méně rozumným. S tím, že podstatně znásobíte počet problémů.

Normalizace není potřeba zvažovat, pokud se bavíme o ukládání řetězců. Navíc jste taktně nezmínil, že jak UTF-8, tak UTF-16, tak UCS4 musí řešit všechny normalizaci. Protože normalizace není a nikterak nesouvisí s kódováním Unicode, ale je vlastností Unicode samotného. Tudíž při rozhodování ohledně UCS4, nebo UTF-8, nebo UTF-16, je to off topic téma. Normalizaci budete řešit vždy, když použijete Unicode, a to bez ohledu na použité kódování.

Pokud je Vaší prioritou ušetřit několi desítek KB za každou cenu, pak máte pravdu. Ale obávám se, že nevýhody by silně převážily. Máte pravdu, záleží na kritériu, které si dáme. UTF-8 a UTF-16 je úspornější (o ty desítky, max. stovky KB v běžném skriptu), než UCS4, zato přináší takové problémy, že o ně tvůrci programů obvykle nestojí. Zejména UTF-16 je silně znouze ctnost.

V UTF-8 zase česká abeceda vychází kratší, ale třeba asijský text mnohdy značně delší, než v UCS4. Vyberte si.

Pro mne délka skriptu nehraje roli. Ovšem, co hraje roli, např. pro db, je velikost nezkomprimovaných dat v cache. Minimálně pro data v db to bude znatelný rozdíl – ať už z důvodu většího počtu stránek, které je potřeba přečíst (byť komprimovaně), nebo přesunu větších bloků v paměti.

Tak si shrňme, jaké operace provádíme s řetězci a jak si stojí UTF-8 ve srovnání s UTF-32:

• Kontrola platnosti – snadné v obou kódováních
• Podřetězec – kvůli kombinačním znakům pracné v obou kódováních, v UTF-8 o něco pracnější
• Změna velikosti písmen – obě kódování bez problémů
• Vyhledávání – obě kódování bez problémů
• Přenositelnost – UTF-8 bez problémů, UTF-32 platformově závislé
• Velikost – UTF-8 podstatně menší než UTF-32

Zkuste tedy popsat ty obrovské problémy, které UTF-8 ve srovnání s UTF-32 podle vás má.

Pokud celá aplikace využívá UTF-8 (což u PHP+MySQL není sebemenší problém), tak bude menší nejen objem zpracovávaných dat, ale tomu úměrně i rychlost. Neustálé konverze by vše samozřejmě zpomalily, ale já se kloním k tomu, aby UTF-8 proplulo celou aplikací bez jakékoliv konverze.

Můžete prosím uvést znaky, které při změně velikosti zaberou v UTF-8 jiný počet bajtů? Měl jsem za to, že jednotlivé části prostoru jsou přiřazované tak, aby podobné znaky byly pohromadě.

Převodní mapa bude poměrně řídká, pro její uložení bych tedy volil hash tabulku, která dobře pracuje i s proměnlivou délkou klíče.

Uveďte prosím asijský text, který je v UTF-8 delší než v UCS-4. Vzhledem k definici těchto kódování se vám asi bude hledat těžko.

Chápu to správně tak, že vrátit prvních X znaků v Unicode prostě nejde (protože jeden code point může obsahovat víc znaků) a ořezávat musím vždy na code pointy?

Na Wikipedii píší: „more than one character position per code point (for example CJK ideographs)“.

Uvnitř programů jasně UCS4 (fakticky dnes (dnes = nemusí platit v budoucnu) roven UTF-32) bez BOM v machine endian, tedy plných 32 bitů. Není důvod používat naprosto nic jiného.

Pro komunikaci mezi rozhraními, tedy jako API je vhodné používat buď totéž, nebo UTF-8 pro jeho naprostou multiplatformovost.

UTF8 má jednu ohromnou výhodu – je kompatibilní s ASCII – plus je plus, čárka je čárka – pro Cčko je to ohromná výhoda. Za kterou se platí – běžné funkce lower, upper, substring jsou o dost pomalejší. To ovšem pro skriprtovací jazyky nemá význam.

Microsofti přišel s UTF16 snad s první verzí NT – tehdy ještě nebylo paměti nazbyt. Tehdy to asi chybou nebylo.

Microsoft s tím nepřišel, s tím přišlo Unicode consortium. To vymyslelo, že se všechny abecedy světa vejdou do 65535 znaků, což se ukázalo jako nemístně optimistické.

Ovšem tento optimismus mezitím už nadělal nevratné škody, které nejdou zcela vrátit.

Jinak co souhlasím je, že UTF-8 se nechutně povedlo. Jako předávací formát je velmi dobrý.

Jinak UTF-16 nebylo od začátku UTF-16, ale jak Windows, tak Java zavedla oficiální UCS2. Teprve později pod tlakem nalepováku byly nuceny z toho udělat UTF-16.

„Ne, je z nich úplně jasné, že o tom nemáte ponětí.“

Prosím neuvádějte žádný konkrétní argument, jinak byste na sebe prozradil, že o tom víte kulové. Takhle to ale můžete dovedně skrývat.