Qt 5.3

Vyšla verze 5.3 toolkitu Qt. Přináší především zlepšení stability a uživatelské přívětivosti vůbec; mezi novinky patří např. WebSockets API nebo třída QQuickWidget, která umožňuje používání jak Qt Widget, tak Qt Quick v jednom uživatelském rozhraní.

20.5.2014 20:33 | Fluttershy, yay! | Nová verze

Komentáře

[:::]

vzbudte me az se zbavi utf-16

[Jardík]

To forkni a vyhoď ho. Spolu s tím vyhoď ty ubastlený vlastní kontejnery a další šmejďárny, co jdou nahradit standardní knihovnou. Pak ještě vyhoď kýbl těch alokací na heapu a přidej strong exception safety. Pak vzbuď mě.

[LKG]

A teď mi řekni, co má člověk používat. Když jsem dělal očistu firmy od Borland C++ 6.0, tak jsme prošli všechny možný frameworky a hledali věc, ve které budeme schopni psát udržitelný kód pro Windows a Linux. QT bylo nejlogičtější volbou, navíc se začal skvěle uplatňovat python na GUI a logiku ovládání, C++ na rychlý kód výpočetních algoritmů.

Jo, člověk se nesmí sem tam podívat do zdrojáků. Ale co bych dal kolikrát za to, vidět pod prsty Embarcaderu a jeho nové inkarnaci Borlandích nástrojů. O VS20xx ani neuvažuju, lock-in na Windows bych nedal...

[little.owl]

Je to marny, je to marny, cekat na "rozumny" toolkit je jak cekat na Godota.

Nakonec zkoncime u HTML5/JS ci jejich pohrobka.

[little.owl]

Tech alokaci na heapu je jak sracek ... Jeste vyrazit MOC.

[Roger]

http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html

[little.owl]

To by sice slo, ale bohuzel to necitelnym zpusobem zvysuje komplexitu jazyka.

[m][sko]

prepac ale ukaz mi prosimta kontajnery, ktore podporuju copy on write a podobne vychytavky no STL to urcite nieje ani C++11 to nema A nie vsekty kompilatory maju vobec STL. Taky divoky rozvoj C++ je nastastie az teraz kdezto Qt sa rozvijalo daleko rychlejsie kedze nemuseli cakat na neaku realnu normu akceptovanu 10 firmami

Dalsia vec je ze Qt je plnohodnoty framework skratka mas tam vsetko a zapada to doseba a hlavne nieje tam miliarda KOPIROVANIA. O com vela ludia ani nevie, ked nieco pise a casto sa to nedozvedia ani pri profilovani kodu kedze su to vsetko sablony

A ukaz mi neaky opensource framework, ktory ti ponuka nieco podobne ako QML. Pre vela ludi je to strasny problem, ale v nicom nespravis tak jednoducho UI a animacie ako prave v QML

Je to fakt velky konkurent frameworkom ako su WPF JavaFx,..... A je evidentne napisany tak optimalne, ze raspberry pi sa dost flaka :)

[Jardík]

Copy on write nemá většinou smysl. Buď vím, že (třeba) řetězec potřebovat nebudu, tak ho funkci kydnu přes std::move. Když vím, že ho funkce bude měnit, tak jí prostě předám kopii, která by se stejně vytvořila.

Dnešní Qt stejně bez stl skoro nefunguje. Ve spousty projektech i předpokládají, že třeba Qt bylo zkompilováno s podporou STL a že tam jsou fce na konverzu apod, s testováním maker se nikdo nesere. Ve výsledku pak máme zbytečnou duplikaci kódu a pomalejší linkování při startu programu.

[kralyk z abclinuxu]

Viz Obsolete Members for <QtAlgorithms> - doporučují std::foo ...

[unicode]

UTF-16 je prakticke.

[kralyk z abclinuxu]

To sice souhlasim, ale Qt implementace tak úplně praktická není...

[chrono]

Praktické na čo?

[Hans1024]

Asi pevna delka znaku.

