abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
dnes 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
dnes 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 8
včera 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 0
včera 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 6
včera 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
včera 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 22
včera 13:00 | Komunita

MojeFedora.cz informuje, že Fedora 27 dostane podporu pro AAC. Podpora multimediálních formátů je ve výchozí instalaci Fedory tradičně limitovaná kvůli softwarovým patentům, ale desktopový tým Red Hatu se ji i tak snaží v poslední době co nejvíce rozšířit. Už nějaký čas obsahuje kodeky pro MP3, H.264, AC3 a nyní byl přidán také kodek pro další velmi rozšířený zvukový formát – AAC.

Ladislav Hagara | Komentářů: 2
18.10. 23:55 | Pozvánky

Spolek OpenAlt zve příznivce otevřených technologií a otevřeného přístupu na 145. brněnský sraz, který proběhne v pátek 20. října od 18:00 hodin v restauraci Time Out na adrese Novoměstská 2 v Řečkovicích. Jedná se o poslední sraz před konferencí OpenAlt 2017, jež proběhne o víkendu 4. a 5. listopadu 2017 na FIT VUT v Brně. Běží registrace účastníků.

Ladislav Hagara | Komentářů: 0
18.10. 21:44 | Nová verze

Byla vydána verze 5.2.0 multiplatformního virtualizačního nástroje Oracle VM VirtualBox. Jedná se o první stabilní verzi z nové větve 5.2. Z novinek lze zmínit například možnost exportování VM do Oracle Cloudu, bezobslužnou instalaci hostovaného systému nebo vylepšené GUI. Podrobnosti v seznamu změn. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 2
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (11%)
 (1%)
 (1%)
 (2%)
 (73%)
 (13%)
