Byl publikován přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie) za uplynulé dva měsíce. Servo zvládne už i Gmail. Zakázány jsou příspěvky generované pomocí AI.
Raspberry Pi Connect, tj. oficiální služba Raspberry Pi pro vzdálený přístup k jednodeskovým počítačům Raspberry Pi z webového prohlížeče, byla vydána v nové verzi 2.5. Nejedná se už o beta verzi.
Google zveřejnil seznam 1272 projektů (vývojářů) od 185 organizací přijatých do letošního, již jednadvacátého, Google Summer of Code. Plánovaným vylepšením v grafických a multimediálních aplikacích se věnuje článek na Libre Arts.
Byla vydána (𝕏) dubnová aktualizace aneb nová verze 1.100 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a videi v poznámkách k vydání. Ve verzi 1.100 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána v nové verzi 2025.5.
OpenSearch (Wikipedie) byl vydán ve verzi 3.0. Podrobnosti v poznámkách k vydání. Jedná se o fork projektů Elasticsearch a Kibana.
PyXL je koncept procesora, ktorý dokáže priamo spúštat Python kód bez nutnosti prekladu ci Micropythonu. Podľa testov autora je pri 100 MHz približne 30x rýchlejší pri riadeni GPIO nez Micropython na Pyboard taktovanej na 168 MHz.
Grafana (Wikipedie), tj. open source nástroj pro vizualizaci různých metrik a s ní související dotazování, upozorňování a lepší porozumění, byla vydána ve verzi 12.0. Přehled novinek v aktualizované dokumentaci.
Raspberry Pi OS, oficiální operační systém pro Raspberry Pi, byl vydán v nové verzi 2025-05-06. Přehled novinek v příspěvku na blogu Raspberry Pi a poznámkách k vydání. Pravděpodobně se jedná o poslední verzi postavenou na Debianu 12 Bookworm. Následující verze by již měla být postavena na Debianu 13 Trixie.
Richard Stallman dnes v Liberci přednáší o svobodném softwaru a svobodě v digitální společnosti. Od 16:30 v aule budovy G na Technické univerzitě v Liberci. V anglickém jazyce s automaticky generovanými českými titulky. Vstup je zdarma i pro širokou veřejnost.
Vyšlo Qt SDK verze 1.1, tato nová verze sjednocuje dříve rozdělená SDK pro desktop a mobilní platformy. Dále nově umožňuje zveřejňovat aplikace na Ovi Store. V rámci SDK 1.1 vychází knihovna Qt 4.7.3, Qt Mobility 1.1.3, Qt Creator 2.1/2.2RC a Qt Simulator 1.1. Více informací také v Qt blogu.
Tiskni
Sdílej:
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.cz
if 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].