[ET]

?

http://cs.wikipedia.org/wiki/UTF-16

Při dekódování jsou vstupní data čtena po 16 bitech a je prováděno následující rozhodování:

1. Pokud je hodnota menší než 0xD800 nebo větší než 0xDFFF, jedná se o konečný výsledek.

2. V opačném případě musí být hodnota v rozmezí 0xD800-0xDBFF a je třeba přečíst dalších 16 bitů, které musí ležet v rozsahu od 0xDC00 do 0xDFFF.

[Hans1024]

Otazka je, jestli se v Qt ty dalsi dva bajty pouzivaji.

[kralyk z abclinuxu]

Ale jistěže používají, UTF-16 je variable-length encoding a Qt ho jako takový podporuje (korektně), akorát to ve třídě QString není moc dobře zapouzdřeno, tj. délka stringu a příslušné algoritmy nepracují ne se znaky, ale s utf-16 jednotkami, z čehož mohou vznikat problémy.

[kralyk z abclinuxu]

z čehož mohou vznikat problémy.

Abych to rozvedl: Vezměme například takovýhle string. Všechny znaky tohoto stringu jsou v UTF-16 v dvojicích (tzv. 'surrogate pairs', 2×2B). Pokud tenhle string zobrazíš například v programu konsole, nezabere každý znak jedno políčko, jak by měl, ale dvě políčka, navíc špatně funguje označování takového stringu.

P.S. String jsem nemohl vložit přímo do komentáře, ábíčko to nechtělo uložit do databáze

[Tom K]

V programu konsole to funguje špatně, ale např v qt creatoru 3.1.1 pod qt 5.3.0 to už funguje správně.

[kralyk z abclinuxu]

Tak což o to, ono to funguje správně i v řadě jiných Qt programů. V Qt5 se v tomhle ohledu nic nezměnilo - bohužel, stále je potřeba to explicitně ošetřit.

[little.owl]

Treba proto, ze je to vyhodnejsi kodovani pro asijske jazyky, coz byla hlavni motivace proc to Microsoft zacal prosazovat.

[:::]

UTF-16 je prakticke.

Ne. UCS-2 bylo prakticke, protoze to bylo fixed-length kodovani. Bohuzel nekteri ho naivne naimplementovali aniz by si uvedomili ze 16 bitu neni dost, a potom pro ne bylo jednoduzsi prejit na paskvil jmenem UTF-16, nez to udelat spravne a pouzit UTF-8, nebo 32.

[kralyk z abclinuxu]

Jaký je technický důvod proč UTF-8 není paskvil a UTF-16 jo? Variable-length jsou oba...

[:::]

1. UTF-8 je ASCII kompatibilni

2. UTF-16 vede hodne programatoru k mylne predstave ze je to fixed-length

3. Dvojce codepointu se nepouzivaji moc casto. To vede k tomu ze programatori z bodu 2 ani nemusi prijit na to ze tam maji chybu. A kod se bude obecne hur ladit.

[:::]

4. UTF-8 nema problem s endianovosti

pravdepodobne jich bude jeste vic...

[little.owl]

Problemy s endianovosti ma IMHO UCS-2, UTF-16 ma BOM.

[:::]

tak to tady mame:

5. BOM

[:::]

6. Navenek stejne musis komunikovat utf-8. (v tom se snad shodneme)

[little.owl]

ad 1) Jak kdy, pro aglictinu ano, pro jine jazyky nemusi.
ad 2) A u UTF-8 ne? To je nesmyslny argument.
ad 3) Pak at jdou past kozy.

[:::]

1. Kompatibilita se sw ktery vznikl za poslednich 50 let bude vzdycky vyhoda.

2. Nesetkavam se s tim ze by nekdo vedel co to je UTF-8 a nevedel ze to je variable-length. S tim ze nekdo nevi ze UTF-16 je variable-length se setkavam kazdou chvili. Treba i v tyhle diskuzi...

