Na čem aktuálně pracují vývojáři GNOME a KDE? Pravidelný přehled novinek i s náhledy aplikací v Týden v GNOME a Týden v KDE.
Organizace Apache Software Foundation (ASF) vydala verzi 20 integrovaného vývojového prostředí a vývojové platformy napsané v Javě NetBeans (Wikipedie). Přehled novinek na GitHubu. Instalovat lze také ze Snapcraftu a Flathubu.
Desktopové prostředí Cinnamon, vyvíjené primárně pro distribuci Linux Mint, dospělo do verze 6.0. Seznam změn obsahuje především menší opravy a v říjnovém přehledu novinek v Mintu avizovanou experimentální podporu Waylandu.
OpenZFS (Wikipedie), tj. implementace souborového systému ZFS pro Linux a FreeBSD, byl vydán ve verzích 2.2.2 a 2.1.14. Přináší důležitou opravu chyby vedoucí k možnému poškození dat.
V ownCloudu byly nalezeny tři kritické zranitelnosti: CVE-2023-49103, CVE-2023-49104 a CVE-2023-49105 s CVSS 10.0, 8.7 a 9.8. Zranitelnost CVE-2023-49103 je právě využívána útočníky. Nextcloudu se zranitelnosti netýkají.
I letos vychází řada ajťáckých adventních kalendářů. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2023. Pro programátory v Perlu je určen Perl Advent Calendar 2023. Zájemci o UX mohou sledovat Lean UXmas 2023. Pro zájemce o kybernetickou bezpečnost je určen Advent of Cyber 2023…
Byla vydána verze 2.12 svobodného video editoru Flowblade (GitHub, Wikipedie). Přehled novinek v poznámkách k vydání. Videoukázky funkcí Flowblade na Vimeu. Instalovat lze také z Flathubu.
Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 23.11 Topi. Přehled novinek v Changelogu.
Po 4 měsících vývoje byla vydána nová verze 4.2 multiplatformního open source herního enginu Godot (Wikipedie, GitHub). Přehled novinek i s náhledy v příspěvku na blogu a na YouTube.
Byla vydána nová stabilní verze 23.11 linuxové distribuce NixOS (Wikipedie). Její kódové označení je Tapir. Podrobný přehled novinek v poznámkách k vydání. O balíčky se v NixOS stará správce balíčků Nix.
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: