Hlavní navigace

Změna plánu ve vývoji PHP 6

Aktuální release master PHP 5.3 na svém blogu oznámil poměrně zásadní změnu v plánu vývoje PHP 6. Rozhodnutí přepsat PHP tak, aby vnitřně používalo UTF-16, se ukázalo jako nevhodné. Bude se pokračovat jiným směrem, o konkrétním postupu se bude ještě debatovat. Cílem bude zrychlit a zjednodušit proces zavádění unicode do PHP. PHP 6 tak bude z trunku svn repositářů PHP přesunuto do samostatné – v podstatě mrtvé – větve.

Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!

Předchozí zprávička Následující zprávička        
viki
viki (neregistrovaný) 88.103.90.---
15. 3. 2010 14:24 Nový

LOL!

PHP rulez!

Miloslav Ponkrác aura:67
15. 3. 2010 15:03 Nový

Tak to je jasné

celé vlákno

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.

Miloslav Ponkrác aura:67
15. 3. 2010 15:05 Nový

Re: Tak to je jasné

celé vlákno

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.

Mark423
Mark423 (neregistrovaný) ---.251.broadband11.iol.cz
20. 3. 2010 14:44 Nový

Re: Tak to je jasné

celé vlákno

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.

mixal
mixal (neregistrovaný) ---.73.30.82.vnet.sk
15. 3. 2010 15:10 Nový

Re: Tak to je jasné

celé vlákno

vyhody utf-16:
- konstantna dlza znaku

Eddie
Eddie (neregistrovaný) ---.59.broadband2.iol.cz
15. 3. 2010 15:19 Nový

Re: Tak to je jasné

celé vlákno

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?

Miloslav Ponkrác aura:67
15. 3. 2010 15:24 Nový

Re: Tak to je jasné

celé vlákno

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

Santa
Santa (neregistrovaný) ---.fi.muni.cz
15. 3. 2010 15:31 Nový

Re: Tak to je jasné

celé vlákno

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

Peter Helcmanovsky aura:65

Re: Tak to je jasné

celé vlákno

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)

Santa
Santa (neregistrovaný) ---.fi.muni.cz
15. 3. 2010 16:09 Nový

Re: Tak to je jasné

celé vlákno

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 :-/

Miloslav Ponkrác aura:67
15. 3. 2010 16:26 Nový

Re: Tak to je jasné

celé vlákno

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.

David Grudl aura:47
16. 3. 2010 2:02 Nový

Re: Tak to je jasné

celé vlákno

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.

Miloslav Ponkrác aura:67
16. 3. 2010 10:39 Nový

Re: Tak to je jasné

celé vlákno

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.

David Grudl aura:47
16. 3. 2010 11:05 Nový

Re: Tak to je jasné

celé vlákno

(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?

Miloslav Ponkrác aura:67
16. 3. 2010 12:24 Nový

Re: Tak to je jasné

celé vlákno

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

David Grudl aura:47
16. 3. 2010 12:36 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
16. 3. 2010 11:11 Nový

Re: Tak to je jasné

celé vlákno

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

Miloslav Ponkrác aura:67
16. 3. 2010 12:13 Nový

Re: Tak to je jasné

celé vlákno

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

xurfa
xurfa (neregistrovaný) ---.dip.t-dialin.net
4. 4. 2010 15:40 Nový

Re: Tak to je jasné

celé vlákno

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 :)

Davidek grudl
Davidek grudl (neregistrovaný) ---.vodafone.cz
4. 4. 2010 19:09 Nový

Re: Tak to je jasné

celé vlákno

Heee :-))) konecne!

Peter Helcmanovsky aura:65

Re: Tak to je jasné

celé vlákno

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.

Miloslav Ponkrác aura:67
16. 3. 2010 10:43 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
16. 3. 2010 10:57 Nový

Re: Tak to je jasné

celé vlákno

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

Miloslav Ponkrác aura:67
16. 3. 2010 12:37 Nový

Re: Tak to je jasné

celé vlákno

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.

Pavel Stěhule aura:89
16. 3. 2010 13:20 Nový

Re: Tak to je jasné

celé vlákno

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.

Jakub Vrána aura:60
16. 3. 2010 13:45 Nový

Re: Tak to je jasné

celé vlákno

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.

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 18:06 Nový

Re: Tak to je jasné

celé vlákno

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.

