Jakub Jelínek oznámil vydání verze 15.1 (15.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 15. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Byly vyhlášeny výsledky letošní volby vedoucího projektu Debian (DPL, Wikipedie). Staronovým vedoucím zůstává Andreas Tille.
Jason Citron končí jako CEO Discordu. Od pondělí 28. dubna nastupuje nový CEO Humam Sakhnini, bývalý CSO Activision Blizzard.
Článek na Libre Arts představuje baskytarový multiefekt Anagram od společnosti Darkglass Electronics. S Linuxem uvnitř (licence, GitHub).
Městský soud v Praze vyhlásil rozsudek, který vyhověl žalobě novináře Jana Cibulky, který s podporou spolku IuRe (Iuridicum Remedium) požadoval omluvu od státu za to, že česká legislativa nařizuje operátorům uchovávat metadata o elektronické komunikaci. To je přitom v rozporu s právem. Stát se musí novináři omluvit a zaplatit náklady řízení. Především je ale součástí přelomové rozhodnutí o nelegálnosti shromažďování dat a o
… více »Americké technologické firmy Apple a Meta Platforms porušily pravidla na ochranu unijního trhu, uvedla včera Evropská komise (EK). Firmám proto vyměřila pokutu – Applu 500 milionů eur (12,5 miliardy Kč) a Metě 200 milionů eur (pět miliard Kč). Komise to oznámila v tiskové zprávě. Jde o první pokuty, které souvisejí s unijním nařízením o digitálních trzích (DMA). „Evropská komise zjistila, že Apple porušil povinnost vyplývající z nařízení
… více »Americká společnost OpenAI, která stojí za chatovacím robotem ChatGPT, by měla zájem o webový prohlížeč Chrome, pokud by jeho současný majitel, společnost Google, byl donucen ho prodat. Při slyšení u antimonopolního soudu ve Washingtonu to řekl šéf produktové divize ChatGPT Nick Turley.
Po roce vývoje od vydání verze 1.26.0 byla vydána nová stabilní verze 1.28.0 webového serveru a reverzní proxy nginx (Wikipedie). Nová verze přináší řadu novinek. Podrobný přehled v souboru CHANGES-1.28.
Byla vydána nová verze 10.0.0 otevřeného emulátoru procesorů a virtualizačního nástroje QEMU (Wikipedie). Přispělo 211 vývojářů. Provedeno bylo více než 2 800 commitů. Přehled úprav a nových vlastností v seznamu změn.
42 svobodných a otevřených projektů získalo finanční podporu od NLnet Foundation (Wikipedie).
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.
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
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.