3. Divil by ses kdo vsechno dneska programuje A i kdybys mel ty nejlepsi programatory, tak proc jim zbytecne pridelavat praci a ztezovat ladeni?

[kralyk z abclinuxu]

1. UTF-8 je ASCII kompatibilni

Hm, to je taková sporná "výhoda"... Je to výhoda jen na západě a jen ve specifických situacích...

2. UTF-16 vede hodne programatoru k mylne predstave ze je to fixed-length

To nepovažuju za technický problém, ale problém dokumentace a/nebo společenský.

3. Dvojce codepointu se nepouzivaji moc casto.

To je spíše výhoda - je možné optimalizovat pro častý případ...

To vede k tomu ze programatori z bodu 2 ani nemusi prijit na to ze tam maji chybu. A kod se bude obecne hur ladit.

Na ladění to žádný vliv nemá. UTF-8 dekodér je výrazně složitější než UTF-16 a jsou tam taky sporné momenty, ale přesto se dá odladit...

4. UTF-8 nema problem s endianovosti

Problém s endianness je problém jakéhokoli multi-byte kódování, ne pouze UTF-16...

[:::]

1. To ze ti funguje existujici sw je zcela jasna vyhoda

2. System kterej nefunguje s realnejma lidma je spatne navrzenej. Sice si muzes myslet ze chyba je v lidech a mozna i je, jenomze soucasna technologie neni schopna zmenit lidi, takze se musi zmenit system.

3. Pro kod kterej se jednou napise, otestuje, zoptimalizuje a uzavre aby na nej uz nikdo nikdy nemakal to vyhoda je. Pro ruzny ad-hoc algoritmy je to nevyhoda ze pri chybe ti spadnou jednou za mesic pri uplnku...

4. Tady se ale nebavime o jakemkoli multi-byte kodovani, ale o tom proc je utf8 vyrazne lepsi paskvil nez utf16.

[Miloslav Ponkrác]

Ad 4) Podle mého stojí jak UTF-8, tak UTF-16 naprd.

UTF-8 je nesmírně plýtvavý formát, který je zbytečně nabubřelý na základě konpatibility s ASCII a samosynchronizovatlenosti ad absurdum. Ve své podstatě lze každý Unicode znak zbytečně zakódovat několika způsoby, čehož se v praxi také občas využívá. Navíc UTF-8 ještě velkoryse nepoužívá některé bajty, takže se nikdy nevyskytne třeba bajt 0xfe nebo 0xff.

Nemyslím si, že UTF-8 je nějak skvělý formát, naopak si myslím, že je to paskvil úplně stjeně jako UTF-16. Každý z obou formátů je nalepovák na nějaký problém a velmi špatné řešení.

Jak UTF-8, tak UTF-16 lze zařadit do kategorie horší, než z nouze ctnost. Nechválil bych ani jeden, oba formáty jsou tu z historických důvodů, a to z důvodů, že jejich tvůrci něco v historii pekelně špatně nedomysleli a UTF-8 i UTF-16 jsou prostě rychlé nedomyšlené nalepováky.

Ostatně, kdo dělá sw s Unicode, bude blázen, pokud vnitřně bude pracovat s UTF-8. Tento formát se použíje maximálně jako vstupní nebo výstupní. To už rozumnější a sem tam opodstatněné je vnitřně pracovat s UTF-16.

Ale drsně budu proti, pokud někdo napíše, že jeden z formátů UTF-8 nebo UTF-16 je lepší. Oba nestojí za nic, a jsou zhruba stejně špatné. Každý z trochu jiných důvodů.

Miloslav Ponkrác

[kralyk z abclinuxu]

To ze ti funguje existujici sw je zcela jasna vyhoda

Možná funguje, pokud třeba taky nemáš smůlu...

Pro kod kterej se jednou napise, otestuje, zoptimalizuje a uzavre aby na nej uz nikdo nikdy nemakal to vyhoda je. Pro ruzny ad-hoc algoritmy je to nevyhoda ze pri chybe ti spadnou jednou za mesic pri uplnku...