Jakub Vrána aura:60
16. 3. 2010 18:17 Nový

Re: Tak to je jasné

celé vlákno

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.

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 18:33 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
16. 3. 2010 13:47 Nový

Re: Tak to je jasné

celé vlákno

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.

xurfa
xurfa (neregistrovaný) ---.dip.t-dialin.net
4. 4. 2010 15:42 Nový

Re: Tak to je jasné

celé vlákno

<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

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 17:56 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
16. 3. 2010 18:00 Nový

Re: Tak to je jasné

celé vlákno

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?

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 18:20 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
16. 3. 2010 18:24 Nový

Re: Tak to je jasné

celé vlákno

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

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 18:35 Nový

Re: Tak to je jasné

celé vlákno

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

Miloslav Ponkrác aura:67
15. 3. 2010 16:01 Nový

Re: Tak to je jasné

celé vlákno

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.

Pavel Stěhule aura:89
15. 3. 2010 18:50 Nový

Re: Tak to je jasné

celé vlákno

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.

Miloslav Ponkrác aura:67
15. 3. 2010 19:05 Nový

Re: Tak to je jasné

celé vlákno

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.

Miloslav Ponkrác aura:67
15. 3. 2010 19:14 Nový

Re: Tak to je jasné

celé vlákno

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.

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 17:50 Nový

Re: Tak to je jasné

celé vlákno

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

Sten
Sten (neregistrovaný) ---.seznam.cz
16. 3. 2010 17:48 Nový

Re: Tak to je jasné

celé vlákno

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

.
. (neregistrovaný) ---.cust.selfnet.cz
15. 3. 2010 18:48 Nový

Re: Tak to je jasné

celé vlákno

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

Miloslav Ponkrác aura:67
15. 3. 2010 19:03 Nový

Re: Tak to je jasné

celé vlákno

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

xurfa
xurfa (neregistrovaný) ---.dip.t-dialin.net
4. 4. 2010 15:35 Nový

Re: Tak to je jasné

celé vlákno

đ

xurfa
xurfa (neregistrovaný) ---.dip.t-dialin.net
4. 4. 2010 15:36 Nový

Re: Tak to je jasné

celé vlákno

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

Jakub Vrána aura:60
15. 3. 2010 17:36 Nový

Zkazilo mi to aprílový článek

celé vlákno

Chtěl jsem napsat, že vzhledem k současnému tempu vývoje se vývojáři shodli na realističtějším termínu a vydají PHP 6 v roce 2022 stejně jako HTML5.

yossarian
yossarian (neregistrovaný) ---.karneval.cz
15. 3. 2010 17:50 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

ha ha ha.

ldown
ldown (neregistrovaný) ---.inext.cz
15. 3. 2010 18:18 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

Není kam spěchat :)

Pavel Stěhule aura:89
15. 3. 2010 18:52 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

Přechod na UTF8 by mohl být mnohem rychlejší a jednodušší.

.
. (neregistrovaný) ---.cust.selfnet.cz
15. 3. 2010 18:51 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

Já vím, že ňákej pták jste, ale nikdy nevím jakej.

Vláďa J aura:73
15. 3. 2010 19:34 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

Slaví, pane, slavík.

Martin
Martin (neregistrovaný) 89.176.101.---
17. 3. 2010 15:28 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

V roce 2022 snad už PHP nebude používat nikdo, ani PHP exoti jako jste vy a David Grudl.

Peter Helcmanovsky aura:65

Re: Zkazilo mi to aprílový článek

celé vlákno

wishful thinking… :)

Jerry12
Jerry12 (neregistrovaný) ---.net.upcbroadband.cz
29. 3. 2011 14:31 Nový

Re: Zkazilo mi to aprílový článek

celé vlákno

Zapomen, v PHPcku je napsana vetsina webu. Jeho pomer se od roku 2000 zvednul misto toho aby klesal. Takze v roce 2022 bude PHPcka treba pulka, ale to porad bude 30-40% vsech webovejch aplikaci.

Pokud by to clovek pocital podle velikosti/traficu tak pokud se nepletu tak Google: Java+C, Facebook: PHP, YTrubka: Python, Twitter: Ruby, Flicker: PHP ... Mimochodem je to peknej dukaz toho, ze na jazyku nezalezi dokud jde rozumne skalovat.

Zasílat nově přidané příspěvky e-mailem