Celkem 130 hlasů
 Komentářů: 7, poslední včera 23:06
    Rozcestník

    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


    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    20.5.2014 23:08 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    vzbudte me az se zbavi utf-16
    The enemy of my enemy is still my enemy.
    Jardík avatar 20.5.2014 23:12 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Qt 5.3
    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ě.
    Věřím v jednoho Boha.
    21.5.2014 19:48 LKG
    Rozbalit Rozbalit vše Re: Qt 5.3
    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 avatar 21.5.2014 20:38 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    Je to marny, je to marny, cekat na "rozumny" toolkit je jak cekat na Godota.

    Nakonec zkoncime u HTML5/JS ci jejich pohrobka.
    You're damned if you do, and you're damned if you don't.
    little.owl avatar 21.5.2014 20:39 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    Tech alokaci na heapu je jak sracek ... Jeste vyrazit MOC.
    You're damned if you do, and you're damned if you don't.
    22.5.2014 11:07 Roger
    Rozbalit Rozbalit vše Re: Qt 5.3
    http://woboq.com/blog/reflection-in-cpp-and-qt-moc.html
    little.owl avatar 22.5.2014 21:22 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    To by sice slo, ale bohuzel to necitelnym zpusobem zvysuje komplexitu jazyka.
    You're damned if you do, and you're damned if you don't.
    24.5.2014 15:51 m][sko
    Rozbalit Rozbalit vše Re: Qt 5.3
    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 avatar 9.6.2014 09:53 Jardík | skóre: 40 | blog: jarda_bloguje
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    Věřím v jednoho Boha.
    oryctolagus avatar 9.6.2014 13:42 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    Viz Obsolete Members for <QtAlgorithms> - doporučují std::foo ...

    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    21.5.2014 13:00 unicode
    Rozbalit Rozbalit vše Re: Qt 5.3
    UTF-16 je prakticke.
    oryctolagus avatar 21.5.2014 14:44 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    To sice souhlasim, ale Qt implementace tak úplně praktická není...
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    21.5.2014 15:49 chrono
    Rozbalit Rozbalit vše Re: Qt 5.3
    Praktické na čo?
    Hans1024 avatar 21.5.2014 15:54 Hans1024 | skóre: 5 | blog: hansovo
    Rozbalit Rozbalit vše Re: Qt 5.3
    Asi pevna delka znaku.
    Veni, vidi, copi
    21.5.2014 17:17 ET
    Rozbalit Rozbalit vše Re: Qt 5.3
    ?

    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 avatar 21.5.2014 18:12 Hans1024 | skóre: 5 | blog: hansovo
    Rozbalit Rozbalit vše Re: Qt 5.3
    Otazka je, jestli se v Qt ty dalsi dva bajty pouzivaji.
    Veni, vidi, copi
    oryctolagus avatar 21.5.2014 18:25 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    oryctolagus avatar 21.5.2014 19:29 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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 :-D
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    21.5.2014 20:19 Tom K | skóre: 20
    Rozbalit Rozbalit vše Re: Qt 5.3
    V programu konsole to funguje špatně, ale např v qt creatoru 3.1.1 pod qt 5.3.0 to už funguje správně.
    echo -n "u48" | sha1sum | head -c3; echo
    oryctolagus avatar 21.5.2014 21:02 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    little.owl avatar 21.5.2014 20:36 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    Treba proto, ze je to vyhodnejsi kodovani pro asijske jazyky, coz byla hlavni motivace proc to Microsoft zacal prosazovat.
    You're damned if you do, and you're damned if you don't.
    21.5.2014 22:38 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    The enemy of my enemy is still my enemy.
    oryctolagus avatar 21.5.2014 23:17 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    Jaký je technický důvod proč UTF-8 není paskvil a UTF-16 jo? Variable-length jsou oba...
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    22.5.2014 00:10 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    The enemy of my enemy is still my enemy.
    22.5.2014 00:11 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    4. UTF-8 nema problem s endianovosti

    pravdepodobne jich bude jeste vic...
    The enemy of my enemy is still my enemy.
    little.owl avatar 22.5.2014 00:18 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    Problemy s endianovosti ma IMHO UCS-2, UTF-16 ma BOM.
    You're damned if you do, and you're damned if you don't.
    22.5.2014 00:23 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    tak to tady mame:

    5. BOM :-)
    The enemy of my enemy is still my enemy.
    22.5.2014 00:32 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    6. Navenek stejne musis komunikovat utf-8. (v tom se snad shodneme)
    The enemy of my enemy is still my enemy.
    little.owl avatar 22.5.2014 00:17 little.owl | skóre: 22 | Brighton
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    You're damned if you do, and you're damned if you don't.
    22.5.2014 00:30 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    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?
    The enemy of my enemy is still my enemy.
    oryctolagus avatar 22.5.2014 01:12 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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...
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    22.5.2014 22:09 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.

    The enemy of my enemy is still my enemy.
    23.5.2014 06:08 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    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
    oryctolagus avatar 23.5.2014 08:30 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    23.5.2014 05:56 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    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
    oryctolagus avatar 23.5.2014 08:24 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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á.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    25.5.2014 03:46 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    „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
    oryctolagus avatar 25.5.2014 12:29 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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í.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    25.5.2014 16:20 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    „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
    oryctolagus avatar 25.5.2014 17:46 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    25.5.2014 18:13 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    „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.
    oryctolagus avatar 25.5.2014 18:34 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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í :-D

    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 :-D
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    25.5.2014 18:50 Miloslav Ponkrác
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    oryctolagus avatar 25.5.2014 19:29 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Qt 5.3
    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žíš...
    Existuje 10 druhů lidí: Ti, co nerozumí binární soustavě, ti, co ano, a ti, kteří znají i balancovanou ternární.
    27.5.2014 12:48 nyan
    Rozbalit Rozbalit vše Re: Qt 5.3
    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 ?
    27.5.2014 14:19 extremni lama | skóre: 14 | blog: e_lama
    Rozbalit Rozbalit vše Re: Qt 5.3
    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.
    The enemy of my enemy is still my enemy.

    Založit nové vláknoNahoru


    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.