V tomhle není mezi utf-8 a utf-16 rozdíl. Oba se při implementaci musí otestovat pro speciální případy úplně stejně a následně musí být implementace vhodně zapouzdřena.

[Miloslav Ponkrác]

Ad 1) ASCII kompatibilita je obrovská výhoda. Jednou z důsledků této výhody je to, že UTF-8, stejně jako ASCII nemá problémy s endianitou. Dalším důvodem je, že díky UTF-8 je možné používat okamžitě Unicode na operačních systémech, úložných systémech i v sw, který Unicode nikdy neuměl, nebo s ním od začátku nepočítal (třeba v Linuxu).

Ad 2) UTF-16 původně byl fixed-length, přesněji UCS-2 je a byl fixed length.

Za daleko větší problém považuji ne přehození 16-bitového kódování z fixed-length na UTF-16 v historii, ale zdegradování 31-bitového prostoru Unicode na 21-bitový prostor, stejně jako vyhození surrogate kódů z tohoto prostoru, což s tím souběžně přišlo.

Ad 3) UTF-8 dekodér je zhruba stejně složitý jako UTF-16 dekodér. Oč je UTF-16 jednodušší, to naženě nutností brát v potaz endianitu a tím, že UTF-16 formát není samosynchronizovatlený v případě bajtového proudu dat na rozdíl od UTF-8. Dekodér UTF-8 je jednoznačný, nejsou tam sporné momenty, pokud vynecháme počáteční BOM znak.

Ad 4) Problém endinity není nutně problém každého multibajtového kódování, jak vidíte třeba na multibajtovém kódování UTF-8.

Miloslav Ponkrác

[kralyk z abclinuxu]

ASCII kompatibilita je obrovská výhoda. Jednou z důsledků této výhody je to, že UTF-8, stejně jako ASCII nemá problémy s endianitou. Dalším důvodem je, že díky UTF-8 je možné používat okamžitě Unicode na operačních systémech, úložných systémech i v sw, který Unicode nikdy neuměl, nebo s ním od začátku nepočítal (třeba v Linuxu).

No nevim, to mi přijde jako hack. U software, který s utf-8 nepočítá, bych měl vždy obavu o bezpečnost.

Za daleko větší problém považuji ne přehození 16-bitového kódování z fixed-length na UTF-16 v historii, ale zdegradování 31-bitového prostoru Unicode na 21-bitový prostor, stejně jako vyhození surrogate kódů z tohoto prostoru, což s tím souběžně přišlo.

Silně pochybuju, že by velikost toho prostoru byl problém.

Oč je UTF-16 jednodušší, to naženě nutností brát v potaz endianitu

To beru.

Dekodér UTF-8 je jednoznačný, nejsou tam sporné momenty, pokud vynecháme počáteční BOM znak.

Za sporné momenty považuju osobně: 1) interpretace hodnot nad U+1FFFFF a 2) je potřeba implementovat ořetření pro overlong sekvnce, tzn. každá vícebajtová sekvence má nějakou miniální unicode hodnotu, pod kterou je sekvence neplatná.

[Miloslav Ponkrác]

„No nevim, to mi přijde jako hack. U software, který s utf-8 nepočítá, bych měl vždy obavu o bezpečnost.“

Však to také hack je. Software nemusí počítač, ba ani vědět o UTF-8, pokud je schopno pracovat s celým 8-bitovým rozsahem, pak to pojede.

---

„Silně pochybuju, že by velikost toho prostoru byl problém.“

Abys zároveň v dalším takový problém viděl – v dekódování mimo prostor.

Velikost prostoru je problém. 21 bitů Unicode je pod 2 milióny znaků, to se zaplní poměrně brzy. Už jenom jak prskají Asiaté nad han-unification, které jim počet znaků rozypaného čaje zmenšuje a prizní na několikrát menší počet. Díky tomu Asiaté silně blokují Unicode a používají své sady. Jeden z výsledků prznění vidíte v programovacím jazyce Ruby, kdy jeho autor prostě neuznává Unicode řetězce a tak řetězce jsou v zásadě binární bloky s uloženou identifikací charsetu.

