Open source download manager Fatrat povstal z popela. Autor k dvacetiletému výročí projektu přidal do vínku podporu nejnovější knihovny libtorrent, rozhraní portoval na QT6, došlo k nahrazení podpory java rozšíření pythonem. Webové rozhraní bylo přepsáno s podporou mobilních zařízení. Aplikaci je taktéž možno zkompilovat bez podpory GUI. Více informací v releases.
Zranitelnost Broccoli2Shell (CVE-2026-111497) v kompresní knihovně Brotli se netýká pouze Node.js. Ohroženy jsou také aplikace využívající HTTP. Knihovnu používají webové prohlížeče, servery i řada dalších aplikací a technologií, například také Python nebo Bun. Identifikace všech zranitelných komponent může být obtížná, protože knihovna bývá součástí dalších softwarových balíčků nebo je přímo začleněna do spustitelných souborů aplikací.
Quad9, švýcarský celosvětově působící neziskový poskytovatel DNS, od 24. listopadu 2026 ukončí své služby ve Francii kvůli soudnímu sporu s katarskou televizní stanicí beIN. Ta požadovala blokování domén, které podle ní nelegálně zpřístupňují sportovní přenosy. Francouzský soud Katarům vyhověl a nařídil (🇫🇷, PDF) Quad9 blokaci zavést, pod hrozbou pokuty 1000 eur denně. Provozovatel příkaz odmítá s tím, že blokace
… více »Článek na blogu APNIC vysvětluje, jak správně vytvářet a používat ASPA záznamy — podepsané objekty v RPKI, které uvádějí, kteří poskytovatelé směrování jsou pro dané autonomní číslo (ASN) oprávněni. Síťoví operátoři je mohou využít k ověřování tras BGP a k odhalování úniků tras či podvržených tras.
Byla vydána (𝕏) verze 8.0.0 open source programu pro prolamování hesel hashcat (GitHub, Wikipedie). Přehled novinek v příspěvku v diskusním fóru a pdf.
Byla vydána (𝕏, Bluesky) nová verze 2026.3 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem 6 nových nástrojů v oficiálním oznámení na blogu.
Výzkumníci ukazují, jak mohou otevřené tunely a IPv6 Extension Headers synchronizovat pakety do krátkých provozních špiček. V kontrolovaném experimentu naměřili přes 180násobnou koncentraci paketového toku vůči průměrné rychlosti odesílání — nikoli 180násobné zvětšení objemu dat. Článek obsahuje metodiku, limity měření i mitigace pro GRE, IPIP a další tunely.
Po velkém úspěchu prvního MobileLinux Hackdaye se vracíme do Českých Budějovic s druhým ročníkem. V pátek 30. října 2026 od 10:00 se v prostorách Jihočeské univerzity uskuteční Embedded & MobileLinux Hackday #2. Těšit se můžete na témata jako Immutable Linux na telefonech (BengalOS), U-Boot a upstream vývoj, AI optimalizace pro embedded systémy nebo otevřený hardware. Nebude chybět praktické hackování, sdílení zkušeností a možnost … více »
Dne 21. října 2026 vydal projekt Node.js bezpečnostní aktualizace opravující deset zranitelností, včetně jedné umožňující potenciální vzdálené spuštění kódu (RCE). Nejzajímavější je CVE-2026-111497, chyba dekodéru Brotli, kterou objevili výzkumníci využívající OpenAI Codex Security. Chyba je v nativním dekodéru Brotli, nikoli v samotném JavaScriptu. Speciálně vytvořený komprimovaný vstup způsobí, že dekodér zamění
… více »unsigned int convUnicode(int x) {
unsigned int y = 0, m = 0, n = 0;
m = y = n = x;
x = (x & 0x7000000);
x = x >> 6;
n = (n & 0xF0000);
n = n >> 4;
m = (m & 0x3F00);
m = m >> 2;
y = (y & 0x003F);
x = x | y | m | n;
printf("0x%X\n", x);
return 0;
}
Problem je ten, ze u jednobitovych znaku mi fce na outputu dava korektne jen cisla 1-39- 40 vypise jako 0x0, 41 jako 0x1 atd. az do 80. 80 vypise jako 0x0, 81 jako 0x1... proste to jakoby funguje jen po cislo 39 ap ka to jede od znovu. VIcebitove vstupy jsem zatim netestoval moc, dosud se zdaji byt korektni, ale musim to testovat na vetsi skale cisel.
Opravdu by me zajimalo, v cem delam chybu. S praci na bitove urovni mam v C opravdu minimalni zkusenosti, takze by me zajimalo, co a jak delam blbe. Idealne, kdyby mi nekdo poradil, nebo apson navedl na zpusob korektni implemntace. Nechci aby to nekdo vyresil za me, jen chci nakopnout.
Řešení dotazu:
Unicode kód od - do Binární zápis znaku v UTF-8
0000 0000 - 0000 007F 0xxxxxxx
0000 0080 - 0000 07FF 110xxxxx 10xxxxxx
0000 0800 - 0000 FFFF 1110xxxx 10xxxxxx 10xxxxxx
0001 0000 - 001F FFFF 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx
Nicmene, i po uprave masek na 007F se mi HEX korektne vypisuje jen do vstupu 79 (= 0x79). 80 uz koduje jako 0x0.. :( Je jasne, ze do 127 se jedna porad o ASCII, ale jak to namaskovat, aby tam byla ta implementace UTF-8 do UNICODE?
U-00000000 – U-0000007F: 0xxxxxxx U-00000080 – U-000007FF: 110xxxxx 10xxxxxx U-00000800 – U-0000FFFF: 1110xxxx 10xxxxxx 10xxxxxx U-00010000 – U-001FFFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx U-00200000 – U-03FFFFFF: 111110xx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx U-04000000 – U-7FFFFFFF: 1111110x 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxx 10xxxxxNerudovska otazka, co s ni? 0 - 7F to je prvnich 127, tedy ASCII. Otazka zni: uzit nejakou masku? U-00000080 – U-000007FF:. Tak a ted jak zprvniho bajtu oriznout 110 a z druheho 10? Kdyz pouziju:
scanf("%X", &x);
x = (x & 0x7FF);
printf("0x%X\n", x);
Tak se zda, ze to dekoduje v pohode.
Ale v pripade 3 bajtoveho (U-00000800 – U-0000FFFF) znaku to uz nedekoduje v pohode:
x = (x & 0xFFFF);Takze ja proste nevim jak spravne vyuzit tu tabulku z wiki a dalsich odkazu, nevim jak to spravne namaskovat. Mozna by to slo postupnym rozlozenim cisla na jednotlive bajty a ty pak orezat. Ale nevim, jak se takovy rozklad v C implementuje...
Tak a ted jak zprvniho bajtu oriznout 110 a z druheho 10?Musíš oříznout ty správné bity, použít opererátory bitového posunu << a >>, abys je posunul, kam patří ve výsledném bajtu, a zkombinovat výsledek pomocí |. P.S.: Převod UTF-8 do UNICODE nedává smysl. UTF-8 je representace Unicode, takže co je v UTF-8, to už je v Unicode.
if (x <= 0x7F){ //testuje zda je znak 1 bajtovy ANSII
printf("0x%X\n", x);
} else if ((x > 0x7F) && (x <= 0xBF)) { //testuje zda je znak jednobajtovy, s hodnotou vyssi nez ANSII
x = (x & 0x003f);
printf("0x%X\n", x);
} else if ((x > 0xBF) && (x <= 0xDFBF)){ //testuje dvoubajtove znaky
x = ((x & 0x1f00) >> 2) | (x & 0x003f);
printf("0x%X\n", x);
} else if ( (x > 0xDFBF) && (x <= 0xEFBFBF)) { //testuje tribajtove znaky
x = (((x & 0xF0000) >> 4) | ((x & 0x3f00) >>2) | (x & 0x003f));
printf("0x%X\n", x);
} else if ((x > 0xEFBFBF) && (x <= 0xF7BFBFBF )){ //testuje ctyrbajtove znaky
x = ( ((x & 0x7000000) >> 6) | ((x & 0x3f0000) >> 4) | ((x & 0x3f00) >>2) | (x & 0x003f));
printf("0x%X\n", x);
}
return 0;
}
Jinak UTF-8 do unicode samozreme smysl ma:
http://www.utf8-chartable.de/Cely priklad je vlastne prevodnik z UTF-8 do UNICODE a z UNICODE do UTF-16.
Jinak UTF-8 do unicode samozreme smysl maNe, tato věta je výrazem nepochopení vztahu Unicode a UTF-8. UTF-8 můžeš převést leda do nějaké jiné representace Unicode, ale pořád bude nějak representováno. Tabulka bloku prvních 256 znaků má dokazovat konkrétně co?
Vašou úlohou je napísať program, ktorý číta hexadecimálne kódy znakov UTF-8 zo štandardného vstupu. Jednotlivé kódy dekóduje najprv do hodnoty znaku v Unicode tabuľke, následne znak opäť zakóduje podľa UTF-16."dekoduje do hodnoty v UNICODE"
if (x <= 0xBF){ //testuje zda je znak 1 bajtovy
printf("0x%X\n", x);
Tiskni
Sdílej: