Debian dnes slaví 32 let. Ian Murdock oznámil vydání "Debian Linux Release" 16. srpna 1993.
Policisté zadrželi odsouzeného drogového dealera Tomáše Jiřikovského, který daroval ministerstvu spravedlnosti za tehdejšího ministra Pavla Blažka (ODS) bitcoiny v miliardové hodnotě, a zajistili i darovanou kryproměnu. Zadržení Jiřikovského může být podle ministerstva důležité k rozuzlení kauzy, která vypukla koncem května a vedla ke konci Blažka. Zajištění daru podle úřadu potvrzuje závěry dříve publikovaných právních
… více »Administrativa amerického prezidenta Donalda Trumpa jedná o možném převzetí podílu ve výrobci čipů Intel. Agentuře Bloomberg to řekly zdroje obeznámené se situací. Akcie Intelu v reakci na tuto zprávu výrazně posílily. Trump minulý týden označil Tana za konfliktní osobu, a to kvůli jeho vazbám na čínské společnosti, čímž vyvolal nejistotu ohledně dlouholetého úsilí Intelu o obrat v hospodaření. Po pondělní schůzce však prezident o šéfovi Intelu hovořil příznivě.
Společnost Purism stojící za linuxovými telefony a počítači Librem má nově v nabídce postkvantový šifrátor Librem PQC Encryptor.
VirtualBox, tj. multiplatformní virtualizační software, byl vydán v nové verzi 7.2. Přehled novinek v Changelogu. Vypíchnou lze vylepšené GUI.
Eric Migicovsky, zakladatel společnosti Pebble, v lednu oznámil, že má v plánu spustit výrobu nových hodinek Pebble s již open source PebbleOS. V březnu spustil předprodej hodinek Pebble Time 2 (tenkrát ještě pod názvem Core Time 2) za 225 dolarů s dodáním v prosinci. Včera představil jejich konečný vzhled (YouTube).
Byla oznámena nativní podpora protokolu ACME (Automated Certificate Management Environment) ve webovém serveru a reverzní proxy NGINX. Modul nginx-acme je zatím v preview verzi.
Vývojáři KDE oznámili vydání balíku aplikací KDE Gear 25.08. Přehled novinek i s náhledy a videi v oficiálním oznámení.
Společnost Perplexity AI působící v oblasti umělé inteligence (AI) podala nevyžádanou nabídku na převzetí webového prohlížeče Chrome internetové firmy Google za 34,5 miliardy dolarů (zhruba 723 miliard Kč). Informovala o tom včera agentura Reuters. Upozornila, že výše nabídky výrazně převyšuje hodnotu firmy Perplexity. Společnost Google se podle ní k nabídce zatím nevyjádřila.
Intel vydal 34 upozornění na bezpečnostní chyby ve svých produktech. Současně vydal verzi 20250812 mikrokódů pro své procesory řešící 6 bezpečnostních chyb.
Nicmene pro utf-16 mas ten samej problem (2/4 byty).Nemas, protoze to nastane v minimu pripadu. Cili ano, v kodu ten
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czif bude, ale oznaci se za nepravedopodobny a branch prediction to vezme jakoze nenastane...
if (decode(&state, &codepoint, *s++))
continue;
if (codepoint > 0xffff) {
*d++ = (uint16_t)(0xD7C0 + (codepoint >> 10));
*d++ = (uint16_t)(0xDC00 + (codepoint & 0x3FF));
} else {
*d++ = (uint16_t)codepoint;
}
UTF-16 je nejhorší kódování internetu jaké existuje.
Jestli tu chcete udělat dojem, že UTF-16 je nějakým kompromisem, tak lžete. UTF-16 je největší z nouze ctnost.
Unicode kdysi žilo představou, že Unicode se jim vejde do 65535 znaků, což se ukázalo jako utopie. Mezitím se BOHUŽEL rychle Unicode uchytlo a velcí hráči, jako je Microsoft, nebo Sun, nebo IBM tvrdě zadrátovalo do sw 16bitové kódování znaků. Například Windows, Java, ICU a další.
Když se zjistilo, že je 16bitový prostor nestačí, bylo nutné nějak řešit kompatiblitu s již rozšířeným 16 bitových kódováním a vymyslelo se UTF-16.
UTF-16 není žádným kompromisem, je to to nejblbější, nejhloupější a nejméně výhodné kódování, které na Unicode existuje. Důvodem jeho existence je iluze Unicode konsortia, že 16 bitů bude pro Unicode dost a také obrovská rychlost přijetí Unicode na 16 bitech velkými hráči tak, že se to už nedá změnit.
UTF-16 samo o sobě je brzda internetu. Aby vůbec fungovalo, bylo nutné rezervovat 1024 kódů v Unicode tabulce jen proto, aby UTF-16 fungovalo a vyčlenit je a zbytečně zabrat jen pro účely přepínačů v UTF-16.
Dále bylo nutné omezit Unicode z 32 bitů na pouhých 21 bitů, protože debilní UTF-16 kódování víc nezvládne. Nutnost debilního UTF-16 je jediným důvodem, proč Unicode je omezeno na 21 bitů a není využíváno a počítáno z 32 bity.
UTF-16 navíc má problém s little/big endian, takže navíc řešíte pořadí bajtů – to už samotné Vám rychlost vystřílí slušně směrem dolů natolik, aby to výhodné rozhodně nebylo. Kromě toho existuje BOM znak pro detekci, v jakém endianu to je – takže UTF-16 na rozdíl třeba od UTF-8, nebo UTF-32/USC4 nelze procházet zprostředka, ale je nutné vědět, kde je začátek.
UTF-16 nemá žádnou výhodu. Je to to nejhorší co vzniklo. Má všechny nevýhody, které lze nabrat. Je to nalepovák nutný pro kompatibilitu s Javou a Windows, které si bohužel své znaky definovali jako 16 bitové unsigned integery.
Miloslav Ponkrác
www.ponkrac.net
Jestli tu chcete udělat dojem, že UTF-16 je nějakým kompromisem, tak lžete.A nejaky argument?
„Ono utf-16 je především výkonostně-paměťovým kompromisem. Utf-8 je pomalé, utf-32 zabere šílený paměti. Utf-16 je rychlý, ale přitom nezabírá příliš paměti. Proto je v Qt.“
Ale prdlajs.
Pokud máte Qt posazené nad Windows, které nativně pracuje s UTF-16, pak je UTF-16 výhodné proto, že odpadají konverze.
Stejně tak při použití UTF-16 může Qt použít kódy z IBMovského ICU, které slušně pokrývá vše co s Unicode můžete potřebovat a také pracuje s UTF-16.
Je ale roztomilé, jak z nouze ctnosti a rozhodnutí z lenosti děláte nejlepší rozhodnutí – byl by z Vás skvělý tiskový mluvčí či markeťák.
Jinak to ze vetsina znaku se vejde do jednoho 16bit slova ti nepomuze, protoze i kdyby to porusoval jenom 1 znak z milionu, tak stejne musis nahradit indexaci (s konstantni slozitosti) za pruchod (s linearni slozitosti)...To není pravda, stačí si někde udržovat
bool (v případě Qt v QStringu), který bude indikovat, jestli se ve stringu vyskytuje surrogate pair. A když ne, což je většinou, stačí indexace.bool se aktualizuje při změně dat, kdy se string prochází lineárně tak jako tak.
este lepsi, takze vlastne uz z principu nemuzes vedet jakou ta operace bude mit slozitost...O(n), Omega(1), průměrně něco jako 1.
pak se to dostane k nejakymu zakaznikovi do asie a ten ti to omlati o hlavuSe koukni, co všechno je v BMP (ie. v jednom 16-bit znaku) - skoro všechny světový jazyky včetně afaik většiny čínštiny a podobně. Vždyť v tom je i Hlaholice
. V tý supplementary plane jsou fakt hodně specielní věci...Problém je, že tvoje představa o unicode je neúplná, přečti si třeba unicode normalization.no to je prasarna, o tom radsi nechcu nic vedet...
Zkus si napsat funkci tolower(), která bude používat UTF8, a pak funkci, co bude používat UTF16. A zkus to bez použití maker a dalších nesmyslů jako jsou lookup tables.Ta funkce by vypadala nejak takhle:
void tolower(str const &input, str &output)
{
for (iter i : str)
{
output.write_next(char_tolower(*i));
}
}
predpokladam tam ze iter je forward iterator co cte znaky z retezce a ze existuje char_tolower().
Jinak ten kod by vypadal stejne pro utf8 a utf16. Ono v podstate jekejkoli algoritmus by mel vypadat skoro stejne pro utf8 a utf16, protoze obe jsou kodovani s promennou delkou...
Kdyz ty algoritmy budou stejne stejnyNo ty právě stejný nebudou.
tak je zvrhlost pouzit utf16 misto utf8...A to proč? Mně přijde, že zatím všechny argumenty proti utf-16 v této diskusi by se daly shrnout do "Nemám rád utf-16."
No ty právě stejný nebudou.ty stejny budou protoze oboji jsou kodovani s promennou delkou. A pokud stejny nebudou tak v tom utf16 algoritmu je chyba... (napr programator zapomel ze utf16 != ucs2)
A to proč? Mně přijde, že zatím všechny argumenty proti utf-16 v této diskusi by se daly shrnout do "Nemám rád utf-16."1. zbytecne spotrebujes dvojnasobek pameti na ascii 2. zrusis si kompatibilitu s programama co pracujou s ascii 3. problemy s little/big endian A nic tim neziskas. Kdyby ti slo a maximalni rychost a pouzivals kvuli tomu ucs4 tak to pochopim, ale utf16 jenom kombinuje nevyhody ostatnich kodovani - je stejne pomaly jako utf8, ale zabere mnohem vic pameti...
ty stejny budou protoze oboji jsou kodovani s promennou delkou. A pokud stejny nebudou tak v tom utf16 algoritmu je chyba... (napr programator zapomel ze utf16 != ucs2)Ale blbost. Sis asi nepřečet tohle... I při správné implementaci utf-16 je průměrná složitost přístupu ke znaku ve stringu konstatní, ve vzácných případech lineární. V utf-8 je lineární buď vždycky, nebo často.
zrusis si kompatibilitu s programama co pracujou s asciiNo, tak si třeba text tohoto příspěvku ulož do utf-8 a zobraz v programu, co pracuje z ascii, schválně, co uvidíš
problemy s little/big endianJo, tohle se dá celkem brát jako nevýhoda utf-16.
ale utf16 jenom kombinuje nevyhody ostatnich kodovani - je stejne pomaly jako utf8, ale zabere mnohem vic pameti...Nikoli, utf16 je celkově vzato téměř stejně rychlý jako utf-32, ale zabírá téměř dvakrát miň paměti.
No, tak si třeba text tohoto příspěvku ulož do utf-8 a zobraz v programu, co pracuje z ascii, schválně, co uvidíšnejde jenom o to co uvidis. Treba ascii filesystem ti utf8 zvladne bez uprav. utf16 tezko...
Řekl bych to asi takhle: utf-16 je pro svou informační efektivitu mnohem vhodnější při zpracovávání (Ie ve frameworcích jako Qt, v OS, apod.),v tech frameworcich se ale pouziva z historickych duvodu (puvodne si najivne mysleli ze ucs2 bude stacit), ne proto ze by byl vyhodnejsi...
Treba ascii filesystem ti utf8 zvladne bez uprav. utf16 tezko...Tohle vysvětli, proč by to měl být s utf-16 větší problém, než s utf-8?
v tech frameworcich se ale pouziva z historickych duvodu (puvodne si najivne mysleli ze ucs2 bude stacit), ne proto ze by byl vyhodnejsi...Ne, ne, třeba v tom Qt by to změnili, kdyby jim to vadilo. Před časem jsme se o tom bavili na irc #qt a utf-16 tam je právě z výkonostních/paměťových důvodů. Se jich běž zeptat
ty stejny budou protoze oboji jsou kodovani s promennou delkou. A pokud stejny nebudou tak v tom utf16 algoritmu je chyba... (napr programator zapomel ze utf16 != ucs2)Tuto odpověď nechápu. Pokud použiješ ten iterátor, tak konverzi zařídí ten právě on, takže by byla chyba v iterátoru. Toto je ale argument spíš proti tobě, protože pokud zavedeš takovou abstrakci, tak se nemá cenu bavit o kódování.
1. zbytecne spotrebujes dvojnasobek pameti na asciiTo sice ano, ale pořád je to jen 2x víc vs 4x víc (UTF-32). Na druhou stranu spotřebuju míň paměti na znaky, které se do 2-bytů UTF-8 nevlezou (japonština a čínština?). Statisticky bude spotřeba paměti stabilnější než případě UTF-8.
2. zrusis si kompatibilitu s programama co pracujou s asciiAle UTF-8 a ASCII není kompatibilní, a pokud myslíš byte-streamy, tak tam se používá 8bitové kódování by-design, o tom nemá cenu se bavit.
3. problemy s little/big endianInterní reprezentace vždycky používá native-endian. Neřešíme IO, kde se nejspíš použíje UTF-8.
A nic tim neziskas. Kdyby ti slo a maximalni rychost a pouzivals kvuli tomu ucs4 tak to pochopim, ale utf16 jenom kombinuje nevyhody ostatnich kodovani - je stejne pomaly jako utf8, ale zabere mnohem vic pameti...UTF16 spotřebuje v 99.9% případech polovinu paměti co UCS4, takže máš větší šanci, že se vlezeš do cache. UTF-8 je zase velmi náročné na výkon, a paměť ušetří pouze v případě, že se jedná o znaky < 128 (ASCII). UTF-16 je kompromis, sice je to variable-length, ale ten jeden if, co je potřeba, je snadno předvídatelný, a případy, kdy je potřeba použít surrogate pair, jsou výjimečné.
btw. vubec bych se nezdrahal verit tomu ze m$ a sun pote co naivne presli na ucs2 a zjistili ze to nestaci, tak vymysleli a rozsirili tenhle mytus ve snaze svoje rozhodnuti nejak racionalizovat...
Podle zdrojáků Qt mi přijde, že to neřeší nijak, ale možná se mýlím...Máš recht, dokumentace:
QString::length() represents the number of QChars. Thus, it can be that the length does not actually refer to number of actual characters (when the string contains supplementary characters).[odtud].
Tiskni
Sdílej:
