Vlákno názorů ke zprávičce Změna plánu ve vývoji PHP 6

Upřímně, používat UTF-16 je blbost na entou a pokud se vydalo PHP tímto směrem byla jen otázka času kdy narazí.

Myslím, že celé rozhodnutí honit Unicode na 16bitech je něco, čeho všichni litují – a generuje to daleko větší ztráty v sw, než kdysi Y2K.

Nenajdete nikoho, kdo by byl z UTF-16 odvázaný. Docela by mně zajímalo jméno toho, kdo UTF-16 chtěl do PHP prosadit – je to nekompetentní člověk.

Myslím, že dnes by Microsoft byl rád, kdyby mohl věci vrátit a ve Windows kódovat Unicode na 32 bitem. Taktéž by to bylo požehnání pro Javu, apod. Autor Ruby zase nepřímo, stejně tak jako řada Japonců i Číňanů odmítají Unicode zcela, protože zprzňovací akce nad Unicode zvaná han unification, která przní jejich texty je důsledkem nedostatku znaků v 16bitovém prostoru Unicode.

Proboha, ať děláte cokoli, zapomeňte na UTF-16. Neexistuje více problematičtější kódování, které nemá fakticky žádné výhody, ale zase enormní množství nevýhod.

Znovu by mně zajkímalo jméno člověka, který to do PHP prosadil.

Vlastně asi tuším, kde to vzniklo. Je to snaha přenášet bezmyšlenkovitě věci z Javy do PHP, jak se stalo už u OOP, a teď koukám ve zvoleném Unicode kódování.

Možná se časem takto Java stane nepřímo vrahem PHP. Protože do PHP přenášejí věci i tehdy, kde by se dnes tvůrci Javy rádi rozhodli jinak, kdyby to šlo vrátit. Pokud se z UTF-16 tvůrci PHP poučí a vyvodí důsledek, že kopírovat Javu do PHP za každou cenu je blbost, pak tahle akce stála více, než za to.

prekvapuje me ze nikdo z vas tu jeste nezminil UTF-8 … nebylo by to lepsi reseni ? mensi objemy pri prenosu dat a pritom by to byl plny unicode. A anglicky mluvici by nepuznali rozdil vubec zadny.

vyhody utf-16:
- konstantna dlza znaku

No to ne, to je UCS-2. UTF-16 má stejně jako třeba UTF-8 promennou delku znaku, jen s tim rozdilem, ze nejmensi velikosti jsou dva byty.

Nepletou si i predchozi komentatori rozdil mezi temito dvema kodovanimi?

Doufám, že je z mých předchozích komentářů jasně znát, že rozdíl mezi UCS2 a UTF-16 je mi dobře znám.

Nicméně UCS2 i UTF-16 má také problém s endianitou a BOM znakem.

Všichni co dnes implementují UTF-16 s tím začali jako UCS2. Tak to bylo v Javě, ve Windows, i jinde. Časem byli nucení překvalifikovat to na UTF-16 a změnit chování.

Ovšem každý, kdo dnes dobrovolně v novém projektu postaví základ na UTF-16 by měl jít k lopatě.

A co by se podle tebe mělo používat? A důvody? Nerýpám, opravdu mě to zajímá.

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)

Ono s tím konstantním počtem bitů na znak to právě není tak úplně pravda ani u UCS-4/UTF-32, protože diakritika může být jako extra codepoint :-/

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ů“.

Já myslím, že pan Vrána rozumí, ale hraje si na středověké alchymisty, kteří rádi do textů podsouvali skryté významy. Zde je to jedno velmi peprné slovíčko :)

Heee :-))) konecne!

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.

U UTF-8 může změna velikosti písmen znamenat změnu délky řetězce, tedy nelze to provádět in-place. Jednotlivé „znaky“ v UTF-32 lze navíc používat přímo jako indexy do tabulek pro převody Unicode či různých podmínek (třeba vyhledání určitého code pointu), což u UTF-8 nelze, tam je nutné ten znak podmíněně vypočítat, případně hledat nezarovnaně a pomocí AND masky a to stojí hodně procesorového času.

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.

Třeba turecká İ (U+0130, malá varianta je ASCII i) a ı (U+0131, velká varianta je ASCII I)

Hash mapa sice dobře pracuje i s proměnlivou délkou klíče, ale stále je to o dost pomalejší než u pevné délky, kde lze udělat např. nepodmíněný XOR

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.

<blockquote>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ší.</bloc­kquote>

Probůh, ten moloch? :-o

Ani normální formy nedokáží zaručit, že jeden znak je jeden code point, pouze umožňují dva různé zápisy stejných znaků porovnávat. Unicode už není založeno na znacích a asi už nikdy nebude (těch kombinací je příliš mnoho a nikomu se to nechce kódovat).

Zotavení se z chyby je u UTF-8 i UTF-16 triviální (skočit na další znak a U+FFFD). Problémy se zotavováním trpělo UTF-1, které se už naštěstí nepoužívá.

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?

Opačně, jeden znak může být zakódován i po normalizaci více code pointy

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

Tady šlo o stav po normalizaci a tyhle znaky lze rozbít na více code pointů

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.

Jak už to tak bývá, tak UTF-8 nevymyslelo konsorcium UNICODE, ale Bell Labs pro Plan 9 :)

Céčko nativně podporuje UTF-16/UTF-32 (dle compileru) pomocí wchar_t a L"řetězec". Jediné výhody UTF-8 jsou v tom, že je kompatibilní s API, které očekává ASCII, a že nezávisí na endianu

> Doufám, že je z mých předchozích komentářů jasně znát, že rozdíl mezi UCS2 a UTF-16 je mi dobře znám.

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

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

đ

hehe, taxe zdá, že ani root.cz na tom s podporou unicode není úplně nejlíp :-(