Byl vydán Debian 12.11, tj. jedenáctá opravná verze Debianu 12 s kódovým názvem Bookworm. Řešeny jsou především bezpečnostní problémy, ale také několik vážných chyb. Instalační média Debianu 12 lze samozřejmě nadále k instalaci používat. Po instalaci stačí systém aktualizovat.
Makepad dospěl do verze 1.0 (𝕏). Jedná se o multiplatformní open source UI framework pro Rust napsaný v Rustu.
Konference OpenAlt 2025 hledá přednášející. Proběhne o víkendu 1. a 2. listopadu na půdě Fakulty informačních technologií VUT v Brně. Témata konference jsou: Otevřený a svobodný software, IoT a Hnutí tvůrců, Vzdělávání, Bezpečnost a soukromí, Otevřená společnost, komunity a data, OpenMobility a další.
Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 153 (pdf)
Byl publikován květnový přehled dění a novinek z vývoje Asahi Linuxu, tj. Linuxu pro Apple Silicon. Vývojáře lze podpořit na Open Collective a GitHub Sponsors.
Programovací jazyk Rust (Wikipedie) dnes slaví 10 let od vydání verze 1.0. Přímo na oslavě byla vydána nová verze 1.87.0. Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.
Evropská komise obvinila provozovatele čínské platformy TikTok z porušování pravidel EU kvůli netransparentnosti v reklamě. Komise, která v EU plní i funkci antimonopolního úřadu, to dnes uvedla v tiskové zprávě. TikTok, který patří čínské firmě ByteDance, se může k předběžnému nálezu vyjádřit. Pokud ale podezření komise nevyvrátí, hrozí mu pokuta až do šesti procent z ročního globálního obratu.
Sovereign Tech Agency (Wikipedie), tj. agentura zabezpečující financování svobodného a otevřeného softwaru německou vládou, podpoří GFortran částkou 360 000 eur.
Microsoft hodlá zrušit zhruba tři procenta pracovních míst. Microsoft na konci loňského června zaměstnával kolem 228.000 lidí. Tři procenta z tohoto počtu představují téměř 7000 pracovních míst.
V říjnu loňského roku provedl Úřad pro ochranu hospodářské soutěže (ÚOHS) místní šetření u společnosti Seznam.cz. Krajský soud v Brně tento týden konstatoval, že toto šetření bylo nezákonné.
Dobry den, zacinam s mysql a tvorim si novou tabulku pres phpmyadmin. Zde pro kazdy sloupec vybiram "collation". Pochopil jsem, ze to bude asi kodovani textu v tabulce. Chci tam dat utf8, ale tech je tam vice typu, tak by me zajimalo jaky je rozdil mezi temito:
utf8_czech_ci utf8_general_ci utf8_unicode_ci
A ktery tedy vybrat.
Rozdil by mel byt v razeni podle textovych polozek (ORDER BY), pokud tabulka obsahuje stringy v cestine tak bych asi dal utf8_czech_ci, jinak to je asi jedno.
Předem informace: není není třeba collation
uvádět u každého sloupce, stačí uvést collation u databáze či u vytváření tabulky.
U sloupce to pak stačí uvést jen u odlišného zvoleného třídění, například pro sloupce s ruštinou.
Collation
se při vytváření tabulky dědí z datbáze přes tabulku na sloupec.
Pro pochopení rozdílů mezi 2. a 3. viz zde
... (máme nejsložitější pravidla třídění v evropských jazycích).
Dalo by se tohle nejak dolozit? Nesnazim se tvrzeni napadat, jen by me zajimali nejake podrobnosti. Diky.
Anebo testem v MySql :):
Setřídění český měst ve sloupci utf8_bin s indexem a výsledný čas
S použitím clausule COLLATION
v ORDER BY
.
utf8_czech_ci 0.0350 utf8_turkish_ci 0.0330 utf8_hungarian_ci 0.0330 utf8_unicode_ci 0.0329 utf8_swedish_ci 0.0329 utf8_spanish_ci 0.0329 utf8_spanish_ci 0.0329 utf8_general_ci 0.0187 (není průkazné protože sloupec má index utf8_bin)
Zde pro kazdy sloupec vybiram "collation". Pochopil jsem, ze to bude asi kodovani textu v tabulce.
Ostatní už to naznačili, ale spíš předpokládali, že víte, co to je. Collation není kódování, ale označení pro soubor pravidel, jak porovnávat řetězce. Protože stejné kódování může používat více jazyků (iso-8859-1 celá západní Evropa, iso-8859-2 celá střední a východní Evropa píšící latinkou, UTF-8 všichni), ale pro každý jazyk mohou být pravidla porovnávání řetězců jiná; někdy je i víc variant pro stejný jazyk (typicky používá-li se v různých zemích).
Nejčastěji odlišnosti vznikají tak, že některé kombinace znaků se při porovnávání chovají jako "slitek", tj. nedělitelný objekt, kterému se přiřadí určitá pozice v abecedě. Příkladem je třeba "ch" v češtině (pokud byste chtěl řadit úplně podle normy, tak to ani s ním nebude tak jednoduché, ale v praxi se to ignoruje) nebo "ck" či "ss" v němčině. Odtud pochází termín collation, stejně jako LC_COLLATE
v locales.
Takže u řetězcových datových typů definujete (na úrovni databáze, tabulky nebo konkrétního sloupce) jednak kódování (z historických důvodů se většinou nepřesně používá termín charset), jednak collation. Pro každé kódování máte ale k dispozici jen z těch collation, které jsou pro něj určena.
Správná připomínka.
utf8_xxxx_xx jsou předpokládány znaky v kódování utf8 a to xxxx_xx jen říká jak se budou řadit.
ad. „ale v praxi se to ignoruje“ = špatná praxe, a právě collation utf8_czech_ci to zatřídí správně včetně 'CH'.
PS:
Nezapomínat pak v každém dotazu (kde je to třeba) uvést: ORDER BY sloupec
, protože bez této clausule je řazení NEdefinované.
U MySQL a typu tabulek MyISAM jakmile mažete a vkládáte, tak vám to bez ORDER BY sloupec
bude sypat záznamy, tak jak jsou fyzicky uloženy v souboru, NE podle primárního indexu !!!
Ta poznámka "ale v praxi se to ignoruje" se týkala něčeho trochu jiného. V normě se totiž píše, že s kombinací znaků "ch" se nakládá jako se slitkem pouze v případě, že opravdu reprezentuje hlásku "ch". Pokud by se ale např. jednalo o složené slovo, kde první část končí "c" a druhá začíná "h", pak se to má brát jako dvě samostatná písmena i při porovnávání. Jak to má chudák program poznat, to už nám ale autoři normy neříkají. Naštěstí je tam jakási poznámka, že tam, kde by to bylo technicky obtížně realizovatelné, je možné některé špeky (jsou tam i horší vylomeniny) ignorovat. V praxi se tedy u českých collation kombinace "ch" bere jako slitek vždy.
U MySQL a typu tabulek MyISAM jakmile mažete a vkládáte, tak vám to bez ORDER BY sloupec bude sypat záznamy, tak jak jsou fyzicky uloženy v souboru, NE podle primárního indexu !!!
To je celkem logické a není to specialita MySQL. Pokud nepoužijete klauzuli order by
, je pořadí záznamů nedefinované a bylo by krajně nepraktické, pokud by se databáze v takovém případě zdržovala řazením. Výjimkou jsou samozřejmě situace, kdy je z nějakých důvodů vhodnější řadit tak jako tak, typicky třeba při použití klauzule group by
.
ad. Ignoruje … - sorry nepochopil jsem
ad. ORDER BY, ano specifikace SQL přímo říká že to není definováno. Nemyslel jsem, že je to specialita MySQL, chtěl jsem jen upozornit na tuto skutečnost a kde se na ni zaručeně narazí, protože například MySql + InnoDB se toto neprojeví (jestli se nepletu) díky internímu způsobu zapisování záznamů, a M$SQL 2005 (opět jestli se nepletu), má někde napsáno, že se řadí, v takovém případě, podle primárního indexu.
Je to častá chyba a neprojeví se často hned - tak jsem to jen chtěl někomu říct :)
Tiskni
Sdílej: