Svobodný multiplatformní herní engine Bevy napsaný v Rustu byl vydán ve verzi 0.18. Díky 174 přispěvatelům.
Miliardy korun na digitalizaci služeb státu nestačily. Stát do ní v letech 2020 až 2024 vložil víc než 50 miliard korun, ale původní cíl se nepodařilo splnit. Od loňského února měly být služby státu plně digitalizované a občané měli mít právo komunikovat se státem digitálně. Do tohoto data se povedlo plně digitalizovat 18 procent agendových služeb státu. Dnes to uvedl Nejvyšší kontrolní úřad (NKÚ) v souhrnné zprávě o stavu digitalizace v Česku. Zpráva vychází z výsledků víc než 50 kontrol, které NKÚ v posledních pěti letech v tomto oboru uskutečnil.
Nadace Wikimedia, která je provozovatelem internetové encyklopedie Wikipedia, oznámila u příležitosti 25. výročí vzniku encyklopedie nové licenční dohody s firmami vyvíjejícími umělou inteligenci (AI). Mezi partnery encyklopedie tak nově patří Microsoft, Amazon a Meta Platforms, ale také start-up Perplexity a francouzská společnost Mistral AI. Wikimedia má podobnou dohodu od roku 2022 také se společností Google ze skupiny
… více »D7VK byl vydán ve verzi 1.2. Jedná se o fork DXVK implementující překlad volání Direct3D 5, 6 a 7 na Vulkan. DXVK zvládá Direct3D 8, 9, 10 a 11.
Byla vydána verze 12.0.0 knihovny libvirt (Wikipedie) zastřešující různé virtualizační technologie a vytvářející jednotné rozhraní pro správu virtuálních strojů. Současně byl ve verzi 12.0.0 vydán související modul pro Python libvirt-python. Přehled novinek v poznámkách k vydání.
CreepyLink.com je nový zkracovač URL adres, 'díky kterému budou vaše odkazy vypadat tak podezřele, jak je to jen možné'. Například odkaz na abclinuxu.cz tento zkracovač převádí do podoby 'https://netflix.web-safe.link/logger_8oIlgs_free_money.php'. Dle prohlášení autora je CreepyLink alternativou ke zkracovači ShadyURL (repozitář na githubu), který dnes již bohužel není v provozu.
Na blogu Raspberry Pi byla představena rozšiřující deska Raspberry Pi AI HAT+ 2 s akcelerátorem Hailo-10 a 8 GB RAM. Na rozdíl od předchozí Raspberry Pi AI HAT+ podporuje generativní AI. Cena desky je 130 dolarů.
Wikipedie slaví 25. výročí svého založení. Vznikla 15. ledna 2001 jako doplňkový projekt k dnes již neexistující encyklopedii Nupedia. Doména wikipedia.org byla zaregistrována 12. ledna 2001. Zítra proběhne v Praze Večer svobodné kultury, který pořádá spolek Wikimedia ČR.
Po více než dvou letech od vydání předchozí verze 2.12 byla vydána nová stabilní verze 2.14 systémového zavaděče GNU GRUB (GRand Unified Bootloader, Wikipedie). Přehled novinek v souboru NEWS a v aktualizované dokumentaci.
Google Chrome 144 byl prohlášen za stabilní. Nejnovější stabilní verze 144.0.7559.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 10 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře (YouTube).
V IT jde o způsob reprezentace znaků pomocí sekvence přirozených čísel nebo bajtů. K čemu to? Protože počítač nekomunikuje abecedou :-). Nejzákladnějším příkladem je 7bitová znaková sada ASCII, která obsahuje znaky anglické abecedy plus další v informatice využívané znaky. Znaků je celkem 128, což vyplývá ze zmiňovaných 7 bitů, protože 2 ^ 7 = 128. Jenže 128 znaků je málo pro obsažení ostatních abeced a dalších znaků, a proto vznikla další kódování, například různá 8bitová rozšíření ASCII (pro češtinu zejména Windows 1250, ISO 8859-2, CP852) s 256 znaky. I toto ovšem bylo málo, a proto bylo vyvinuto kódování Unicode, jehož patrně nejpoužívanější variantou je UTF-8.
Předpokládám, že je vám asi jasné, co za nejrůznější problémy to přináší. Setkal se s tím snad každý. Nejčastěji když například autor webových stránek zapomene uvést kódování v HTML hlavičce a vy pak místo českých znaků vidíte nějaký paskvil. To je tím, že se kódovaný text převádí do námi čitelné podoby pomocí špatné znakové sady.
V následujících odstavcích si předvedeme různé programy sloužící k převodu kódování textu a jeden, který umí opravit špatně kódované názvy souborů.
Dokonce ani na znaku symbolizujícím nový řádek se tvůrci operačních systémů neshodli. Microsoft používá CR+LF (nebo-li \r\n v C), Apple až do doby Mac OS 9 používal CR (\r) a UN*X systémy (včetně Linuxu a Mac OS X) používají LF (\n). I na to je třeba dávat pozor, v praxi na to člověk narazí třeba při spouštění shellového skriptu s CR+LF konci řádků:
$ ./CRLF.sh bash: ./CRLF.sh: /bin/bash^M: bad interpreter: Adresář nebo soubor neexistuje
Naštěstí to není tak velký problém a poslouží nám zde nástroje dos2unix, mac2unix a unix2dos.
dos2unix soubor_z_windows.txt soubor_z_linuxu.txt
Kódování někdy nelze strojově detekovat tak snadno, jak by si někdo mohl myslet. Je zde mnoho háčků, jako třeba podobnost některých kódování, a také to, že je jich opravdu mnoho. Nicméně existují projekty, které se tímto zabývají a jedním z nich je Enca, která má mimochodem původ v ČR a jejím původním autorem je David Nečas (Yeti), který kdysi působil i zde na AbcLinuxu.
Abych encu vyzkoušel, zkusil jsem pomocí níže jmenovaných programů vytvořit pár souborů s textem ěščřžýáíé v různém kódování.
$ enca utf8.txt Universal transformation format 8 bits; UTF-8 $ enca iso8859-2.txt ISO 8859-2 standard; ISO Latin 2 $ enca cp1250.txt MS-Windows code page 1250 $ enca cp852.txt IBM/MS code page 852; PC (DOS) Latin 2
Enca umí vypsat kódování i ve formátu vhodném pro iconv (přepínač -i), cstocs (-s) nebo podle RFC 1345 (-r).
$ enca -r ~/abcl/kodovani.html UTF-8
Detekce evidentně funguje dobře. Enca umí i převádět kódování (pomocí nástroje enconv), a to buď vestavěným rozhraním nebo pomocí externích knihoven a nástrojů (libiconv, librecode, cstocs – viz níže). Zkusil jsem testovací soubory převést zpátky na UTF-8 s tím, že jsem nechal encu detektovat vstupní kódování a ani zde nebyl problém. Při převodu z windowsích kódování Enca automaticky ukončuje řádky windowsím stylem (CRLF).
$ enconv -x utf8 < cp1250.txt ěščřžýáíé
Pokud chcete místo vestavěného převodníku použít jiný podporovaný, nechte se inspirovat následující ukázkou:
# použije externí program, výchozí je cstocs, lze nastavit přes -E enconv -x cp1250 -C extern < ~/abcl/kodovani.html # použije libiconv enconv -x cp1250 -C iconv < soubor.txt # použije librecode enconv -x cp1250 -C librecode < ../jiny_soubor.txt
iconv je program (a API) sloužící k převodu kódování textu. Je součástí standardu Single UNIX Specification. Poprvé se objevil na systému HP-UX. Na GNU/Linuxu je dostupná svobodná implementace v glibc, což je standardní knihovna programovacího jazyka C od GNU.
Nyní si předvedeme ukázku použití. Pro vypsání všech známých kódování spusťte:
iconv -l
Jelikož iconv dokáže pracovat jak se standardním vstupem a výstupem, tak se soubory, můžete dle potřeby použít přesměrování shellu, roury nebo přímo rozhraní programu. Oba následující příkazy provedou to samé; převedou text z kódování Windows 1250 na UTF-8.
iconv -f cp1250 -t utf8 < cp1250-vstup.txt > utf8-vystup.txt iconv -f cp1250 -t utf8 cp1250-vstup.txt -o utf8-vystup.txt
Projekt Recode je též knihovna i program (recode). Umí využívat iconv a podporuje tak až 300 různých kódování.
# změní kódování souboru „soubor.txt“ z UTF-8 na Windows 1250 recode utf8..cp1250 soubor.txt # nebo když nechcete přepsat původní soubor: recode utf8..cp1250 < soubor.txt > jiny_soubor.txt
Recode podporuje nejen znakové sady, ale i různé fajnovosti jako třeba HTML nebo TeX.
$ recode html..utf8 <<< '&–&' &–&
Cstools obsahují dva perlové moduly + nástroj cstocs. Jde o projekt z české dílny a slouží, podobně jako ostatní výše zmiňované nástroje, ke konverzi znakové sady textu. Použití vypadá následovně:
# cstocs [-i] vstupni_kodovani vystupni_kodovani [soubor(y)] # převod cp1250 na UTF-8 cstocs 1250 utf8 < vstup-v-cp1250.txt > vystup-v-utf8.txt # převede soubor.txt z UTF-8 na ISO 8859-2 cstocs -i utf8 iso8859-2 soubor.txt
Pokud vstupní kódování obsahuje znak, který není ve výstupní znakové sadě, můžete nastavit, jak se má program zachovat. Například --null tyto znaky vynechá a --fillstring="?" je nahradí za otazník.
Perlový nástroj convmv slouží k převodu kódování názvů souborů. Něco takového je třeba, když si do Linuxu zkopírujete soubor z Windows nebo takto (nedejbože) něco přímo stáhnete. Uživatelé Windows například rádi posílají přílohy s diakritikou v názvu. Ať už jste se do této situace dostali jakkoliv, tak vězte, že praktické použití vypadá následovně:
$ convmv -f cp1250 -t utf8 . Starting a dry run without changes… mv "./KOM V�KLAD-1.pol.IV.r.-08.doc" "./KOM VÝKLAD-1.pol.IV.r.-08.doc" No changes to your files done. Use --notest to finally rename the files.
Přepínači -f zadáte jako parametr vstupní kódování, -t výstupní a nakonec uvedete soubory či adresáře. Případně přidáte -r pro rekurzivní procházení adresářů. Toto spustíte, prohlédnete si, co se bude dít, a když vám to vyhovuje, tak teprve poté spustíte totéž navíc s přepínačem --notest, se kterým program soubory již skutečně přejmenuje.
$ convmv -r -f cp1250 -t utf8 . --notest mv "./KOM V�KLAD-1.pol.IV.r.-08.doc" "./KOM VÝKLAD-1.pol.IV.r.-08.doc" Ready!
Po tomhle mi už nezbývá, než doporučit odstranit diakritiku z názvů úplně. Přináší to akorát problémy s přenositelností.
Který z nástrojů na konverzi znakové sady textu si vyberete, to je na vás. Vězte, že v tom, co spolu mají společné, fungují stejně.
$ cat utf8.txt ěščřžýáíé $ cstocs utf8 1250 utf8.txt | iconv -f cp1250 -t utf8 | \ recode utf8..cp1250 | enconv ěščřžýáíé
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Diskuse byla administrátory uzamčena
Slovo žluťoučký má velké Z, ale ta věta přeci zní "Příliš žluťoučký kůň úpěl ďábelské ódy", aby byly obsaženy všechny písmenka s diakritikou. To jen tak mě napadlo
.
Žluťoučký kůň příšerně úpěl ďábelské ódy.a taky tam jsou obsaženy všechny znaky.
a za druhé to logo nemá mezi slovy "kůň" a "úpěl" žádné jiné slovo, takže moje připomínka stále platí
. Ale koukal jsem do nastavení písma v KDE4 a ta věta je tam taky neúplná, takže je to asi globální nedostatek
.
Žluťoučký kůň úpěl příšerné ďábelské ódy.by ti vyhovovalo?
. Asi toho necháme a budeme se věnovat bohulibějším činnostem
.
iconv -t cp1250 -f utf8 soubor -o souborNa co je třeba dávat pozor je tohle
iconv -f cp1250 -t utf8 soubor > soubor # a tohle iconv -f cp1250 -t utf8 < soubor > souborprotože to už tak vesele nedopadne (skončí to prázdným souborem). Ovšem to už není věc iconvu, ale přesměrování shellu.
man iconv neuvadi parametr -o, sam jsem na to prisel nahodou, proste jsem to zkusil a slo to.
iconv -f UTF-8 -t ASCII//TRANSLIT.
Pozor, jeho výsledek závisí na locale:
~> echo Müller | LANG=cs_CZ.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT Muller ~> echo Müller | LANG=de_DE.UTF-8 iconv -f UTF-8 -t ASCII//TRANSLIT Mueller
convmv.
Kdyby tak už konečně tohle všechno zmizelo a všude zavládlo kódování UTF-8! Hned by bylo na světě o něco lépe.
Jenže to by nesměl existovat Mrkvosoft se svými Windows. To je nejhorší brzda veškerého pokroku. Těžko lze najednou prosadit UTF-8 ve všech textech, síťových protokolech, souborových systémech a lokalizacích aplikací, když drtivá většina českých uživatelů tam všude bude mít zmrzačený-latin-2 zvaný Windows-1250.
I samotná existnce „jazykových verzí“ software svědčí o zoufalé technické zaostalosti Mrkvosoftu v této oblasti. Například u KDE uživatele ani nenapadne, že by měl třeba KDE CZ nebo něco podobného! Když se k jednomu počítači připojí čtyři monitory, čtyři klávesnice a čtyři myši, může si k němu sednout Číňan, Japonec, Čech a Egypťan a všichni čtyři budou mít samozřejmě celé prostředí ve svém jazyce. K Windows zasedne stěží jeden jediný člověk a ani tehdy nic nezaručuje, zda tam bude schopen svoji lokalizaci nějak nastavit.
Over the last year or so, as UTF-8 has finally started to gain some acceptance, I've ran into a lot of UTF-8 zealots who think that UTF-8 should be the single global one-size-fits-all standard; that it is the Final Encoding and there will be nothing after it. They seem to think that programs should assume that all input and output is, will be and should be UTF-8 or, if the program doesn't need to deal with individual characters, that it should ignore character sets and encodings altogether, assuming a single global standard – the UTF-8 monoculture.
Have they not learned that assumption is the mother of all fuck-ups?
Já taky moc nesouhlasím, stále nějak tápu nad tím, jak to, že "c" a "с" jsou různé znaky, zatímco "..." a "…" má být jedno a totéž.
Já považuju utf-8 za geniální vynález.Asi tak geniální jako RLE nebo huffman. To jen někteří, co se narodili včera, jsou z toho odvázaní až na půdu.
v praxi pro víceznakové řetězce dokonce převažují ty výhody.Výhody převažují právě pro nevíceznakové.
Urážky si nech na doma, tady na ně neni nikdo zvědavej :). I když doma asi taky, ne, viď :). S tímhle přístupem ze sebe akorát uděláš blbce.Já považuju utf-8 za geniální vynález.Asi tak geniální jako RLE nebo huffman. To jen někteří, co se narodili včera, jsou z toho odvázaní až na půdu.
To je podle mě nesmysl. Ukládání jednoho znaku mi přijde daleko lepší do "integeru" než do bajtového řetězce proměnlivé délky.v praxi pro víceznakové řetězce dokonce převažují ty výhody.Výhody převažují právě pro nevíceznakové.
.
Oni mají jednotlivé komponenty (radikály) toho písma dobře definované.
A co jako? System zapisu zustava debilni a zaostaly...
Zrovna tenhle text není moc dobrý argument pro obhajobu současného zmatku kolem kódování. A z téhož článku cituji:
Almost everyone in their right mind will use an UTF-8 locale for now (unless some obsolete but important piece of software has other requirements), but nobody should be forced to do so, neither now, nor in the future. For, if something better or more suited to some environment comes along, it will then be easier to switch to it.
Autor na jedné straně tvrdí, že kdo nepoužívá UTF-8 locale, ten na tom možná není úplně dobře, pokud jde o rozum. Na druhé straně ostře vybízí k bezbřehé toleranci hraničící s otevřenou podporou totálního chaosu. Poněkud rozporuplný přístup k věci.
V době vzniku toho blogpostu jsem už sice měl UTF-8 locale, ale o pár měsíců dřív jsem ještě používal ISO-8859-2, protože kvůli některým programům (a rozhodně nebyly obsolete) to bylo nezbytné. A potíže s hlavou jsem neměl.
Refusing minimal locale support and encoding conversions, where possible and useful, and assuming instead everyone who wishes to partake in an exchange, to use the same locale and encoding, should not be an option, not if diversity has any value to you. And if that is not the case, I don't want to have anything to do with you or your programs.
Ve světě, kde žiju já, je situace taková: Drtivá většina uživatelů o takových věcech vůbec nerozhoduje a ani nedovede kvalifikovaně rozhodnout! 99% uživatelů netuší, jakým způsobem se ukládají jejich data a jak s tím souvisí texty. Chtějí pouze kompatibilitu. Problém tedy není v tom, že by někdo nutil uživatele, aby byli ve všem stejní. Někdy vidíme pravý opak. Microsoft je toho příkladem. Jeho kódování Windows-1250 andeb zmrzačené-latin-2 na dlouhou dobu zmrazilo pokrok v oblasti ukládání a sdílení textů ve všech jazycích kromě angličtiny.
Zatímco ASCII-assumption je zjevně něco zcela špatného, protože jde v podstatě o předpoklad existence jen dvou jazyků — latiny a angličtiny —, UTF-8-assumption mi přijde jako rozumný předpoklad všude tam, kde není možné kódování explicitně oznámit v metadatech nebo jiným vhodným způsobem. Jednoduše proto, že v dnešním světě neexistuje jazyk, kterému by UTF-8 působil problémy. Nebo snad existuje?
Jsou konvence, jejichž nedodržení vede k potížím. To pochopitelně neznamená, že by se z konvence měl stát zákon. Vznikla by totalita. (V tomto směru s autorem blogpostu souhlasím.) Neodpustím si ovšem jeden protipříklad pro ilustraci:
Kdybych měl dost prostředků, nic mi nebrání zkonstruovat auto, které se řídí gamepadem připojeným do USB portu na palubní desce. Když si ale půjčím pro mě dosud neznámé auto v půjčovně, můžu směle předpokládat, že bude mít volant a pedály. Autor odkazovaného blogpostu ovšem tvrdí, že to předpokládat nesmím a že musím být kdykoliv připraven začít se v přeplněných ulicích velkoměsta učit ovádat auto gamepadem. A to je nesmysl.
Drobná oprava: Poznámka o Windows se měla týkat všech znakových sad Windows-xxxx, ne pouze té středoevropské.
Jednoduše proto, že v dnešním světě neexistuje jazyk, kterému by UTF-8 působil problémy. Nebo snad existuje?
Existuje
A nejsou to žádné jazyky na vymření, třeba čínština a japonština. To si jednou nějaká chytrá hlava kdysi řekla, že "vždyť to vypadá málem stejně" a jednoduše se sjednotily některé varianty znaků. Takže je v Unicode jeden kód pro dva (graficky a foneticky, někdy i významově) různé znaky.
Převedeme-li to, co se stalo s kódováním těmto asiatům do našich zeměpisných šířek, tak je to jako kdyby byl v Unicode jediný kód pro znaky "ů" a "ô" (a klidně i pro další páry, co třeba "m" a "n", taky téměř stejné). Volbou vhodného fontu (slovenský font, český font, font s m, ...) by se rozlišovalo, který z těchto znaků se zobrazí. Kdo by proboha mohl mít tu drzost takový systém nazývat konečným řešením!?
A to jsem ještě nezačal uvádět druhou vlnu zjednodušování čínských znaků (která co jsem se naposledy koukal chybí téměř celá), ten korejský nesmysl co je zaveden, ty chyby co tam zavlekla nepozornost, systematických duplicit atd. atd.
Inu dobrá, takže Microsoft se s desetiletým zpožděním dohrabal k podpoře pro lokalizaci, která byla v linuxových distribucích už dávno. Well done.
Nicméně tato lokalizace je (předpokládám) k dispozici jenom za příplatek a jenom u některých verzí. Ostatní verze mají antifeature. Což je skoro totéž, jako by tam nebyla.
Mimochodem, znamená to, že když spustím jeden počítač s Windows a bude s ním přes RDP pracovat 10 uživatelů paralelně, bude mít každý z nich svoji lokalizaci? Mám takové tušení, že v tom zase bude háček...
Rád věřím, že na nějakých Windows Ultra-Hyper-Server-Stojím-Sto-Litrů to asi půjde, ale nějaká Vista, což jsou zatím poslední Windows, které jsem viděl, se ke změně locale moc neměla. Asi to nebyla edice Hyper-Kdesicosi, nevím...
To je podobné, jako když se se mnou tuhle někdo hádal, že 64-bitová verze Windows podporuje víc než 8 GB RAM. Skutečně? Vista Home Basic rozhodně ne. 
Po tomhle mi už nezbývá, než doporučit odstranit diakritiku z názvů úplně.Ja bych naopak doporucil se s tim naucit zit. Protoze se ti jinak stane, ze musis neco udelat na stroji, kde jsou nazvy obsahujici pomalu i konce radek, a kdyz nevis co s tim, tak koncis.