Další problém je plýtvání. Jediné rozumné zpracování Unicode a jediné rozumné kódování je UCS-4/UTF-32. Tedy co znak, to 4 bajty. Jenže na 21bitovém prostoru? To je stejný luxus jako zapalovat doutníky bankovkami.

Jednoduše: Odstřelte dva zpátečníky, konkrétně Javu a Windows, a v tu chvíli pomine jakýkoli důvod mít Unicode 21 bitové, a bude okamžitě 31bitové.

---

„Za sporné momenty považuju osobně:“

„Ad 1) interpretace hodnot nad U+1FFFFF“

To je přesně ten problém velikosti Unicode prostoru. Ta sekvence není neplatná, pouze je nad hodní mezí prostoru Unicode. Tedy nad mezí v roce 2014. Ono až začně být problém neřešitelný, ona se velikost Unicode prostoru zase posune.

„Ad 2) je potřeba implementovat ořetření pro overlong sekvnce, tzn. každá vícebajtová sekvence má nějakou miniální unicode hodnotu, pod kterou je sekvence neplatná.“

Ta potřeba není potřeba. Ba dokonce toto ošetřování je kontraproduktivní. Dekódování i pod minimální hodnotu je jednoznačné. A nejenom to, v praxi se často používá, protože to má výhody. Například je možné zakódovat nulový znak, aniž by se nula vyskytla v bajtech – pak je možné mít ASCIIZ řetězec, který umožňuje mít i nulové znaky uvnitř. A pro jistotu: dost se toto používá, třeba v Javě, v Androidu i jinde.

Tedy problém ad 2) není problém. Každá vícebajtová sekvence je schopna kódovat ockoli od nuly po svůj max.

Shrnu-li, ani ad 1), ani ad 2) není problém dekodéru UTF-8. Problém ani ad 1), ani ad 2) se netýká UTF-8, protože v obou případech je dekódovaná hodnota výsledného kódu znaku zcela jednoznačná.

Pouze je UTF-8 schopno kódovat znaky s odhadem asi 40bitového prostoru (nechce se mi přemýšlet, kolik je to přesně, tak ± pár bitů). Tedy rozsah Unicode je o mnoho řádů menší. Nicméně toto není chyba dekodéru, ani UTF-8, dekódování je zcela jednoznačné.

Miloslav Ponkrác

[kralyk z abclinuxu]

Jednoduše: Odstřelte dva zpátečníky, konkrétně Javu a Windows, a v tu chvíli pomine jakýkoli důvod mít Unicode 21 bitové, a bude okamžitě 31bitové.

No, Java a Widle implementují unicode příšerným způsobem, to souhlasim. Pravděpodobně kvůli Javě a Windowsům mají lidi dojem, že UTF-16 je fixed-length.

Imho by úplně stačilo na UTF-16 aplikovat stejný postup jako na UTF-8 - tj. prostě povolit tak dlouhé sekvence, jak bude potřeba.

Ta potřeba není potřeba. Ba dokonce toto ošetřování je kontraproduktivní. Dekódování i pod minimální hodnotu je jednoznačné.

Dle standardu Unicode jsou overlong sekvence neplatné a neměly by se objevit v UTF-8 stringu. Povolení overlong sekvencí by přineslo problémy např. při porovnávání stringů.

Například je možné zakódovat nulový znak, aniž by se nula vyskytla v bajtech – pak je možné mít ASCIIZ řetězec, který umožňuje mít i nulové znaky uvnitř.

No to je teda pěkná prasárna. Nejen, že to je proti standardu, ale taky je to imho bezpečnostní hazard, protože když pak takový string převedeš do jinýho kódování a pak zase zpátky do UTF-8 anebo ho třeba jen proženeš normalizací, tak se ti tam najednou ta nula nečekaně objeví.

[Miloslav Ponkrác]

