Unicode 12.0.0 přináší nové znaky včetně emoji, celkem obsahuje 137 929 znaků

Je pro mě obtížené pochopit, proč se tvůrci Unicode nesnažili zastavit na počtu 65 000 znaků, aby se vešli do dvou bajtů. Je teď těch znaků tolik jenom vlivem různých emoji a dalších serepetiček, nebo by se do dvou bajtů nevešly ani běžně používané jazyky (asijské)? Současná situace mi připadá trochu blbá, máme spoustu míst, kde se sedmibitové ASCII ukládá do 4 bajtů na znak. Kolik bajtů na znak naopak má text kódovaný nějakým tím UTF s proměnným počtem b/z, složený jen z těch nejhorších znaků, už si radši ani nepředstavuju.

to je tezke. tohle :), tohle :( nebo tohle jsou uz natolik pouzivane symboly, ze si to snad unicode special zaslouzilo. jenze tim se otviraji vratka zaplave vsech jinych (kdo posuzuje dulezitost smajliku?), a pak to konci symbolem pro lenochochoda a cerveny ctverec. (mimochodem, bude se v budoucnu rozlisovat i lenochod dvouprsty a triprsty?)

svym zpusobem mi vic vadi znaky U+3380 az U+33FF. treba U+3380 je specialni znak pro pikoamper. ale z definice systemu SI je pikoamper slozenina dvou znaku piko a amper, a pise se jako dva znaky za sebou pA. proc z toho ti chytraci udelali jeden znak netusim, a nema to logiku.

Ty woe fakt:
$ echo -e "\U00003380"
㎀

Na co je uz len toto dobre, netusim, kedze fakt podla SI sa proste pisu 2 pismena.

Ale aspon pre srandu (macicka a vlk), ked uz mame ten unicode:
$ echo -e "\U0001F639"; echo -e "\U0001F43A";

tak picoamper, to je zvracenina. Dokazu pochopit kombinaci fi, protoze pri tisku se tahle sekvence tiskne trochu jinak nez f i. Ale picoamper nema nejmensi duvod byt slozenina! Pak nastavaji problemy, ze
1. nemuzes vyhledavat v textu
2. nekdo nebude mit tento symbol ve fontu, tak to neuvidi nebo nevytiskne.
Mam napriklad jeden manual, kde chybi vsechny fi. Nedokazete si predstavit, jak blbe se to cte a jak casto se to v textu vyskytuje.

Jeste jsem chtel dodat - pA jsou 2 bytes 70 41 (a jsem schopnej si je pamatovat zpameti)
U+3380 jsou v utf8 tri bytes e3 8e 80
To je uspora. Skoro jako letni cas.

Oni se o to docela dlouho snažili a máme z toho docela dost pohrobků, např. kódování UCS-2, které znaky větší než 2¹⁶ neumí kódovat, nebo UTF-16, které je dvoubajtové a znaky nad 2¹⁶ kóduje pomocí surrogate pairs. Jenže se ukázalo, jak jste správně odhadl, že se tam asijské jazyky nevejdou. V Unicode 1.0 byla nějaká omezená sada společných znaků, se kterými si prý asijské jazyky měly vystačit, ale v příslušných státech na to měli jiný názor.

Kde je těch „spousta míst“, kde se používá UTF-32? Pokud vím, obvykle se používá UTF-8 nebo UTF-16.

Text složený z „těch nejhorších znaků“ bude výjimečný, ony se na konec přeci jen přidávají málo používané znaky. A asijské jazyky většinou používají jiná kódování, než UTF-8. S běžnými texty s vícebajtovými znaky se asi paradoxně ve střední Evropě setkáváme podstatně častěji, než v jiných částech světa. Stále se setkávám s chybami ve zpracování vícebajtových sekvencí v UTF-8. Dříve jsem si říkal, jak je to možné, vždyť se s UTF-8 pracuje na celém světě, jak je možné, že je v tom stále tolik chyb. Jediné vysvětlení, které mne napadá, je to, že tam, kde se používá latinka, se většinou používá „UTF-8“, ale ve skutečnosti jsou všechny znaky jednobajtové. Úplně jiné jazyky, jako ty asijské, používají jiná kódování. Tím pádem UTF-8, kde se vícebajtové znaky občas vyskytují (takže se vyplatí používat UTF-8, ale zase je to tak často, aby si té chyby vůbec někdo všiml), je používané relativně málo, takže i s naší prťavou češtinou na ty chyby občas narazím.

Ono napsat UTF8 aplikaci ve starších programovacích jazycích jako je např. C zas není až tak triviální - v Cčku je podpora wide charů, UTF8 char je vlastně vlastně ukazatel na řetězec. Některé knihovny chtějí wide chary, jiné UTF8 stringy. Docela jednoduchá úloha jako převod písmena z malého na velké již vyžaduje převod na wide char nebo zas speciální knihovnu. Pak, když už se to poladí, tak s tím problém nebývá - i když pořád pak člověk může narazit na špeky typu 1 UTF8 znak může mít šířku 1, 1.5 a 2 znaku - což pro terminál znamená kontrolovat jak šířku v bajtech, tak šířku zobrazení.

Délka jednoho znaku je ještě v pohodě, ale to, že se dá spojit více znaku do jednoho, to je teprve špek: ‍‍‍

Jinak většina aplikací s řetězci či znaky nemanipuluje, v drtivé většině maximálně formou spojení řetězců (do jiného řetězce nebo stream). Zobrazení pak řeší obvykle grafický toolkit, bez které stejně není reálné aplikaci napsat... Terminál je zcela transparentní - buď si s tím poradí nebo ne, ale aplikaci to neovlivní.

> Docela jednoduchá úloha jako převod písmena z malého na velké již vyžaduje převod na wide char nebo zas speciální knihovnu.

Převod písmena z velkého na malé není ve vší obecnosti (tedy s přihlédnutí ke všem jazykům používajících nějakou formu rozdělení velkých a malých písmen) vůbec jednoduchá úloha. Podívejme se třeba na turečtinu, která rozlišuje tři formy písmena i: bez tečky (ı/I), s tečkou (i/İ) a se stříškou (î/Î).

Správně implementované toUpper("i") tedy s tureckým locale vrátí "İ", což programátora očekávajícího znak z rozsahu ASCII může překvapit a způsobit pád aplikace.

Mezi velkým a malým písmenem prostě bohužel obecně není rozdíl jednoho bitu…

AFAIK se na webu prave pouziva UTF-8 i pro asijsky jazyky, nebot diky HTML tagum porad velkou cast obsahu tvori ASCII znaky, jedine, kde se nevyplati pouzit UTF-8 by bylo mit nejakej asijskej text, kde neni moc ridicich znaku (ASCII), ti by pravdepodobne pouzili UTF-16. Pak taky mame technologie, ktery zase nic jinyho, nez UTF-8 neznaji

Kolik znaků umí průměrný 3rd party font?

A nebo obráceně. Kolik fontů umí všechny znaky?