„No, Java a Widle implementují unicode příšerným způsobem, to souhlasim. Pravděpodobně kvůli Javě a Windowsům mají lidi dojem, že UTF-16 je fixed-length.“

Java a Windows implementují Unicode správně. Ale uvěřili Unicode consortiu, že Unicode bude mít 16bitový prostor. Takže dnes je implementují jako UTF-16

---

„Imho by úplně stačilo na UTF-16 aplikovat stejný postup jako na UTF-8 - tj. prostě povolit tak dlouhé sekvence, jak bude potřeba.“

Nestačilo, protože v UTF-16 na to už není místo. Historicky totiž UTF-16 se snažilo být co nejpodobnější UCS2. Byla to snaha napravit chybu Unicode consrtia.

---

„Dle standardu Unicode jsou overlong sekvence neplatné a neměly by se objevit v UTF-8 stringu. Povolení overlong sekvencí by přineslo problémy např. při porovnávání stringů.“

Ono by se také podle zákona nemělo krást, programátoři by měli psát pouze bezchybné programy, atd. A hlavně všechny vstupy by měly být dokonalé. A přesto se objevují zloději, přesto programy mají chyby a vstupy jsou narušené. Čím to?

Overlong sekvence se v praxi používají, jak už jsem psal. Dekódování nečiní sebemenší problém. Tudíž nevidím jediný důvod, proč UTF-8 dekodér by neměl tyto sekvence platně dekódovat.

Znovu zdůrazňuji, mluvíme o dekodéru UTF-8, nikoli o relačních operacích nad UTF-8.

---

„No to je teda pěkná prasárna. Nejen, že to je proti standardu, ale taky je to imho bezpečnostní hazard, protože když pak takový string převedeš do jinýho kódování a pak zase zpátky do UTF-8 anebo ho třeba jen proženeš normalizací, tak se ti tam najednou ta nula nečekaně objeví.“

Víte o tom, že UTF-8 standard se několikrát změnil, a to nekompatibilně?

Tahle prasárna, ve skutečnosti velmi čistá věc, protože je logickým nadstandardem UTF-8, a pokud někdo agilně jako aktivní blbec záměrně neoznačuje dekódovatelné UTF-8 sekvence jako chybné, tak i zcela bezpečné.

Tahle věc slouží pouze k přenosu jako obálka pro transfer. A obě strany o tom vědí. A dělá se to na každém rohu, možná i ve Tvém počítači mnohokrát za den. Pro jiné účely se vyrábí UTF-8 normalizované.

---

Ono celé Unicode je nalepovák na nalepovák. Díky Y2K efektu, tedy šetření bajtíkama. Nejdříve Unicode consortium narvalo 16bitový prostor, pak 32bitový prostor, pak 21bitový prostor s odejmutím surrogate znaků jako neplatných. A sním klobouk, jestli jsme na konci změn.

Mezitím se standardy několikrát změnily, a to i UTF-8.

V případě Unicode je dobré nectít pouze standardy, ale dotvořit i vlastním mozkem.

V současné době neexistuje dobré kódování Unicode, každé má nějaké ale.

Miloslav Ponkrác

[kralyk z abclinuxu]

No já s tebou v tom hodnocení unicode v zásadě souhlasim, až na ty overlong sekvence, to je prostě prasárna jak hovado. A že se to dělá? Co to je za argument? Tím je to ještě horší, to je jako když lidi rozšiřují tu fámu o fixed-length UTF-16.

A obě strany o tom vědí.

To je vtip? Obě strany vědí tak maximálně o standardu, který overlong sekvence nepovoluje.

Jestliže je potřeba ve stringu ukládat nuly, tak se to má vyřešit pořádně, tj. nepoužáívat funkce, které předpokládají null-terminated stringy. A ne nějakými takovýmihle hacky, které akorát zavádí další bezpečnostní díru.

Jinak kromě té nuly opravdu nevidím, k čemu by overlong sekvence měly být užitečné.

Viz třeba [1]:

An important note for developers of UTF-8 decoding routines: For security reasons, a UTF-8 decoder must not accept UTF-8 sequences that are longer than necessary to encode a character.

Nebo [2] (DBUS):

The UTF-8 text must be validated strictly: in particular, it must not contain overlong sequences or codepoints above U+10FFFF.

A také Qt považuje overlong UTF-8 za nevalidní (tady nemám citaci, zkusil jsem to na svém systému.) Opravdu pochybuju, že moderní browser by to dovolil.

[Miloslav Ponkrác]

„To je vtip? Obě strany vědí tak maximálně o standardu, který overlong sekvence nepovoluje.“

Takže jeden a tentýž vývojový tým programuje komunikaci, stejně jako vysílač, tak přijímač. Ale ten vývojový tým je tam blbý podle vás, že neví, co si tam pouští.

Zřejmě jim zaměstnavatel, tedy Google a Oracle zakazuje číst interní analýzu a dokumentaci a dovoluje jim číst pouze popis standardů.

Něco vtipnějšího nevymyslíte?

---

„Jestliže je potřeba ve stringu ukládat nuly, tak se to má vyřešit pořádně, tj. nepoužáívat funkce, které předpokládají null-terminated stringy. A ne nějakými takovýmihle hacky, které akorát zavádí další bezpečnostní díru.“

No a oni to vyřešili. Pořádně.

---

Ad 1) a ad 2) Unicode consortium by se více mělo soustředit na promyšlenost svých standardů, než na ztrapňování se.

Je to totiž pouze a jedině vina Unicode consortia, které již poněkolikáté nedomyslelo své standardy.

A znovu, což jste cudně zamlčel, standard UTF-8 se několikrát změnil – nekompatibilně. To, co bylo povoleno v předchozí verzi, je teď zakázáno. Nemluvě vůbec o tom, že UTF-8 není dílo ani původní standard Unicode consortia, Unicode consortium se stará hlavně o to, jak to rozesrat co nejvíce.

---

Nevidím sebemenší problém si v rámci svého sw, či své skupiny projektů, pouštět jakékoli kódování chci. Zatímco Vy v tom problém vidíte.

Samozřejmě, že ven budu pouštět normalizované UTF-8.

A dekodér budu psát tak, aby zvládl vše, co je logicky možné a dekódovatelné. Takový zvládne bez chyby a v souladu se současným UTF-8 standardem všechny validní vstupy a nebude s tím sebemenší problém.

---

„Jinak kromě té nuly opravdu nevidím, k čemu by overlong sekvence měly být užitečné.“

Viz mé příspěvky výše. Google i Oracle užitečnost vidí, a proto je používají.

Overload sekvence umožňují vyhnout se určitým hodnotám bajtů v proudu binárních dat aniž by to jakkoli omezovalo prostor vstupních znaků, které je možné přenést.

[kralyk z abclinuxu]

A znovu, což jste cudně zamlčel, standard UTF-8 se několikrát změnil – nekompatibilně.

Já jsem to nezamlčel, pouze mi není jasný, proč je to relevantní. Ano, 5- a 6-bajtové sekvence byly dřív povoleny, ale overlong sekvence pokud vím ne.

Nevidím sebemenší problém si v rámci svého sw, či své skupiny projektů, pouštět jakékoli kódování chci. Zatímco Vy v tom problém vidíte.

Cudně jsi zamlčel, že máš na mysli pouze interní použití, předtím to tak nevypadalo, předtím jsi tvrdil, že to ošetřování je kontraproduktivní

Každopádně pokud někdo chce používat interně nějakou modifikaci utf-8 nebo něco jinýho, tak prosím, pokud si věří, že domyslí všechny případné důsledky a vedlejší efekty... Je ale potřeba pamatovat, že v takovém případě se nepracuje s UTF-8, nýbrž s vlastním kódováním, které má jiné parametry (mj. co se bezpečnosti týče).

Viz mé příspěvky výše. Google i Oracle užitečnost vidí, a proto je používají.

A kde to používají? Já jen abych věděl, jakému SW se obloukem vyhnout

[Miloslav Ponkrác]

Já nic cudně nezamlčel. Já vše poctivě psal.

Navíc se držím hesla: Buď benevolentní a čekej problémy/šumy/poruchy na vstupech.

A pak hesla: Pokud je standardizátor pitomec, je třeba myslet i za něho. Největší standardizační pitomec je W3C, taková banda hochštaplerů se vidí snad jen na školách s MBA titulem. A Unicode consortium je 1000 × lepší, ale stále ještě nepochopilo, že bude muset řešit problémy, o kterých dělá že neexistují – od asijských znaků, přes rozšíření Unicode prostoru a následné úpravě všech Unicode kódování od UTF-8 a UTF-16 přes další.

---

Ne, i v takovém případě se pracuje s UTF-8. Teprve až si Unicode consortium ujasní a přestane měnit své standardy zhruba každou pětiletku, nebude třeba si nic domýšlet.

UTF-8 nevymyslelo Unicode consortium. Je to vynález autorů operačního systému Plan9, kteří potřebovali řešit přechod na Unicode. Podstatou řešení, za kterým stálo na konci UTF-8, je snaha vyhnout se určitým bajtů, aby se nemuselo měnit API systému.

Dále bych si na Vašem místě zjistil, kde všude u kterých organizací se UTF-8 stanrd vyskytuje a přečetl bych si je také. Unicode consortium to uchvátilo až jako poslední.

---

Tyhle úpravy UTF-8 se dějí přímo v kernelu, takže je třeba se vyhnout Javě i Androidu.

Ale je dosti pravděpodobné, že se to vyskytuje i na mnoha jiných místech. Možná by pomohl jedině kompletní odchod z IT včetně používání cokoli vybavenějšího, než dřevěné kuličkové počítadlo.

[kralyk z abclinuxu]

Ne, i v takovém případě se pracuje s UTF-8. Teprve až si Unicode consortium ujasní a přestane měnit své standardy zhruba každou pětiletku, nebude třeba si nic domýšlet. UTF-8 nevymyslelo Unicode consortium. Je to vynález autorů operačního systému Plan9, kteří potřebovali řešit přechod na Unicode. Podstatou řešení, za kterým stálo na konci UTF-8, je snaha vyhnout se určitým bajtů, aby se nemuselo měnit API systému.

Pokud vím, overlong sekvence byly ilegální od začátku [1]:

When there are multiple ways to encode a value, for example UCS 0, only the shortest encoding is legal.

Takže fakt nevím, proč sem píšeš to všechno o měnění standardu a uchvácení Unicode konsorciem...

Tyhle úpravy UTF-8 se dějí přímo v kernelu, takže je třeba se vyhnout Javě i Androidu.

Javě už se snažím vyhýbat co nejvíce z jiných důvodů, ale je dobře, že vím o dalším, díky.

K tomu kernelu jsem skeptický - [citation needed].

Ale je dosti pravděpodobné, že se to vyskytuje i na mnoha jiných místech.

Ditto - [citation needed]. Mně přijde dosti pravděpodobné, že mlžíš...

[nyan]

Jeden z výsledků prznění vidíte v programovacím jazyce Ruby, kdy jeho autor prostě neuznává Unicode řetězce a tak řetězce jsou v zásadě binární bloky s uloženou identifikací charsetu.

A kde je problem, resp to przneni ?

[:::]

Rekl bych ze mysli przneni asijskych znaku o kterym mluvi v predchozi vete, ne przneni Ruby ("Už jenom jak prskají Asiaté nad han-unification, které jim počet znaků rozypaného čaje zmenšuje a prizní na několikrát menší počet. Díky tomu Asiaté silně blokují Unicode a používají své sady.")

Pokud jde o Ruby tak ten jazyk se me celkove nelibi, ale to ze se nikomu nesnazi vnutit jedno svaty kodovani povazuju za dobrou vec.